April 18, 2011 by in Technical Documentation
Having clearly defined requirements in-hand at the start of a project may seem like a no-brainer, but it’s important – I can’t emphasize it enough. It makes me cringe to think about the projects I’ve worked on that didn’t have any real requirements to begin with—once or twice it was so frustrating that I found myself thinking about throwing my laptop out the window. Sound familiar? And to think that some of that frustration could have been avoided if I had just insisted on business requirements…
The degree of clarity with which business requirements are defined and communicated to all parties involved in a project can set the tone for the entire project. Poorly defined or nearly non-existent requirements can translate into days of frustration, not only for those working on the project but also for the stakeholders. Clearly defined requirements help establish and maintain a solid target throughout a project; poorly defined requirements can make me feel like I’m banging my head against the wall.
Not only does having a set of clearly defined requirements from the start of a project help minimize wasted time and frustration; if developed correctly, requirements can help ensure an organization maximizes its return on investment. The clearer the business requirements, the more streamlined a project can be, and the less waste there is in terms of time and resources. As all of us know, it all comes down to profit.
Determining Requirements: For Customers
The successful outcome of an envisioned product or service is far more likely if you and your colleagues are able to clearly communicate and capture the statement of requirements before any work is started. The power of clear requirements should never be underestimated, nor should the task of defining them be taken lightly. The following steps can help you craft an effective statement of requirements.
- Identify the “moment of inception”—that is, how the need for this product or service was identified. Doing this will help put things into focus.
- Revisit your organization’s goals and objectives and determine whether and how the proposed product or service aligns with big-picture goals and objectives.
- Keeping in mind what you have learned during the previous steps, briefly capture what the desired outcome is—you now have your draft statement of requirements.
- Ensure that all stakeholders have bought into and signed off on the requirements before communicating them to whoever is responsible for developing the product or service. Failing to get buy-in from everyone involved before any work is completed could lead to wasted time and resources later if someone steps in with a different view on what should be done.
Determining Requirements: For Service Providers
Believe it or not, the customer is not always going to have a clear idea of what they want. It may be up to you as the service provider to lead the way.
Keep in mind that it can be especially tricky to help a customer determine requirements if there is more than one decision maker involved – it’s best to ask up front for a primary point of contact who can also serve as the ultimate decision maker. If you don’t do this and there are too many cooks in the kitchen, days can be spent trying to get everyone to agree on requirements—believe me, I have been there and it’s not pretty. I often use the following steps to help capture a solid set of requirements.
- Conduct background research on the customer organization to learn about their overall mission and goals.
- Do some investigating to find out what sparked the need for the product or service.
- Capture in writing what all stakeholders (customers) want or desire with regard to the new product or service. Contact people individually if at all possible. If you weren’t given clear requirements to start with, it’s likely that the stakeholders are in disagreement or aren’t communicating. Proceed with caution.
- Insist on being assigned a single point of contact who can serve as the final decision maker—this is something you may be able to “feel out” when talking to each of the stakeholders individually.
- Based on your knowledge of the organization’s overall mission and goals, and on the information collected from each individual about their desired outcomes, compose a brief sentence or two – this is the draft statement of requirements.
- Submit the draft statement of requirements to the previously identified point of contact and ask for sign-off/approval on either this version or a modified version by a specific date and time. Let this contact present the requirements to all necessary parties and field any disagreements.
- Iterate on the statement of requirements as needed and whatever you do, do not begin work on the project until the requirements are firm, agreed upon, and included in the statement of work.
After having read this procedure, you may be thinking, “Well, this just sounds like the same old ‘bring me a rock’ scenario.” There’s no point in trying to convince you otherwise—it is. (“Bring me a rock” is a common euphemism for bringing a “best guess” to the table when the customer isn’t really sure what the requirements are or should be yet.) Only here, you are limiting the “bring me a rock” scenario to a statement of requirements—not an entire redesigned website that is completely turned upside down because the business requirements were never clear from the start and management disagrees about what’s most important to capture on the home page. That’s what happened to me and some former colleagues. I’ll admit, I wasn’t always real assertive about getting those requirements up front—not the case now. I believe life is too short for such agony.
What’s the most important takeaway message here? Don’t underestimate the power and importance of having clearly defined business requirements before any work on a project begins. Also, requirements are not always going to come from the customer—customers aren’t always clear on what they want and may need some coaching from the service provider to figure things out. Don’t be afraid to invest time in developing clear requirements up front—it could end up saving countless hours and who knows how many headaches later on.
Clear requirements make for happy projects!