Tag Archives: scope creep

Your Project Will Change

You led your team through a very thorough requirements gathering process. There was brainstorming and walk-throughs of the product functionality. Multiple groups contributed and reviewed the results. Additional analysis and review went into deciding which of the requirements would really make it into the scope. There was plenty of intelligent debate. And now finally, the project scope document has been signed.

Everything has been agreed upon and there will be no changes. Right? Wrong! Your project will change. You might begin to think, “What does she know? She wasn’t there. She did not see all of the work that went into agreeing upon our project scope.” You are right. I have not been following you. Still, your project will change.

What you have done is helped to ensure that the changes that occur either stem from unforeseeable circumstances or are truly useful enhancements or result from changes in the organization or political climate. Your project will change.

Even with the best planning possible, random things can occur. Previously stable business partner can go out of business and cause you to seek out new suppliers. A certain type of material may not hold up to testing. A new regulation may be imposed on your industry. A product may not function as designed. Testing might reveal a flaw. Sometimes unforeseen events bring about change.

As the project moves along, your team members will develop a better understanding of the work that is being performed. Your customers will develop a better understanding of what they really need. New ideas will evolve. You are not going to tell all parties to stop thinking, to stop coming up with new ways to make your product or service even better. You want the good ideas to keep flowing. If a change to the project is valuable enough, then a change request should be approved and the change should be incorporated. Your project will change.

To your surprise, your project sponsor who seemed happy and stable in her position announces that she has accepted a position outside your organization. Her replacement supports your project, but has different ideas about the project objectives and about what you and your team should really be creating.

Say it with me now, “My project will change.”

And it is going to be all right. The amazing work you did with your requirements and your scope document was well worth the effort. By spending time gathering requirements and agreeing upon scope, you have created a good baseline for the changes that will come. You and your team will recognize change. You will be able to have intelligent conversations about what these changes mean to your project.

Let the changes come, you are ready for them.

Do testers goldplate too?

Do testers goldplate too?

via Flickr by by Mykl Roventine

Why is it always the developers who get blamed for goldplating? Most people who have worked in a project environment know that goldplating is one of the biggest contributors to scope creep. When you consider that the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly.

But, what if the developers are not the only contributors to goldplating? What if goldplating is also being done by the testers? Considering the cost of change at the various stages in the SDLC, it becomes clear that goldplating by a tester could be ten times more costly than if it is done by a developer.? But, exactly how can a tester goldplate?

Goldplating by a tester?can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product.? A tester may feel that their suggestion would improve the customer experience so they log this in the defect log.? While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”.?? A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality.

Quality is defined as the ability to meet specified requirements as stated by the user.? The key in this definition is the user.? It is the user’s perception that determines whether a product meets their expectations.

To mitigate the risk of?gold-plating?by testers, all defects should be triaged by a member of the project team who has a clear understanding of the requirements scope. ?This person can determine whether each defect is truly a defect related to the current project or an enhancement suggestion for a future release.

The Need for a New Knowledge Area

Is the Sky the Limit?

Is the Sky the Limit?

So I’m doing some PMP sample test questions today and ran into one where at the end, additional things were added and the customer is very happy. According to the answer, this project was unsuccessful because the additional features were “gold plating” which wastes time and probably cost. Primarily, I got this wrong because I read “the project has added [this and that]” as the [this and that] = intended product of the project.

But there’s a deeper insight here.

Gold plating. What is it? To me, it’s when you add features or functionality without going through the change process. It’s unapproved scope creep….usually created by the project team themselves when it comes to the term “gold plating”.

Why does gold plating happen? Here is a theory.

  • A project team member comes up with an idea that will clearly add value
  • The thought of elevating it to the project manager, sponsor, or customer and going through the change management process is too painful to comprehend
  • This kind of thing is usually thought of as scope creep, and therefore it is bad
  • It usually never occurs to the team member that this is a “risk”
  • If it did occur to them, the word “risk” attached to it would give it a snowball’s chance – even more painful to bring with the project manager
  • so the team member finds a way to “squeeze it in”
  • This may mean that other tasks don’t get as much attention as they deserved

In the above scenario, there’s no checks and balances on what adds value or not. So what gets gold plated? Usually only things the team member finds “cool” and enjoys working on. To them, it adds value. Does it add value to the project? No one knows in this underground way of doing it. What if the team member decides to just forget about it? No scope creep, no gold plating. That’s good right?

Wrong! If the team member just forgets about it, the project just lost information about a potentially valuable opportunity.

We need Opportunity Management

In the PMBoK guide, opportunities on a project are dealt with as positive risks within the risk management knowledge area. I believe this is the wrong approach.

  • In practice, when people hear the word “risk” they immediately think negative
  • expertise and processes that need to come into play with opportunities versus risks can be very different, although there is definitely overlap with risk management also
  • A whole range of communication and practices dealing with the rest of the business come into play when you are looking for opportunities
  • Tools and techniques around quantifying the ROI of a potential opportunity and then seeking additional funding for it come into play
  • Lessons learned documentation specifically geared towards discovered opportunities
  • Increased focus and transparency in the process of discovering, evaluating, and executing on opportunities all stakeholders identify while planning, executing, and closing a project.

I mentioned this to Greg Balestrero, CEO of PMI when the New Media Council met with him recently in Denver, CO. He was discussing the need to make positive environmental and social impacts through project management, and I responded with this point. I’m not sure what he thought of the idea, or if that’s even a concern of his. I’m sticking to my guns so far in the call to add Opportunity Management as a new knowledge area in the PMBoK. Maybe it will make the 5th edition.

Think about your own project(s), current or in the past.

  • Did you or someone else come up with an idea that would have added a lot of value for the customer or business?
  • Did it get shut down or never communicated because it would have resulted in a change to the project scope?
  • Do people thus have a fear of speaking up about opportunities they think of while executing projects?

Leave a comment and let’s have a good discussion!