How to Deliver a Successful Project – Part 2 – Start It By Defining THE Business Requirements

Posted in: Blog, Methodologies, Project Delivery | Jan 11, 2013 at 7:32 PM

No comments

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

START IT BY DEFINING THE BUSINESS REQUIREMENTS

First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE!

Throughout my career in IT, I notice that defining the scope is the initial step that is often either missing or not done properly. Before I even go into the details, let me emphasize: A PROJECT WITHOUT A CLEAR REQUIREMENTS WILL FAIL! My definition of a successful project can be found in the first part of this series.

What is in the business requirements?
– Project definition (what it is);
– Deliverables (what the client is getting);
– In-scope and out-of-scope items (the boundary);
– The actual business requirements (how the project should run).

Let me give you an example:

I realise that in life, every activity we do is a project. For example: cycling. I love cycling and I commute to work almost everyday. For me this is a small project. How come? Think about it: Based on the definition above cycling truly fits the criteria:
– Project definition: Tommy is working at company ABC and he needs a method of transport to get to the office from home.
– Deliverables: Arriving at the office by 930am.
– In-scope items: A method of transport on road.
– Out-of-scope items: A method of transport off road (eg. air such as planes).
– The actual business requirements: Tommy does not want to spend more than $5000/year on transport costs; Tommy does not want to spend more than 1.5 hours one-way to get to the office; Tommy does not want to wake up any earlier than 7am.

You can name other scenarios such as looking for apartments or houses to rent or picking up your friends and families at the airport or planning a wedding. As long as something has a timeline: it’s a project.

From my experience, in order for me to deliver a successful project, I have to first define a clear business requirements. The idea of defining business requirements is for both parties (you as the person delivers the project, and your stakeholders) understand what you are all getting at the end and how much effort required.

I have been at many client engagements where a deadline has been set without first defining the business requirements. This is very dangerous. How do you know if you can meet the deadline without defining what is required? In the cycling example above, without me defining the requirements, I could have woken up at 4am in the morning everyday if I need to arrive by 930am and I live 100km from the office and still choose cycling as my method of transport.

It has always been human’s nature to ask this straight away: “Can you do this by this date?” or “How long is this going to take?”. In fact, it is often the question that was asked by the client. However, we as the project deliverer we need to be cautious enough to say, “Let me get back to the office and re-think about it and I’ll get back to you with the actual hours required”. NEVER mentions any dates or number of hours before you are defining the actual business requirements.

WHAT IF THE CLIENT DOESN’T KNOW WHAT THEY WANT?

Scoping or defining the business requirements are also often difficult. Sometimes when the project is so big, client is confused himself  (ie. doesn’t know where to start). The way to deal with this scenario is by YOU (as the project deliverer) defining the scope for them.

For example, I’m helping out my mom looking for cars to buy. Initially my mom wouldn’t know what car she wants. Me as the project deliverer would define the scope for her by asking, “OK I’ll start with this question: Do you want a car with sunroof?”. She may say, “No, I don’t”. Then that’s THE scope. I will say to her, “OK for the first phase of the project, I will make you a list of ALL cars that don’t have sunroof. It will take me 3 days to write up the list. Let’s just do this first then we can talk about the next phases”.

See, it’s all clear! The client (mom) knows exactly what she is getting, you as the project deliverer has a clear scope of delivery.

In IT for example, let’s say you are about to begin an Intranet project and the client doesn’t know what they want. He/she may say, “I really don’t know what I’m looking for in an Intranet”. That is OK, let’s define a scope for them. I’ll say this to them, “OK, what I will do, let me create a homepage and a content page. I will choose the colours and designs based on your logo and branding. Then I will present this to you and we’ll go from there. How about that? This will be our pilot project and it will take me about 1 week to do it”.

There you are! That’s your scope, deliverables and business requirements.

You just keep doing the same for every phase of the project.

CONCLUSION

Never, ever starts a project without a clear scope, deliverables and business requirements. Your project is only doomed to fail if this is the case. Without a clear scope and requirements, you will find a lot of scope-creeps (ie. out-of-scope items that are introduced along the way) which will eat a lot of your project time. I will talk more about this in the next series.

No Comments Yet.