The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects

Atwood wrote about the Iron Triangle – the three critical dimensions of any project. Most project management folks refer to the three legs as Money, Scope, and Time, and Atwood gives a good treatment for the software development crowd, tweaking the three terms (which can apply to any project, not just software) …

1. Time – purely in a calendar sense – adding weeks to the overall duration of a project. Not to be confused with …
2. Resources – a better term for the Money leg, because what you really need are hands to the task, and money can buy that – along with additional servers, programming tools, training, etc. Yes, this will generate more working hours to get the tasks done, but that is “capacity”, not Time (see #1)
3. Features – Atwood uses the term Functionality, but I like the term Features – when negotiating the Triangle with the Project Sponsors, you are typically reviewing that long laundry list of Stuff they talked about during the Requirements phase.

Now, Atwood wants to change the shape of the venerable Triangle, and add a fourth dimension – Quality. If you are up against a fixed budget, with a fixed development team, somethings gotta give, and that thing is typically quality; unit testing and some system testing may take place, but acceptance testing is cursory, technical documentation a pipe dream (to the delight of the techs), and volume testing happens with that first round of lucky users (oh, beta, right …)

I disagree: Quality is a Feature, and project planners and sponsors must knowingly accept the risk when testing and documentation is sacrificed to make a deadline.

This is best illustrated when working the project plan, and the unruly Gantt chart that stretches past the target date. A fully loaded plan will correctly have time set aside for documentation, a full suite of testing, plus training, conversion, and “burn-in” – some span of time where project members are on-call, watching the systems performance, providing focused follow-on training where needed. When doing a roll-out to multiple departments / locations in the business, it’s also a good idea to put in calendar “buffers” between major process changes, so the folks on the line / in the trenches don’t get blown away with changes every week.

Of course, when the resource leveling hits, and the end date stretches to a full quarter beyond the target … well, those big stretches of lag time look all too easy to cut out. It takes a strong project manager – or, more often, an experienced business sponsor whose been burned before – to fight for those elements to remain in the plan. Success is never about the number lines of code that make it into production – it’s about delivering the business results that you paid for.

The correct Feature(s) to remove are the Functionality bits – cut the brilliant menu options, the alternative views, the fancy reports, but do not skimp on the Quality stuff. If you lay out your project correctly, folks will see that simplifying the Functionality / Feature set of the software can also cut down the Testing, Training, and Documentation portions of the plan.

The super-simple PM one-liner for the Iron Triangle is …

Better, Cheaper, Faster – Pick Two

Better means more bells and whistles, but infers bells and whistles that aren’t cracked.