Moving forward with any type of work without enough detail is a scary endeavor. I don’t like to go to the grocery store for my wife without first checking the list twice and asking questions before I ever get in the car. Why? Because I have such a big reputation for calling her 5-10 times from the grocery store and I want to change that reputation and appear like I can deliver the goods successfully.
The same should hold true on the projects that we manage. When we are done planning, we want to move into design and development with the scope well defined. Because questions raised at that point can mean costly rework – not just a phone call home to your wife. One frustrates your significant other. The other frustrates a paying customer who has a say in the success or failure of the project you are managing.
I think I can safely say that I have never – in 21 years of managing technical and creative projects – felt completely secure in the level of detail we have defined in the requirements that are documented for the effort. I am not sure that any project manager has been ever – or should ever be – comfortable in the level of detail of their requirements. But there is no question that at some point you have to say, “Ok, we are done with requirements, let’s move on.”
So, how do you know when requirements have been captured in enough detail? How do you know that enough is enough? How do you know that what your team and the customer have documented representing project requirements are going to result in a workable, usable end solution? The answer is: you really don’t. And nearly every project experiences some requirements shift or change during the engagement – sometimes resulting in change orders.
What I’ve found is that there are indeed a few questions you can ask – likely best done as a group meeting when you ‘think’ requirements are complete – that will help you figure out if you’re there yet…or if you’re even close. Think of these as sort of a litmus test for your project requirements.
Will my project’s requirements make sense to those shaping the solution?
Remember, these requirements are going to be handled by multiple individuals who are going to take them and develop a solution from them. Think of them as the blueprint for your house. Could you see yourself living in the final product? Do you trust that they are complete enough to tell multiple individuals of slightly varying skill levels what to do based on the information they contain? Centralize it and make it personal – ask those tough questions.
Do my project’s requirements help answer the question being asked?
As a whole, do these requirements answer the problem, question or issue of the project? If the project is for a new customer relationship management system, do they tell you what is needed from the new solution? Are key pieces missing? Will the proper customer data be captured by the new CRM system as a result of these requirements you have documented so far? Are knowledge gaps closed by utilizing these requirements?
Are my project’s requirements accurate?
Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct.
Can stakeholders understand my project’s requirements?
Show the documented requirements to all your stakeholders – or at least the key ones…your team, the customer, and a few others that have significant tie-in like the planned end users. Get their buy-in. Do the requirements make sense to them? Granted, you and your team will be held accountable no matter what they say - and you’re the expert, not the customer. However, getting feedback from them is still important and can potentially uncover some missing requirements. You might hear, “What about the report that we need every week to report up to management.” Yes, a report that executive management is expecting would be a bad thing to omit.
You could expand the requirements documentation phase out forever – no question about it. There could always be more detail. But you do have to move forward at some point and say enough is enough. You aren’t being paid to continually document requirements – you are being tasked to deliver a product or project or some type of end solution. So make sure your requirements answer these questions before moving on, and then proceed into the next phases of the project with confidence…and one eye on scope management at all times. Because there is always the chance that you missed something – early detection will help mitigate some very damaging results in terms of dollars, timeframe and rework.