The ‘key’ criteria?
The triumvirate of criteria – time, budget, scope – are not always as clear cut or as exclusive as some might think.
Smyrk, who consults to industry through Sigma Management Science and is a Visiting Fellow in the Business School at Sydney University, recently co-authored a book with the Australian National University’s Ofer Zwikael on the subject, Project Management for the Creation of Organisational Value.
Classic elements of what he calls the ‘iron triangle’ are often used as the measures of the success of a project, but there may be end effects that are “unexpected, unacceptable and avoidable”. Smyrk calls these “detrimental outcomes”.
As an example, he cites a project manager who fulfils his project triangle, but in doing so puts his team under so much pressure that key technical staff resign towards the end of the project.
“If the loss of staff was considered a detrimental outcome, the conclusion is that the iron triangle fails as a test of project management success, because it ignores those detrimental outcomes that can be attributed to the management of the project,” Smyrk explains.
This then leads to a ‘steel tetrahedron’ – scope/quality, timeframe, cost and ‘acceptable’ detrimental outcomes (collateral damage in the military).
“Even if the project meets these four criteria, but doesn’t give the investment return expected, then it is an ‘investment failure’,” he continues. “It must be a project ownership failure and the project owner would be regarded as also failing”.
An example is the Cross City Tunnel in Sydney, which achieved the criteria for project success, but then failed to meet the investment criteria: 30,000 cars per day out of the CBD rather than the targeted 90,000. That the Tunnel was a project management success was of little comfort.
Increases in time and cost do not necessarily imply a project ‘blowout’, Smyrk says, if this has been accepted as a possible scenario and funded accordingly. “If a situation had not been identified, then the timeframe and budget have certainly been blown, but even this does not imply a failure of project management unless it can be shown that such a risk should have been identified.”
The customers
Regular communication with customers or end users is regarded as essential in the project governance mix. “The importance of this is often largely underestimated and is a main contributor to why projects are continually delayed, or not well adopted or accepted by the user community,” Corcoran says.
“Where possible, you should try to develop an implementation/delivery program to roll-out functionality incrementally, to bring users along with you on the journey, build acceptance and try to address some of their issues early in the piece. This is particularly important for projects attempting to address productivity and usability issues.
“At some point, a CIO needs to consider when any additional functionality that comes with a new technology should be implemented, taking into account their understanding of the impact on, and readiness of, the users of the system.
“If you foster a good working relationship, you should be able to ride out any bumps in the road that inevitably occur during big projects.”
Bailey agrees on the need for communication. “As I’ve heard it said, a stakeholder is someone who can put a stake in the ground or they can drive a stake through you. Ignore stakeholders at your peril.”
But letting customers and end users loose on the design and running of the project can be fraught with frustration. For Smyrk, customers should participate in the discussion of project scope but not define it.
“Project customers – those who generate outcomes through their use of the project’s outputs – are clearly critical stakeholders in a project. If they do not utilise the project’s outputs, then the project cannot generate its target outcomes,” he says.
If you foster a good working relationship, you should be able to ride out any bumps in the road that inevitably occur during big projects
A long-held view of project customers leads to the conclusion they have a dominant role in defining the project’s scope and specifying its outputs, but Smyrk warns this assumption and approach is naive.
“Any methodology which seeks to scope a project by asking customers to identify outputs is invalid because it involves circular reasoning,” he claims.
“The customers become known only after outputs are identified, not before. In other words, outputs identify project customers, not the other way around.”
That doesn’t mean customers are irrelevant. “Customers should be involved in scoping, but only to identify certain fitness-for-purpose features that proposed outputs must have so they can be utilised successfully.
“In other words, customers have an important role in constraining the project’s scope, but limited role in setting scope. In general, any congruence of views about the project between the funder and a customer is fortuitous.
In many cases, customers are negatively impacted by a project or will have objectives that conflict with those of the funder, so considerable care must be exercised when accommodating their views about desirable and undesirable features of outputs.”
Corcoran adds a caveat in dealing with customer expectations. “IT has become such an enabler for our everyday lives that we often forget there are limitations to it – either direct technological limitations or those we impose upon ourselves in the interest of system optimisation, security or cost,” he says.
“There is a lot which goes behind making something seem simple. This is not always well understood. This can be a real cause of dissatisfaction between the system developers and the client/users.”
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.