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.