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.
[1] Aaron Pippin, Delivering on an E-Discovery Project: Is Gold-Plating Necessary?, Discerning E-discovery, Dec. 8, 2009, http://www.discoveryresources.org/discerning-e-discovery/delivering-on-an-e-discovery-project-is-gold-plating-necessary/ (last visited on Dec. 29, 2009).
[2] Id.
[3] Rita Mulcahy, PMP Exam Prep: Rita's Course in a Book for Passing the PMP Exam 239 (5th Ed. 2005). In her on-line course lectures, Rita Mulcahy she states that gold plating is unethical (from my notes from her 2009 course materials).
[4] Project Management Institute Code of Ethics and Professional Conduct 2.2.3 (2006), available at http://www.pmi.org/PDF/ap_pmicodeofethics.pdf.
[5] Pippen, supra note 1.
[6] Sharyn A. Brotz, The Positive Side of Gold Plating--Introducing the Concept of Scope Interpretation Bandwidth, at 6. Available at http://www.pragmatic-systems.com/Pragmatic/Gold%2520Plating%2520or%2520Gold%2520Starring.pdf
Good comments, Paul, as usual.
It seems to me that the PMBOK is talking about a world that exists only in certain precincts, particularly manufacturing, where all parameters and tolerances are known and a system can be fully specified.
In an organic system, however, such as legal services or software development, the complexity of interrelationships is such that it's effectively impossible to specify every last detail. Indeed, if you try, you'll likely wind up with a spec that is a) self-contradictory and b) unreadable and thus impossible to implement. In such fields, a spec is a map.
I'm writing this on an island about 7 x 20 miles in size. To perfectly map this island, you'd need a map that was itself 7 x 20 miles, quite a useless endeavor. Rather, the map sketches the key points at a decent but imperfect level of detail.
All maps are abstractions, describing but not truly "specifying" the terrain. There is considerable leeway in filling the gaps.
I like your map analogy. Still, consumers of legal services are expecting greater precision in the road maps of their legal matters. Attorneys can no longer get away with merely stating that every case is different and outcomes are unpredictable.
What I like about Ms Brotz's "scope interpretation bandwidth" concept is that it forces the project manager to communicate with the client to find what the CLIENT'S middle ground is between perfectly mapping out every detail and driving blind.
The comparison to risk management is appropriate. Lawyers regularly counsel their clients about the risks involved when making various legal decisions. Experienced lawyers are quite adept at discussing the likelihood of various possible outcomes and helping the client determine what amount of risk they are willing to take on. Lawyers, however, often are not so good at leading clients through similar discussions about the overall scope of their matters and helping them determine the parameters of the representation.
Project Management in Forensic Record Examination. E-discovery tools and techniques can be classified into one or more paradigms as “voluntary standards for electronic discovery consumers and providers to reduce the cost, time and manual work associated with electronic discovery” under a graphic “EDRM” trademark for electronic discovery records management.
If the project manager feels some info will be helpful he can clarify it with the client that makes sense.
It's important to remember that requirements can often be defined in terms of parameters. That allows you to assess the client's utility function. For example, take the deadline. Having a non-perishable product in before the deadline is always fine because it can wait on the client's desk and then be addressed on the deadline (if not earlier), so the client's utility for having a deliverable early is greater than or equal to the utility of having the deliverable in on time, however having the deliverable in late would result in less than or equal utility thus not meeting (or exceeding) the requirement.
As you point out in this article, however, is very important. Since a requirements document rarely specifies all parameters of a deliverable explicitly it's important to understand what other things decisions in your project management affects.
-R