Why, what, and how – project control for IT

Why, what, and how – project control for IT

Why, what, and how – project control for IT

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”

Leave a Reply

Your email address will not be published.