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.