Introduction
Most projects go wrong due to lack of control, poorly defined requirements, unrealistic targets and scope creep. This paper looks at the control side of any project. Lack of control generally stems from not managing to a project plan, however even projects that are managed against project plans can and do go wrong, generally because the plans are drawn up prior to the analysis and design stages and are not revised to account for the new information that comes to light during these stages, or relevant stages are completely missed out. As mentioned in other papers in this series, it is important to produce a good project definition document along with good requirements definition, but it is also imperative to update any plan with new information arising from these tasks.

Overview
Most projects will go through the same stages or life cycle, there is a small difference between bespoke development or package implementation, mainly that additional stages are required with package implementations, that of evaluation and instillation. Generally an organisation will have a preferred development route with respect to package or bespoke development, thus deciding which route to take. The project life cycle is listed below:
 Project Definition
 System Requirements Analysis (Functional Design)
 Package and or Bespoke Evaluation
 Package Acquisition & Installation
 Package Solution Definition / Bespoke Design
 Architecture & Infrastructure Definition
 Technical Design
 Integration Testing
 Procedures & Training
 UAT
 Transition

These stages are listed out into more detail below outlining the main tasks that need to be undertaken. This is not an exhaustive list and you may need to supplement this with specifics for your particular project however it is good starting point.

Experience
Experience indicates that a good detailed plan is essential to manage a project against. Also there is never enough up front analysis, especially in the majority of package implementation projects, these tend to go off the rails because not enough time is spent in determining the gaps between the business process, required functionality and the package at the early stages, all too often these gaps arise later in the project costing both time and money to resolve. There is always too much emphasises on development rather than what is needed to be developed.

To see a table of project stages the detailed tasks, and associated or expected deliverables visit www.mynon.com.

Note that while some of these tasks are obvious and may go without saying, I have known them to add considerable time projects (mainly because they were not started soon enough or thought some other team was managing them) and thus I prefer to leave them in. A good example of this is procurement of a development environment.

Conclusion
The plan should be produced out of the project Charter phase. This is the most important phase, as it not only formulates the plan to manage against but also lays out the scope, success and failure criteria and the roles & responsibilities of the project members. It provides the basis upon which to manage the project against. The other important area that is often overlooked is the analysis, of the existing process flows, functionality and data.

It is always best to start any plan sessions with more tasks, and combine or if appropriate remove them later rather than to add forgotten tasks at a later stage.

2001 Mynon - all rights reserved
--
gfeakes