Many projects start off as a jumble of inconsistent requirements, a wish list, or as a mission statement. The detailed project requirements need to be teased out little by little, iterating around a what-how-when loop. Sometimes, when development is involved, the detailed requirements can't be known until the project has been running for some time. In such circumstances, the embedding of alternatives in the plan, and the management of risk becomes crucial - a deterministic CPM model is of little use.
A Project - At the Beginning
Many of the decisions that need to be made in the initial stages of as project will determine its eventual success or failure. A decision must be made on the how of the project, perhaps choosing between using a mature technology with a limited life and an emerging technology, with its own spectrum of risk. In its early stages, the project model should include a risk assessment, with outcome, completion and cost risks, so the overall risk can be compared with the cost benefit of the project.
The best way of doing this is to build a model which includes each of the aspects - the what, the how, the when and the how much, then use this model to determine what to do. ORION's ability to represent tentative information and controllable alternatives makes it easy to represent initial uncertainty about requirements. The first stage of the model may only flesh out the mission statement, with no reference to the time frame of the intended project.
A functional model at an early stage allows people to simulate outcomes, aiding the Requirements Elicitation process.
An Example
The example is defence-oriented, but the incremental model building and the inclusion of alternatives which are then pruned away as the plan becomes more detailed are relevant to many other situations.
A Mission Statement
Prevent InterdictionOf Our Northern
Shipping Lanes
This tells us in general what is required, but is far too vague to start planning anything concrete. We need to ask questions, get specifics - how long should prevention last if attacked, what time frame, protection from what - we need to understand the ramifications of the mission statement, its achievability and cost.
| What range |
| What timeframe |
| What hostile technology |
As we get answers to these questions, we can start to build an analytic model of the requirements, discarding technologies which are too far away in capability or availability to be considered. We are already beginning to quantify the concepts in the mission statement.
First Level Of Alternatives
We build up a model which has potential alternatives. Specifying the ranges of available outcomes allow us to show how well the potential alternatives match the requirements. We will need to describe an "acceptability criterion", because each alternative has its strengths and weaknesses, and in the worst case it may be necessary to combine several alternatives to build a satisfactory system if no single alternative is acceptable. There will also be interactions with existing systems and other planned systems to consider.
We fix on a likely alternative and explore that in more depth.
We are not yet planning the when of the project, only the what, the how, and, very roughly, the how much. Unless the project is being built "in-house" , we will need to have all our estimates, of technological possibility as well as cost, validated by the people who will do the work.
The effort expended in building the model ensures that we have sufficient decision support structure to allow us to move to another alternative if our favoured alternative is not feasible.
Tendering
We put our plan out to tender, to have our cost and time estimates confirmed. The tenders received will not usually exactly match our expectations, nor will they be of identical structure, making simple comparisons between them difficult. We can use our model and its acceptability criterion to assess the feasibility and acceptability of the various options proposed.
The initial model has gone through several stages of refinement, from the ramifications of the Mission Statement to a model which can support assessment of tenders, to a model which can monitor and control the project implementation stage.
The ORION Project Model can be used for many purposes throughout the life of the project because the model can encompass analytic descriptions, tentative information, risks and alternatives, and it can be used to analyse the what, the how, the when and the how much of the project at each stage. The emphasis of each aspect is changing as the project progresses, the what dominating at the beginning, changing to the how, and then to when and how much. In contrast, a CPM model has little relevance over most of the early planning stages.
