Would you buy a car or a house without ensuring that it has all the features and amenities that you needed?  So why would you run a project that way?

Do you know what you need?

You are in the market for a new motor vehicle, what do you buy?  You may want a motor bike, but need a car.  You may want a 2-door sports car but need a 4-door family car.  You may want leather seats but need child seats.

Now, imagine that you hadn’t given any consideration as to what type of motor vehicle you needed.  You may have gone to a car dealership, bought an expensive sports car and while driving home realised that you had made a mistake.  When you drive the car back to the dealership you have to ask to trade-in, as the car is now rated second hand, and to top it off, you have to outlay the additional cost for the car you need.

These types of errors happen often, especially in projects, because we don’t invest the time to understand what it is we really need.  Requirements need to be documented to ensure the project delivers the business benefits stakeholders are expecting.

The optional extras checklist

You are with the car salesman and have agreed on the car you are going to buy and the price you are going to pay.  You walk inside to complete the paperwork when you are asked to consider a range of optional extras – GPS, paint protection, sunroof, and leather seats.

Now imagine the car salesman had just added these optional extras on the purchase order without your authorisation.  What would you have done?  Would you have signed the PO because you just assumed he put the right information on the order, or would you have read the PO and picked up the mistake?

When it comes to projects, stakeholders need to take accountability for what the project is delivering to ensure that the planned benefits eventuate.  Stakeholders need to:

• Review the list of requirements
• Ensure that each requirement has a traceable link to a project / business objective
• Sign off on the requirements to validate and confirm the deliverables

Imagine what you could receive if you don’t read, review and sign the requirements document.  You may end up having to invest in the project for a second time in order to achieve the original objectives.

Have you ever experienced a project which didn’t deliver the anticipated benefits / requirements?

By Gary Rubinstein – Practice Principal – Revolution IT