Project Managers Would Make Terrible Bakers

For example, if a client asks for a specific report, they know what they are looking for and hope the report will give them the needed information.  If the PM takes the time to include information he or she thinks is relevant but was not requested, the report could end up being convoluted and/or raise new concerns.  It may also take more time to generate the report in order to provide this additional but unnecessary information.^[2]

Gold plating refers to giving the customer extras (e.g., extra functionality, higher-quality components, and extra scope or better performance). This practice is not recommended, as gold plating adds no value to the project. Often, such additions are included based on the project team's impression of what the customer would like. This impression may not be accurate. Considering that as of 2004, only 34 percent of all projects succeed, project managers would be better off spending their time seeing that projects conform to requirements.[3]

But few people are going to resent the extra doughnut if they don't have to pay extra. And, more to the point, I might not mind paying more for a doughnut up-grade (e.g., holiday-themed pastries) as long as it is communicated with me. Communication here, as usual, is key.

Mr. Pippen notes this when he suggests that:

[t]o resolve gold plating, take a few minutes to discuss with the client what the report should and should not include.  Discover the questions the report is supposed to answer.  By doing this, you may have suggestions that will deliver better, cleaner data.  You will also properly set expectations in terms of timelines and the data needed.  Although a gold-plated response may be seen as a desirable goal, delivering exactly what the client needs in a timely manner usually provides the most value.^[5]

Here, however, he seems to simply recommend setting the scope. One issue I have with traditional project management as represented by the PMBOK Guide, is the seeming rigidity of the scope-management processes. Not all elements of the PMBOK apply to all projects, especially to all legal projects. Traditional project management can certainly be adapted to legal work, but that adaptation requires more fluid scope management than what is generally taught and tested.

Sharon Brotz, Managing Director of Pragmatic Systems International Corp., in an article providing a alternative and more positive view of gold plating, introduces the concept of \"scope interpretation bandwidth.\" In explaining this concept, she also uses the example of reporting, which provides a nice tie-in with Mr. Pippen's post.

Shall we ... follow the requirements so closely and literally that all possible additional peripheral benefits are suppressed for consideration? Suppose the requirement calls for 5 clearly specified hard-copy reports; shall we provide just those reports and ensure that no additional data fields are available for further analysis? Shall we not even advise our customer of the potential of drill-down online reporting (albeit with an associated cost or time increase). This decision about which way to proceed in terms of honoring the scope is to introduce a new concept--Scope Interpretation Bandwidth which should be set forward during the scope definition phase and added to the Contingency dollars in terms of project cost management. Similar to Risk tolerance, the Scope Interpretation Bandwidth should establish a percentage increase ceiling by which the project funds cannot be exceeded. If the project sponsor above clearly wants 5 hard copy reports and nothing more, then providing the business user with the option of more of an on-line system may be met with anger rather than contentment. However, if the Scope Interpretation Bandwidth as set forth by the project sponsor is more tolerant of interpretations for potential increases in the scope, then this provides the green light to consider options.[6]

I'm not sure that we need to add new terminology and processes to the PMBOK. What Ms Brotz brands \"Scope Interpretation Bandwidth\" seems to me to be nothing more than good client communication and a shortcut method for making changes to the project scope, within pre-set boundaries, without requiring laborious scope-control processes and the associated delays and perverse incentives they can create. 

In any event, I'll be sure to communicate to my baker that my Scope Integration Bandwidth has plenty of room for extra doughnuts and sprinkles.