How To Prevent Your Project From Hemorrhaging

12 Comments

Triage Your ChangesThis post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating.

Goldplating is very common in application development and can be very expensive. If you’re dealing with Waterfall, it’s a little more obvious when it’s happening.  Some may argue, but I’ve seen it happen in Agile as well.  I’ve sat across the table from a vendor and asked, are you prepared to roll back every one of these changes?  Their eyes get big because why wouldn’t the client want these changes?  Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month.  Or, now that I’m here, it makes a lot more sense if I do it like this versus what we originally thought.

In short, Jennifer wrote about goldplating caused by testers. She asked

why is it always the developers who get blamed for goldplating? When you consider 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. 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…

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I’m not saying changes should not be made.  I’m saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end…customer satisfaction.

Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.

Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.

Am I just a control freak or do you agree with me?

12 Replies to “How To Prevent Your Project From Hemorrhaging”

  1. I am 100% with you on this one. When you are late on your deadline and above budget, nobody remembers the extra stuff (goldplating) you added to the scope for them because you are so nice. The customer actually forgets about all those nice things you added and only remembers that you are late and overbudget. 9 times out of 10, if you are a vendor, the customer will expect you to eat any additional cost.

    1. Samad, I can empathize with so many PMs out there, trying to give the customer what they want. Sometimes, you just need to treat them like children. My Son would love to eat nothing but snacks or stay up late into the night. I would not be a good Father if I didn’t make sure he ate his dinner first and got the rest he needed. We, as good stewards of our children and projects, know better. Sometimes we have to save or kids and customers from themselves. You’re absolutely correct that when push comes to shove, customers can have selective amnesia. Though people hate the idea of having a formality of approved and agreed upon changes being documented, it will save a vendor a lot more then it will cost.

      1. So true Derek.

        A PM friend of mine once gave me a children’s book to read called “If You Give a Mouse A Cookie“. you probably heard of it. It tells the story of the problem you run into if you happen to give a overly active and demanding mouse a cookie.

        In the story, a little boy’s one act of generosity caused him a lot of trouble. “If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him milk, he’ll probably ask you for a straw. When you give him a straw, he will ask………” And it goes on and on and on until the poor kid is completely exhausted trying to fulfill the never ending requests of the demanding and pushy little mouse.

        This book should be a required reading for all new project managers as education about consequence of goldplating.

        1. Samad, that is one the best comparisons I have heard in a very long time. Now that you mention it, customers are not unlike my 4-year-old or that mouse in the book. They will ask and ask and ask with the hopes you will give in. Don’t blame them for asking. Just learn how to deliver a positive no.

  2. I am 100% with you on this one. When you are late on your deadline and above budget, nobody remembers the extra stuff (goldplating) you added to the scope for them because you are so nice. The customer actually forgets about all those nice things you added and only remembers that you are late and overbudget. 9 times out of 10, if you are a vendor, the customer will expect you to eat any additional cost.

    1. Samad, I can empathize with so many PMs out there, trying to give the customer what they want. Sometimes, you just need to treat them like children. My Son would love to eat nothing but snacks or stay up late into the night. I would not be a good Father if I didn’t make sure he ate his dinner first and got the rest he needed. We, as good stewards of our children and projects, know better. Sometimes we have to save or kids and customers from themselves. You’re absolutely correct that when push comes to shove, customers can have selective amnesia. Though people hate the idea of having a formality of approved and agreed upon changes being documented, it will save a vendor a lot more then it will cost.

      1. So true Derek.

        A PM friend of mine once gave me a children’s book to read called “If You Give a Mouse A Cookie“. you probably heard of it. It tells the story of the problem you run into if you happen to give a overly active and demanding mouse a cookie.

        In the story, a little boy’s one act of generosity caused him a lot of trouble. “If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him milk, he’ll probably ask you for a straw. When you give him a straw, he will ask………” And it goes on and on and on until the poor kid is completely exhausted trying to fulfill the never ending requests of the demanding and pushy little mouse.

        This book should be a required reading for all new project managers as education about consequence of goldplating.

        1. Samad, that is one the best comparisons I have heard in a very long time. Now that you mention it, customers are not unlike my 4-year-old or that mouse in the book. They will ask and ask and ask with the hopes you will give in. Don’t blame them for asking. Just learn how to deliver a positive no.

  3. Derek

    Maybe its time for developers to keep a goodwill log, for times, when the customer wants some changes without going through a change request! I often see customers ask designers and developers to add this feature, because it is a “best practice” (Oh, how I hate that term!). This is especially true with applications with a substantial user interface.

    Usually, this is an issue because the senior managers in the customer organization have a different view of project success (and vendor performance) compared to the operational manager.

    While performance on scope, schedule and cost is important to all, the operational manager expects the vendor to be “flexible”. All in the name of customer value.

    You are right in saying that project managers have to show tough love.

    Great post and on target, as usual.
    .-= Sridhar´s last blog ..Some thoughts on Risk Management =-.

    1. Sridhar, I like the idea of a goodwill log! In the past, I’ve had my team use a Kanban board with a triage column, so everyone could see the requested changes and who is asking for them. It was interesting, by doing so, a specific stakeholder backed off from going directly to the development team. There’s always that one stakeholder who insists in bypassing the process. Everyone then pays the price. Whatever tool or process that will empower both sides to fully vet a requested change, I’m for.

  4. Derek

    Maybe its time for developers to keep a goodwill log, for times, when the customer wants some changes without going through a change request! I often see customers ask designers and developers to add this feature, because it is a “best practice” (Oh, how I hate that term!). This is especially true with applications with a substantial user interface.

    Usually, this is an issue because the senior managers in the customer organization have a different view of project success (and vendor performance) compared to the operational manager.

    While performance on scope, schedule and cost is important to all, the operational manager expects the vendor to be “flexible”. All in the name of customer value.

    You are right in saying that project managers have to show tough love.

    Great post and on target, as usual.
    .-= Sridhar´s last blog ..Some thoughts on Risk Management =-.

    1. Sridhar, I like the idea of a goodwill log! In the past, I’ve had my team use a Kanban board with a triage column, so everyone could see the requested changes and who is asking for them. It was interesting, by doing so, a specific stakeholder backed off from going directly to the development team. There’s always that one stakeholder who insists in bypassing the process. Everyone then pays the price. Whatever tool or process that will empower both sides to fully vet a requested change, I’m for.

Leave a Reply

Your email address will not be published. Required fields are marked *