Scoping Projects for Risk to Inform Selection of Project Management Methods

It's common these days to hear of "agile" developments for IT projects - agile meaning, quick set-up, quick to get to the coding stage and an iterative approach to specification, development & testing. Organisations however, often still rely on more formal methods "Bid Design Up Front" commonly referred to as Waterfall methods, where one stage commences only once the previous stage finishes, so coding and design never overlap. How do organisations decide which method to use and is there scope to support both approches in the one organisation?

Apparently, if you stand on top of the Great Wall of China, you can see the moon - Boothby Graffoe

Formal methodologies usually require some form of feasibility study to senior management with a go/no go option on the development based on Return on Investment and do-ability. There is an option, however, to look at the project and quickly scope out the risk & value profile at a high level and inform the decision on methodologies, and if this points towards agile methods, restricting the effort required for feasibility and saving the organisation time and resources

How to Scope for Risk and Value up front

To be "Agile" in this step requires the Scoping exercise to be shift yet valuable and this requires its own methodology - Navigator - which is designed for Risk and Value management of individual projects, programmes and indeed an entire portfolio of development efforts. At a simple level Navigator allows a consultant to make an informed decision on the route the project should take. This is based on easily accessible information (which is expanded in greater detail as programmes progress) and presented in a simple and easy to digest format. Perfect for indication agile or formal.

There are about ten risk "markers" and about ten value "markers" but for this article I will examine the threee of the most common. Firstly, on the risk side we have: 1. the number of stakeholders, 2. assumed complexity of the mission, and 3. expected duration. For instance, imagine a project such as the replacement of premises based IVR systems in two call centres with one hosted IVR system serving both centres. Using only the three risk markers above, likely this project has one stakeholder - the head of customer service delivery, likely has low to medium complexity (the new system can be tested and tested without removing the old ones) and the duration is likely to be relatively short - three to six months. This data would lean the project towards agile methods. On the other hand, imagine a project to upgrade call centre applications to provide better integration with the rest of the busines. Immediately, this brings in other stakeholders - finance, branch networks, marketing, etc. It's also likely to be highly complex as interfaces between systems and division are often where trouble lies in project management and the duration is likely to be medium to long. This data would lean the project towards formal methods with a high degree of planning and consultation prior to development.

Without delving into the mathematics behind the risk assessments, one can see there is a relationship between, say an increasing number of stakeholders and an increasing risk of a project missing some of its objectives, due to the way conflicts are resolved in organisations.

The above examples are fairly obvious for the purpose of illustration but what Navigator does is allow value and risk, which are intangible elements to be deconstructed and given tangible £ values. The elements in a project can then be aggregated and compared, on an equal footing with all projects in the portfolio regardless of the asset class they serve.

Having risk and value assessments over an entire portfolio allows senior IT staff to accurately manage risk and be assured in delivering the value. They can also easily decide which projects to fast track through agile methods and which to manage through traditional methods.

Note: Navigator is a decision support methodology for enterprises to use to align business technology decision with business goals and to keep this relationship in lock-step as the business evironment changes and the portfolio evolves. Navigator is the property of the author.

Copyright 2007 Robert A Innes