The Critical Path Week Ending February 28

No Comments

January 28 through February 5Due to working crazy off hours in preparation for my v1.0 launch, I not only forgot to do a week in review on the 20th, I also missed meeting my writing commitment on the 24th and 25th.  Whatever the excuses, I was feeling a little burned out.  I have to remember this is a marathon and not a sprint.  Writing a daily blog takes a lot of discipline.  Though I have so much to say, it can escape me if I don’t get the idea captured quickly.  Wow, it’s hard to believe it’s almost March.  At least there should be viewer posts about snow removal.

2/26/2010

Putting Things In Perspective

I had mild chest and shoulder pains this morning. I am in the ER waiting to see the doctor. I’ll let you know the outcome and my status shortly…

2/23/2010

Satisfying Needed Scope Versus Wants

There are many templates and means to ensure your project meets the requirements.  But I can’t stress enough how important it is to ensure you’re working to satisfy the requirements (or scope) first…

2/22/2010

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it…

2/21/2010

How To Prevent Your Project From Hemorrhaging

This 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…

2/20/2010

How Owners Managers and Leaders Differ

I was asked a very interesting question today, requiring me to stop and think. How do I believe being an entrepreneur and a business owner differ? It’s a very good question because…

2/19/2010

What You Need Is Some Kaizen

While sitting in a governance meeting the other day, I heard how (before I joined the team) a vendor brought in some high paid six sigma black belts to…

2/18/2010

How to Thank a Managed Camel

I was informed I am the winner of the very first Freedom of Speech February (FOSF) giveaway from How to Manage a Camel.  My comments last week on a blog post by Gary Holmes earned me a free copy of the Method123 Project Management Methodology (MPMM™) Professional from their partners at Method123…

2/17/2010

Creeping Ever So Closer To Closure

As my startup project is creeping ever so closer to its closure and the actual launch of the product happens, I’m feverishly completing activities late into the night.  It’s not easy working crazy hours to get this done.  My family goes to bed, I drink a pot of coffee, and get to work…

2/16/2010

Interesting PMI Perspective On Claiming PDUs

…Based on the telephone conversation I had, if you’ve worked as a PM for at least 6 months, you can claim 5 PDUs.  Otherwise, if you are able to say you spend more than 1,500 hours per calendar year in that roll, you also qualify to claim the 5 PDUs…

2/15/2010

Getting Exactly What You Want

I just wrapped up a week long logo design project at 99Designs, with an intellectual property transfer agreement.  Flash back to August 2009, when I was watching Episode 13 of This Week in Startups

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?