The First of 8 Habits of Highly Successful Project Managers: Know Your Outcome!
By Richard Morreale
This article is a part of a series. You can find the previous article here.
The lack of an agreed, properly controlled Requirement is one of the top ten reasons that Projects fail. In fact, some people, including me, believe it to be the top reason that Projects fail. So, what do highly successful Project Managers do to help to ensure success on their projects? They ensure that they have a properly documented, agreed and properly controlled Requirements Document. This article is focused on the importance of the Requirement, the criteria for well defined Requirements, ways of defining the Requirement, ways of handling unknowns, documenting the Requirement, getting it approved and controlling changes to it.
The Importance of Knowing Your Outcome
Having a proper Requirements Document in place on your Project delivers a number of real benefits to you, to your team, to the customer and to the successful completion of your Project.
Probably the major benefit of having the Requirements Document in place is that the Project Team will know what to deliver. There will be very little wasted time associated with having to do things over because they started working on what they thought was wanted before they actually knew what was wanted. In addition, the Requirements Document provide a basis for evaluating, assessing and agreeing changes to the overall Project.
The Requirements Document also helps with getting commitment from both the Project Team and the person for whom the project is being completed. It helps in pulling the Project team together and in ‘rallying the troops’. It helps in the communication process because it provides a common basis for communicating what is wanted and, therefore, what the project is based upon.
And last, but certainly not least, the agreed Requirement provides the basis for the Project Plan. I see no other way of putting a credible Project Plan together without having a definite idea as to what must be delivered.
The Criteria for Well-Defined Requirements
I believe that a well-defined Requirement must be a real document. It shouldn’t just be a loose collection of e-mails, notes, letters, conversations, minutes of meetings, etc. It should be a well-structured hard copy of a document that has been signed off by both the customer and the person responsible for delivery to the customer. In fact, I believe that sometimes it might be worthwhile to have the entire Project Team sign it as a sign of not only understanding but also of commitment.
The Requirement should be prepared by the Customer and presented to the Project Team. However, in most cases the Requirements Document is usually developed by the Project Team with assistance from the Customer. I’m ok with this as long as the Customer supports the preparation of the Requirements Document and signs it signifying agreement that the Document accurately defines what they want delivered and they are committed to assisting the Project Team in delivering it.
Ways of Defining the Requirements
There are numerous ways to define the requirements. These include, but are not limited to, Interviews of the Customer by members of the Project Team, Structured Workshops facilitated by the Project Manager and attended by the Customer and the Project Team, Structured Methods, Prototyping and Visioning.
My favorite way to establish the requirements is to use Structured Workshops especially when you incorporate into the workshop a structured technique such as a modified version of Structured System Analysis and Design Method (SSADM) for documenting the requirement. I have used the Structured Workshop/Modified SSADM technique many times and it has always proven to take less time to get to the Requirements Document than any other way.
Workshop/Visioning is also an excellent way of defining the Requirements especially when the project is for, say, a training course. At the workshop, the facilitator leads the attendees in an exercise where they pretend they are in the future after the training has taken place. The attendees are then asked to identify what is different about the people who attended the training course. What are they able to do now that they weren’t able to do before? How do the act now compared to before the course? The attempt is to define, in detail, as much as possible the difference between now and before the training. The vision that you come up with is the requirement. It is documented and agreed as the final action at the Workshop.
Ways of Handling Unknowns
I am well aware that not every detail of the Requirement is known at the beginning of the Project. However, I believe more of what are initially identified as unknowns are usually known or can be defined with a small amount of effort. In loads of Projects that I have audited, I have found that the unknowns are usually forgotten until they come up later and cause you numerous problems.
The way I handle things when I am told that certain information is unknown is that I push back to make sure that they are really unknowns. Then I ensure that we define the unknown as much as possible. For instance, I want to know exactly what is the unknown? What is the effect on cost and schedule of not knowing the information required? Who needs to provide the information required? Where will it be found? When will we know it? I then document the unknowns in the Management Plan, in the Risks and Issues and, if applicable, in the Project Plan. I make sure that ‘unknown’ information providers are aware of their responsibility and then I monitor the unknowns closely.
Getting the Requirements Document Approved
I never e-mail the final Requirements Document and ask for approval. I make it more formal than that. I might e-mail the Requirement Document around during its preparation for review but when I am ready to have the final agreed I hold a meeting with all those who are going to be required to sign.
I sometimes meet with individuals to explain the importance of their involvement in the Project and to ensure that they understand the requirement, what is being asked of them and what they are committing to by signing the Requirements Document.
When I am ready for approvals I print a hard copy of the Requirements Document and at a special meeting held to approve it I get the applicable people to sign it. I like doing that because I believe that it highlights the importance of the Document and helps to add to the commitment of the attendees.
Controlling Changes to the Requirements
Once the Requirements Document is approved, it should be base-lined and put under Change Control. That way, whenever a change to the requirement is required, it should be assessed in terms of its technical impact on the project and its impact on schedule and cost. Once this is known, the person in charge of the Requirement, normally the Customer, can decide whether to approve the change or not. If they approve the change they must accept the impacts that were identified during the assessments. If affected, the schedule, the budget and the technical aspects of the project must be revised in line with the impacts.
There are a number of reasons why the Requirements Document is absolutely necessary. It forms the ‘contract’ between the Customer and the Project Team in terms of what is to be delivered. It forms the basis for future development work. It is the basis for the assessment of change on the project. It forms the basis for the Acceptance Testing of what is delivered.
Spend the time getting it right in the beginning and it will save you loads of time later.
Richard is a project manager, professional speaker, author and consultant specializing in Project Management, Leadership, Achievement and Customer Service.