Do IT projects all proceed following recognized laws of physics or engineering? Sadly no: often crucial analysis steps are left out, leading to cost overrun or outright failure.
Agree on WHY the project is happening
A project’s Business Requirements identify and record why the project is important in business terms, even as briefly as a two-sentence description. It need not take months (or hours) of analysis time.
Agree on WHAT the project shall accomplish
The Functional Specifications transforms why into a general statement of what needs to be accomplished. Still independent of ‘how’. The project document can be mere sentences – the amount of analysis process always should decrease or increase so that it’s appropriate for the current project.
Work out HOW the project will do it
Functional Specifications next give rise to the Technical Specification or even the Build Stage. How are you actually going to carry out this project? Here, sadly, is the common starting point for many projects – bypassing the Business Requirements’ statement of goals.
This linked article describes the mechanics of this project planning process in the context of Costs containment for IT projects.
Translate business requirements into functional specifications
The parties should translate the business requirements into functional specifications. This may be done in two ways. Initially, the parties should determine whether the ‘out of the box’ solution is appropriate and the offered solution is close enough to the client’s business requirements to be implemented as is. Alternatively, a more costly approach would be to complete a fit gap analysis and…
sourced August 30, 2011 from Costs containment for IT projects Publication of International Law Office by BCF LLP
2 thoughts on “Why, what, and how – project control for IT”