Someone once said (and I forget who it was) that the downside of great project management is that it can simply accelerate disaster. The point of this comment is not that there is anything wrong with project management, (in fact of course its indispensable) its that if the end product is flawed or poorly defined - project management isn’t going to be a panacea.

I think that there is a lot of faith put into PMI style rigor and discipline - almost as though constant attention to detail will enable the team to see and act with great wisdom - with method as the “saviour”. Indeed I have seen via constant, in fact daily, conference call meetings - teams finally realize substantial disconnects in their project. This pesky persistence can work - but its very inefficient, painful and sometimes embarrassing. I would like to suggest a way to add value to project management so that the right things are being driven towards completion.

The following is a practical approach to apply the Common Computing Framework to best practice project management techniques (also for analysts who are defining projects). By making this a simple checklist of questions (mostly yes/mostly no)- a project charter basically will or will not satisfy an appropriate set of criteria. The reader may challenge this criteria of course - but the reader also needs to understand that this approach is built from the work already completed to date - see the previous post and preliminary results PDF. Feel free to comment back on this too!

In essence everything depends on the scope of the exercise - and in my opinion this is where most projects fail - at the beginning.

Consider the following checklist questions for any project you are approving or participating in -

Scope Questions-

• Are the requirements documented separately from the Service scope? [The service is a business and technical proposition which sits apart from the documented set of needs]
• Does the service scope have people,process and technical components (it probably should)? Is there a really clear picture of what the service does - ie its outputs and value propositions?
• If this is purely a technical IT project is it clear what the technology does vs the people and process components of the overall service?
• Is the scope of the work in the project that needs to be done separate from the target scope of the technology?
• In all or any of the above are the scope definitions mostly in text or are there clear diagrams that help to clarify or at least demystify what is being constructed? (watch out for acronym/jargon rich statements)

Now some would argue that project management makes this iterative - ie that the work itself in the early stages is to determine what the service or technology scope will be. I completely agree! Make sure that if this is true that there was /or is a project charter that had a deliverable called “define the service scope”. Then you should be able to inspect that and then the above rules should still be applied.

If you answered “no” or “its not clear” to any of the questions above - frankly I think you may have problems. The purpose of the Common Computing Framework (CCF) is to make crystal clear what it is that is being built and to make very tangible the target deliverables. For instance a set of needs or requirements can be expressed but it is a business decision whether the service will satisfy all those needs . Failure to make the distinction could mean that the business expects all their needs to be met - when in fact only some will be delivered on. In general the more “no’s” to questions above the greater the degree of risk a project has. Significant stakeholder misalignment may exist due to a difference in understanding or varying frames of reference about what is actually being developed or constructed.

In previous work I have often referred to the building business as a useful reference point. Let me clarify that I am not saying an IT system is like a building - I am really saying that architects and general contractors know exactly what they are building - its that lack of specificity that hampers IT projects.

So here is an exercise for the reader …

My suggestion - or even challenge is for you to go and inspect your major projects - look at the charters and scope definitions and ask yourself - “do the words in the document make clear what is being constructed?” Or are they words that have been carefully “wordsmithed” to satisfy multiple interests and stakeholder needs? If you rewrite the charter to truly reflect the distinctions required in the Common Computing Framework - and then review the work being done and find gaps or disconnects - this is a sign that a potential risk review is required (the project might very well appear to be on track - but against what criteria?!).

In the spirit of an open research project - I am interested in any thoughts you have about this perspective - indeed if you are sceptical I would be happy to take a look at some project charters for validation.