Remembering Why We Undertake ICT Projects

I’ve recently been reading Standards Australia’s publication HB280-2006: "How Boards and Senior Management Have Governed ICT Projects to Succeed (or Fail)"¹. Just yesterday, Pat Weaver blogged some related analysis which ultimately spurred this post.

Both sources draws similar conclusions about the need to identify the delivery aspect of a project as just one component of a larger game. Ultimately, both sources then attribute this responsibility, and thus commonality of project failure, to senior management.

I particularly like this quote from section 2.2.1 of the handbook:

The case studies provide quite strong evidence, that in general, ICT projects deliver benefits by enabling process change, and project management, user support and all the other traditional prescriptions are less important than senior management support. Only senior management can resolve the political issues that arise as a result of conflicts in objectives caused by change.

Within the software development community, we almost always view software projects as changes themselves rather than simply an enabler in a wider organisational change program. While we talk about needing product owners from the business to elicit requirements and resolve implementation questions, we don’t look to them to act as a change champion in anywhere nearly as structured a way.

Food for thought: Perhaps we need to move towards reducing the number of people tasked with gathering requirements (business analysts and subject matter experts) to make way for some people to be actively pushing change back on the business? Both Pat’s post and the handbook talk about this as the responsibility of senior management, however I think they can reasonably be assisted in a structured way, similar to how we employee business analysts rather than expecting the project champion to understand and document all of the requirements.

Certainly, the measure of overall project success needs to shift away from on-time/budget/scope delivery towards an assessment of organisational change and benefit realisation. This is a core principle to any form of Lean-based delivery, however is yet to make it’s way into the world of organisations still addicted to Waterfall-derived delivery models, or in most cases, even Scrum.

Finally, it is encouraging to note that I came across Pat’s post via a discussion thread in the Australian Institute of Company Directors LinkedIn group. This is a group very heavily comprised of senior managers, and consequently a great place to see these questions being raised.

¹ Warning: The publication mechanism for this handbook is positively horrible. After handing over AU$114.27 for a legitimate license, you receive it as a rights-stripped PDF, that requires a third-party DRM plugin for Adobe Reader, which only lets you open it on one computer ever, only lets you launch the print dialog once ever, prevents you from highlighting even a single word, and prevents the accessibility functions from working (in breach of the Australian Disability and Discrimination Act). To top it all off, they still feel the need to print your full license details down the side of every single page. You’ll need to be downright persistent to even make it past page 1 as a legitimate user, which is sad considering it’s otherwise interesting content.