“Gold-plating,” or giving the customer extras such as bonus functionality, higher-quality components, an expanded scope of work or better performance, usually is frowned upon in project management circles. “Often such additions are included based on the project team's impression of what the customer would like,” says Rita Mulcahy in the PMP Exam Prep Guide, Second Edition [Beaver's Pond Press, 2000]. “This impression may not be accurate. Considering that only 26 percent of all projects succeed, project managers would be better off spending their time conforming to requirements.”
Of the 74 percent of projects that are failing, how many fall short because they don't provide additional value and/or capabilities? How many actually fail due to poorly written requirements and insufficient utilization of creative energies on the part of a strong technical project team to meet or exceed expectations?
High-level requirements aren't necessarily the best indicators of project success. They typically portray a functional need, addressing what is desired and not how these requests will be met. What's actually needed or requested by senior management and what can be designed by the project team often are two vastly different things. Providing customers with better-than-expected quality and service can make a difference.
What's actually needed or requested by senior management and what can be designed by the project team often are two vastly different things. Providing customers with better-than-expected quality and service can make a difference.
Devil in the Details
Following the project requirements verbatim is in direct conflict with the popular development trend in IT. Custom-developed applications often are the most expensive software options. As a result, over the past 10 years, there has been a movement toward creating reusable code—object-oriented technology that enables recyclability. Well-trained developers are geared toward producing flexible solutions or finding generic plug-in components to gain greater economies for potential reuse on other projects. Constraining creative developers to follow requirements more closely and literally means that all possible additional peripheral benefits would be suppressed.
Scope interpretation bandwidth is a method of honoring the scope while allowing flexibility. Similar to risk tolerance, scope interpretation bandwidth establishes a percentage increase ceiling for the project funds. This contingency is determined during initial meetings with the stakeholders. If options for potential scope increases are approved by the project sponsor, greater functionality and satisfaction may result. This concept fits with methods already detailed in A Guide to the Project Management Body of Knowledge (PMBOK,® Guide) (Figure 1).
ON THE RIGHT FOOT
A project is always better off when all stakeholders understand scope requirements from the outset, during project initiation. However, the interpretation of the project requirements often does not realistically occur until well into the design or even the development phase. To improve communication:
■ Include a designer or developer (or project manager with these skills) as early in the project initiation as possible
■ Establish the scope interpretation bandwidth (tolerance for increased functionality) as part of the project budget process
■ Recommend a standard contingency to cover about a 25 percent overage in scope right from the beginning
■ Provide a comparison of the functionality options with the anticipated benefit of providing them to enable a more objective review
■ Suggest beginning the project with interactive sessions including the customer and the designer/developers to clarify the interpretations of the requirements and introduce a prototype phase, if feasible, to actually show examples of the variations that are available to the customer.
Figure 1.
This diagram illustrates how the scope interpretation bandwidth method fits into the framework detailed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
Compare and Contrast
Determined as part of project initiation, scope interpretation bandwidth must be broken down into tangible, quantifiable amounts in terms of the critical project components of overall project objectives, the project time line, the project budget and post-project operational cost factors. Ideally, a contingency within the budget would be established so that the total budget amounts are not exceeded.
With a rough idea of project high-level requirements and by consulting with the project stakeholders, the project team can provide the various options armed with an order of magnitude estimate of how these interpretations may impact the project budget.
For example, Pragmatic Systems, Key Biscayne, Fla., USA, was contacted by a midsized, U.S.-based cruise line about to replace its enterprisewide reservations system with a package solution (as new brands were being introduced). The company needed consolidated reports, and several business users presented Pragmatic Systems with sketches of the desired reports as well as the reports already in place for decision-making in key revenue management and sales areas.
But in many other technology projects, the actual expectation and the written requirements did not match. The cruise line asked for “reports to analyze and compare the brands” (Figure 2). Based on the requirement for reports alone, the project could have delivered a range of functionality while remaining in scope. Based on a wide bandwidth for scope interpretation, the company got an intranet-based system with complete drill down and graphical capabilities.
Naturally, an intranet-based solution with all the capabilities that were provided is more costly, and the more robust solution is not always welcome. However, spending time with the customer and gaining an understanding of the nature of the requirements allows all stakeholders to review options and alternative interpretations, along with the final implications of changes in terms of cost and schedule.
More From Less
Of course, the degree to which a customer is willing to alter the initially stated high-level requirement will depend on many factors, including the project's return on investment (ROI). Scope interpretation bandwidth can reveal an opportunity for a reduced scope alternative.
Figure 2.
Requirements alone did not present adequate definition of a cruise line's expectations for a reporting system. Shown are the possible increases in functionality clarified during scope interpretation bandwidth.
For instance, when Pragmatic Systems was approached by a U.S.-based utility company to assist with the implementation of a new interactive voice response (IVR) system for a busy call center, requirements were one-sentence descriptions of desired report titles. Did this mean the customer wanted hard-copy or Web-enabled reports, graphical views, options to drill-down and exception reporting? The utility company wanted to ensure that it had reports representing all facets of the customer experience whether the customer began and ended his experience within the IVR or was subsequently transferred to a customer service representative.
A project was proposed to provide significant functionality to assist in scheduling for the call center. As more details were provided, an evaluation matrix was developed to prioritize and compare functionality with typical product costs to deliver those bands of functionality. As more analysis was conducted within the next two weeks, the team determined that lower cost alternatives exceeded the critical project requirements while eliminating those that did not positively contribute to the project's ROI.
Careful Coordination
With scope interpretation bandwidth as an adjunct to other critical project components, project managers can develop a clearer understanding of methods and the deliverables.
If the sponsors and stakeholders believe that their initially defined scope and associated requirements state precisely what they want, then the tolerance for any increase is reduced to zero. The project scope definition still is improved by identifying additional components that will not be added to the project. However, if there is more tolerance for additional suggested courses of action and activities, the scope statement, work breakdown structure and especially the budget cost estimates can be updated more accurately. PM
Sharyn A. Brotz is managing director of Pragmatic Systems, a Key Biscayne, Fla., USA-based consulting firm that specializes in technical project management particularly for software development projects.