December 20, 2008
I have written a couple of posts now (here and here) about the new PMBOK v4 guide due out soon. One of the new graphs included helps describe how project characteristics change over the project life time.
The top blue line of the graph is used to illustrate how Stakeholder Influence, Risk and Uncertainty start off high and then reduce as the project progresses. The Escalating orange line illustrates how the Cost of Changes increase dramatically over the project timeline.
Quite a lot has already been written on flattening the Cost of Change curve within agile, so I will leave that for now and focus first on the top line.
Before discussing ideas such as how ongoing business input in, for example, prioritization of the remaining work prolongs their ability to influence the project, we should take a moment to understand the PMBOK audience. The PMBOK is not just for software projects, or IT projects, it is an industry agnostic guide relevant to construction, engineering, and manufacturing among other disciplines.
As a general guide, I think these curves make sense, especially outside of software projects. The ability to influence does decline rapidly once designs are committed and construction begins. Likewise, Risks and Uncertainty also reduce generally later in the project once technical obstacles have been overcome.
Software though is different, actually I would hazard a guess that every industry is different really, however software is the one that I know about. Software exhibits a characteristic known as “Extreme Modifiability” meaning we can make many changes, even late in the lifecycle and still be successful. While it would be difficult to move a bridge 3 miles upstream when it was 75% complete; we could choose to move validation logic from the presentation layer, to a middle tier, or a database trigger late into a project.
Not all software changes are possible, wise, or cost efficient, but many are, and unlike other industries we can allow the business to suggest changes and evolve our designs late into the project. So, I would suggest that Stakeholder Influence remains higher than the curve suggests, especially when using agile approaches such as backlog re-prioritization.
The other two attributes Risk and Uncertainty are undesirable things to have at high levels on projects since they can lead to failure and cost overruns. Iterative methods deliberately pull high risk elements of projects forward in the timeline to tackle them early and reduce their impacts. By undertaking the risky work sooner we have more options, time and money at our disposal to solve them or find work-arounds.
For many years, RUP and other methodologies have promoted the early development of risky portions of a system. The Extreme Modifiability of software also allows most projects to trial portions out of normal development sequence. For example, we can build portions of a reporting system, database access, or interfaces before they are needed, to test the architecture and performance.
As these risky pieces of the project are solved so too are many of the project Uncertainties. For a software project using an iterative approach and risk based planning, the profile of this top line splits and becomes as follows:
Now we see that Stakeholder Influence (in brown) stays higher for longer as we exploit software’s ability to accept late breaking changes along with mechanisms to continually engage the stakeholders. At the same time Risk and Uncertainty (in red) drops much faster as we actively attack the risks before they can impact the project.
Finally the good old Cost of Change curve. Agile advocates once argued that with a simple design and liberal refactoring the Cost of Change curve could be flattened. There is a difference between flatter and flat (horizontal). After Kent Beck’s original discussion on flat Cost of Change curves he revised his comments and accepted that the cost of changes does most likely continue to rise as the project continues (especially for large projects), but good practices such as simplicity and refactoring can really help reduce the rate at which it climbs.
I think there is little debate now, a flat Cost of Change curve is the goal; and software teams should undertake practices like: simple design, frequent testing, ruthless testing, and refactoring to achieve this. With these techniques in place, the Cost of Change for software projects can be greatly reduced compared to projects in other industries as shown by the green line below.
The original graph was elegant in its simplicity
I separated Stakeholder Influence from Risks and Uncertainty, complicating the graph, but if we remove Risks and Uncertainty we are left with following:
Here Stakeholder Influence lasts longer and the Cost of Changes are reduced. Adding Risks and Uncertainty again completes the view for agile software projects.
When the new PMBOK v4 is issued I imagine the graphs will be incorporated into PMO guidelines and put into training courses as those in previous editions of the PMBOK guide have. I like visuals and think they help bring a much needed right-brain aspect to project attributes, I just hope people do not take them as gospel for their own environments and instead think about how project characteristics may differ and continue to look for ways to flatten the bad curves and jack up the good ones.
Good job bringing the "right" brain aspect in.
I think the visuals do a good job showing how stakeholders can influence a project longer throughout the cycle vs. the dream it up front approach.
I think a lot of people mistake "agile" for speed, when really what it means is "ability to respond to change." Basically, built to change over built to last.
Where most folks struggle is I see they try to switch to time-based projects, but they don't flex scope. They think in terms of backlog burndown instead of value-delivered. Part of building a rhythm of success is being flexible in the value you deliver -- as you learn more, tune more .. and remember that the backlog is input, but value is the ultimate yardstick.
The other place folks fall down is they just do "user stories" and they don't do "system stories" or "business stories" (they mix up perspectives in a way that makes trade-offs tough.) Designing software is about trade-offs and a simple way I checkpoint is I ask to see the user stories, business stories and system stories. When it's all mixed up or just plain absent, then I know the thinking is mixed up which means I need to start digging for the likely risks. Balance is key and so is making deliberate choices.
People make better choices when you give them a better lens.
Posted by: J.D. Meier | December 21, 2008 at 05:31 PM
Excellent discussion. Perhaps you would also like to address scope creep? We all know scope changes cost more when executed later in a project (more rework, various penalties with the cost of change after competitive bidding, etc.) and I think the software environment has a particularly perverse outcome here. As the work progresses, the work effort becomes more esoteric to software languages and constraints, etc. with developers doing their own thing more and more, and all of the sudden every single one of them has the opportunity to put his/her own signature on the project with some simple doodad. Hey, it’s only a few extra hours of work, right? Wrong! If everybody does that, we’re over budget! Unique to software, I’m not sure the risk of scope creep ever diminishes throughout the life of the project, and incorrectly managing that agile flexibility could become a double edged sword.
Posted by: Joe Carapellucci | January 18, 2009 at 08:03 PM
Thanks for sharing your perspective. If developers were tempted to embellish or add their signature to the project then I can see that scope could increase. This has not been my recent experience, usually as the project progresses and the demo’s to the users illustrate velocity, the team wants to deliver the system as quickly as possible.
I think visibility might be the key here, when I used to develop on traditional projects there was little or no accountability to real progress or motive to finish early. Yet when we are demo’ing every week or two, progress always seems slower than desired. Everyone hears the business requests for the next piece of functionality and people work hard to simplify and deliver.
As PM I track budget, schedule, scope, risks, and quality much like anyone else, but the biggest graph on the wall is velocity. Anything not planned for an iteration earns zero points, people don’t like working on things that do not gain velocity credit, it brings the teams average per iteration down. I do not think this is why the team is so focussed, I am fortunate to work for a great team, but our metrics are simple and relevant to the real goal, getting the project finished to the satisfaction of the business and I think this helps a lot too.
Thanks for your comment, I know gold plating is a very real software project issue and one that deserves an article itself.
Posted by: Mike Griffiths | January 18, 2009 at 10:26 PM
I like your velocity points idea. Years ago as a project engineer, I used to do my own breakdown of the budget allocated to me, and at the end of the week if I found I had engagement hours with no budget to place them against, I knew I was in trouble! Same idea, velocity points move the ball forward, and nothing else counts, at least in this context. Great visibility and goal alignment, and yes, the issue I was referring to is scope creep due to lack of visibility.
Posted by: Joe Carapellucci | January 23, 2009 at 05:51 PM