Tag Archives: Quality

Quality Archive

How To Prevent Your Project From Hemorrhaging

– February 21, 2010Posted in: Application Development

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. 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?

Popularity: 1%

Tags: Creep, Goldplating, Quality, Risk, Scope, SDLC, Triage

Free Total Project Status Report Template

Derek Huether

– June 11, 2009Posted in: Application Development, General, Scrum

As I study the collection and reporting of metrics and project statuses, I find many reports just do not deliver what they should. I believe there should be a stand-alone deliverable that a project manager is able to provide to a stakeholder at any time, illustrating the total project status. I created a report and used the name “TPS Report” from the movie Office Space. I try to interject a little humor into a project, where I can, without raising too many eyebrows. Because I do not think I should keep all of the good stuff for myself, I hope others will download my free template. It captures everything from overall project status to schedule, budget, scope, and quality, including a RAG (Red, Amber or Green) status. What milestones were planned and accomplished? What is planned for the next period? Though I believe a subjective narrative does have its place in project reporting, I like the more objective approach. Give your stakeholders the facts!
Please enjoy this free copy of my Total Project Status Report Template.

Did you learn your lesson?

Derek Huether

– May 5, 2009Posted in: Project Management

I’m going to be facilitating a second lessons learned session later today.

As part of the project closing processes, all project managers should collect and document lessons learned. But, as many will attest, you need to be able to implement approved process improvement activities or you will just continue to revisit history at the end of each cycle or project.

Do you learn from your mistakes? You should be able to at least be aware of them if you document them at the end of each cycle or project. Revisit them at the beginning of the next project or cycle.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Kobayashi Maru for Projects

Derek Huether

– March 6, 2009Posted in: Project Management

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I’m presented with a no-win scenario. I doubt they are trying to test character. Rather, it’s an example of their lack of understanding project management.

I’m sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru. Just because I have a PMP®, don’t expect me to pull a rabbit out of a hat. On a previous program, I’ve looked management in the eye and reminded them that something will have to give. Narrow scope, extend the deadline, lower quality expectation, or increase the budget. Do something or this will be a no-win scenario.

Image from : drexfiles.wordpress.com

Popularity: 1%

Tags: budget, PMP, Quality, Scope, Star Trek, Time, Triple Constraint

What is missing from a Cost Performance Report

Derek Huether

– February 27, 2009Posted in: Project Management

I recall a very positive meeting where we exposed several non project management team members to a Cost Performance Report (CPR) for the first time. A CPR addresses project performance through a defined period of time in relation to contractual requirements. The CPR details budgeted work scheduled and performed, actual cost work performed, and the variance in both schedule and cost. All of this is itemized per Work Breakdown Structure (WBS) element for both the current period and the cumulative to date. The last values you see are the budgeted, estimated, and variance at completion of the contract.

There were a lot of questions as to why one WBS element has a positive or negative cost variance and why it may have a positive or negative schedule variance. Trying to explain this to those without a project management background can be a challenge.

I was having a sidebar conversation with one team member who could not understand how the element that pertained to him could be both ahead of schedule and below budgeted cost. The answer came from across the room in the form of a question.

“Is there any way this report captures quality?” The answer was no.

That my friends is called Triple Constraint. We know the Scope, Time, and Cost within this report. What we don’t know is Quality, Risk, or Customer Satisfaction. That’s ok. This is the CPR, not a Total Project Status (TPS) Report.

By not committing the scheduled time and budgeted dollars to complete the task to a level of quality that meets the customer’s expectations, the contractor looks good only on paper.