Bad requirements or no requirements are definitely not the best way to start any technical project. But most project managers will tell you that you aren’t likely to get your best requirements from your project customer – no matter how certain they may be that they have thoroughly documented everything for you. The problem is, some project customers aren’t even certain they know the right problem or need that the project is going to be addressing for them. In those cases – and that’s often from my experiences – there is no way a project client could have good, detailed requirements waiting for you. They don’t even know the real problem yet…they’ve likely only documented a symptom.
The bottom line is this - customers are not often known for providing good requirements for the solutions they are seeking from our project teams. Ideally, customers would have met internally with their end users and subject matter experts (SMEs) to determine exactly what the problem is, what the real project is, and at least what the high-level requirements are that need to be met by the project team as they develop and implement the solution. In reality, those end users are all to often overlooked leaving us to roll out a solution to them that may or may not help them to do their jobs better. And if it doesn’t solve the need – no matter how we point our fingers, it is us who have failed the project customer…not the other way around.
In order to get to the point where the project team knows what needs to be done and exactly what is expected of them, a few steps must happen. From my experiences, I’ve narrowed it down to a the following four key steps or processes we must go through as a project team when working with our customer in order to get a good handle on real requirements and produce a working end solution for the critical end users…
Let’s look at each of these in more detail…
Get initial requirements from the customer at project initiation
Like it or not, our starting point needs to be whatever our project customer can supply us in terms of project requirements. We can’t run with these, but cause they likely aren’t going to be complete enough to serve the need of real, complete, detailed requirements. Be definition, in order to be a good requirement, it must be unitary (define one thing), complete, consistent, non-conjugated, traceable, current, unambiguous, specify importance, and be verifiable. We may get there with the help of our project client – we have to – but it’s not likely that our client will get there on their own.
There’s no way the project manager can know how ready the customer is with their true project request until he sees what preparation they’ve already put into the engagement. Plus, knowledge of the customer’s preparation status is absolutely necessary to adequately map out a project schedule and how much time the planning phase is going to require – something that is a critical input into the project kickoff session.
Kick the project off formally and set expectations
With all customer pre-project preparation information in hand, the project manager is now ready to put together a draft project schedule based on this information and any information obtained at the handoff from sales to project management. This usually includes the statement of work, original estimate, assumptions, and planned resources at a minimum.
Once the project manager has the draft project schedule ready, a kickoff agenda in place, and a formal presentation prepared, the kickoff meeting needs to be held with the customer and the customer project team. This is the meeting where expectations are set, the schedule is reviewed and agreed upon, deliverables and milestones are finalized, and the final project planning gets set in motion.
Define detailed requirements with the customer
Following the project kickoff meeting, the project team will work with the customer on further project planning activities. The key activity is detailed definition of the project requirements including asking the right questions of the customer, customer team, and customer SMEs and end users to truly identify what the real needs of the project are. That’s the only way that the project team can effectively identify the detailed requirements for the customer and the only way they can confidently embark on developing a project solution that they know will meet the customer’s end user needs once the solution is deployed at the end of the engagement.
Track requirements with a traceability matrix
As I’ve stated, documenting accurate, detailed requirements is important, but that’s not the end of the requirements work. The best way to both document requirements and then to know that those requirements have been built in to the final solution is to create a requirements traceability matrix. This becomes a living, breathing matrix for the rest of the engagement. It will be created in design, updated in development to show where each requirement is built in to the solution, checked in testing and user acceptance testing to be sure all functionality works, and then signed off by the customer as part of system acceptance at deployment.
Summary
Requirements are the lifeblood of the project. Bad requirements = a bad project that usually involves much rework, a blown budget and timeline, and usually ends with a dissatisfied customer and a frustrated end user base. That’s bad…obviously. These four steps or actions are not going to guarantee success or that you even have great requirements to work from. Projects fail, requirements change without us realizing it, and customer systems are often complex meaning it’s not easy to capture good requirements every time. It’s our responsibility as project managers to build adequate time into the project timeline and budget for planning and defining project requirements – thus ensuring better footing as we try to move beyond planning into the real work of designing and building out the customer solution. Plus, good and detailed requirements makes user acceptance testing easier (and better) which also serves to ensure those end users are getting what they need in the long run.
By understanding the real issue or issues, documenting detailed requirements, and then tracking those requirements through a traceability matrix to ensure they are built in to the design of the solution, then the project team can be confident that the customer’s end users will receive a solution that they can productively use. The end result will be a successful implementation and a satisfied project customer.
The bottom line is this - customers are not often known for providing good requirements for the solutions they are seeking from our project teams. Ideally, customers would have met internally with their end users and subject matter experts (SMEs) to determine exactly what the problem is, what the real project is, and at least what the high-level requirements are that need to be met by the project team as they develop and implement the solution. In reality, those end users are all to often overlooked leaving us to roll out a solution to them that may or may not help them to do their jobs better. And if it doesn’t solve the need – no matter how we point our fingers, it is us who have failed the project customer…not the other way around.
In order to get to the point where the project team knows what needs to be done and exactly what is expected of them, a few steps must happen. From my experiences, I’ve narrowed it down to a the following four key steps or processes we must go through as a project team when working with our customer in order to get a good handle on real requirements and produce a working end solution for the critical end users…
- Get initial requirements from the customer at project initiation
- Kick the project off formally and set expectations
- Define detailed requirements with the customer
- Track requirements with a traceability matrix
Let’s look at each of these in more detail…
Get initial requirements from the customer at project initiation
Like it or not, our starting point needs to be whatever our project customer can supply us in terms of project requirements. We can’t run with these, but cause they likely aren’t going to be complete enough to serve the need of real, complete, detailed requirements. Be definition, in order to be a good requirement, it must be unitary (define one thing), complete, consistent, non-conjugated, traceable, current, unambiguous, specify importance, and be verifiable. We may get there with the help of our project client – we have to – but it’s not likely that our client will get there on their own.
There’s no way the project manager can know how ready the customer is with their true project request until he sees what preparation they’ve already put into the engagement. Plus, knowledge of the customer’s preparation status is absolutely necessary to adequately map out a project schedule and how much time the planning phase is going to require – something that is a critical input into the project kickoff session.
Kick the project off formally and set expectations
With all customer pre-project preparation information in hand, the project manager is now ready to put together a draft project schedule based on this information and any information obtained at the handoff from sales to project management. This usually includes the statement of work, original estimate, assumptions, and planned resources at a minimum.
Once the project manager has the draft project schedule ready, a kickoff agenda in place, and a formal presentation prepared, the kickoff meeting needs to be held with the customer and the customer project team. This is the meeting where expectations are set, the schedule is reviewed and agreed upon, deliverables and milestones are finalized, and the final project planning gets set in motion.
Define detailed requirements with the customer
Following the project kickoff meeting, the project team will work with the customer on further project planning activities. The key activity is detailed definition of the project requirements including asking the right questions of the customer, customer team, and customer SMEs and end users to truly identify what the real needs of the project are. That’s the only way that the project team can effectively identify the detailed requirements for the customer and the only way they can confidently embark on developing a project solution that they know will meet the customer’s end user needs once the solution is deployed at the end of the engagement.
Track requirements with a traceability matrix
As I’ve stated, documenting accurate, detailed requirements is important, but that’s not the end of the requirements work. The best way to both document requirements and then to know that those requirements have been built in to the final solution is to create a requirements traceability matrix. This becomes a living, breathing matrix for the rest of the engagement. It will be created in design, updated in development to show where each requirement is built in to the solution, checked in testing and user acceptance testing to be sure all functionality works, and then signed off by the customer as part of system acceptance at deployment.
Summary
Requirements are the lifeblood of the project. Bad requirements = a bad project that usually involves much rework, a blown budget and timeline, and usually ends with a dissatisfied customer and a frustrated end user base. That’s bad…obviously. These four steps or actions are not going to guarantee success or that you even have great requirements to work from. Projects fail, requirements change without us realizing it, and customer systems are often complex meaning it’s not easy to capture good requirements every time. It’s our responsibility as project managers to build adequate time into the project timeline and budget for planning and defining project requirements – thus ensuring better footing as we try to move beyond planning into the real work of designing and building out the customer solution. Plus, good and detailed requirements makes user acceptance testing easier (and better) which also serves to ensure those end users are getting what they need in the long run.
By understanding the real issue or issues, documenting detailed requirements, and then tracking those requirements through a traceability matrix to ensure they are built in to the design of the solution, then the project team can be confident that the customer’s end users will receive a solution that they can productively use. The end result will be a successful implementation and a satisfied project customer.
RSS Feed
