Develop Your Project Requirements with Four W’s
Reading time: ~ 5 minutes
From time-to-time, prospective clients will ask us for an estimate, and we ask them if they have any project requirements documented. Usually, they do… but 20% of the time… they don’t know where to begin.
Are you in the 20%? You need to develop some project requirements because you want an estimate from an agency, like us. And you don’t know where to begin (or what you’re being asked for).
In this post, I’ll explain what a requirement is and why it’s important. Then I’ll help you build a requirements document by providing a list of questions you should answer. So the next time you are asked for your project requirements, you are 100% prepared.
What’s a requirement? And why is it important?
A project requirement is a defined objective(s) that must be met for your project to be considered successful. It’s a list of all of the goals that you/your team have compiled in terms of “what is needed” – from the most basic needs to the more complicated goals.
To get an estimate of work, there needs to be some sense of scope (ie. what is it that we need to deliver). And that is best defined by specific requirements that must be met in the project.
Project Plan vs Project Requirements
A project plan communicates to stakeholders what the entire project encompasses, from the goals of the project to the approach the team will take to meet those goals, to the time it might take to complete. It is a way to formally agree upon the project scope, deliverables, and timeline and is used to manage expectations throughout the project. The project requirements is one small part of the larger plan.
Please note: don’t go through the trouble of trying to put all the pieces of a project plan together before you talk with an agency, as you’ll want and need to decide some of these things (especially approach, priorities, and estimates) with the team you’ll be working with on the project.
Requirements vs. Specifications
Specifications are more of the “how’s” to a project. That is, how are we going to meet those requirements in design? How should a user interact with the application? How should we build this in code? Specifications allow each team from design to development to provide detail in their deliverable, beyond broad objectives, so that it provides a clear guide to the rest of the team and to stakeholders.
Requirements does not mean prescribed work to be done
One quick note, a good partner will use your project requirements to give you an estimate in terms of what it might take – so you have the ballpark amount. However, a good partner should RARELY (if ever) just take your requirements and run with it.
The reason being is that a partner should want to understand the need, goals and objectives before they are prescribed what to do. They should want to understand the root problem the product is meant to solve. And they should challenge that – and use that start to define the approach to take. It may turn out that your requirements aren’t enough, or aren’t really solving the real problem. A true partner would be able to uncover that and suggest a more suitable approach.
If you want someone to just translate your thoughts into code, there are vendors out there, for sure. But if you want an agency that can work with you to determine the best, sustainable product then you should expect that discovery period and expect to step back and reexamine the project so that you are certain you are taking the best step forward.
Let’s get started on your requirements
To help provide context, let’s imagine a scenario that we’ll use to walk through this.
Imagine you are a florist and you want to increase your web presence and provide an online store and shopping experience.
To build your requirements document, you can use four of the five w’s for basic information gathering: who, when, why, what.:
1. WHO are the Stakeholders on your side?
This means, who will be involved in the project and what is their role. These are the people who will help you make decisions and have a voice at the table. This is especially helpful if there is a third-party team working on part of the project.
For example, a stakeholder might be your co-owner at the shop, or your store manager who keeps track of inventory. If you have an in-house developer who helps with your website and will be pairing with a development agency. For third-parties, say you hired a branding team to help you with some marketing materials for your flower shop. Or you hired a content team to help you with writing copy and writing blog articles.
An agency reading your requirements would want to know the scope of their work in regards to the full project, and knowing other teams and users that will be providing input or might be involved in the project (like the developer) will provide more clarity on what’s needed.
2. WHEN do you need this?
This is self-explanatory, but sometimes clients will forget in these early meetings to mention what really drives the date.
Let’s say you are trying to get your shop up before the busy holiday season, and would like to have the site up by November 15th. Or, perhaps you are receiving community funding and you need to have something to show by the end of fiscal year.
Having a realistic idea of how long something might take but also being mindful of any extrinsic dates that might be affecting this project is helpful for your requirements, as it provides context and allows the agency to work in some options for you.
3. WHY do you need this, ie. what is the purpose and scope?
When you answer the purpose and scope, you are answering what is the service need, and how does this project meet that need, at a higher level. This is like the elevator speech if you had to get approval for your project. What are you trying to do and why?
For your flower shop, this could be:
Our current website was created two years ago and was just a marketing site giving customers an overview of what we do and where we are located. We’ve since increased our product line, and are able to offer consistent services, we need to give customers the ability to view and order items for delivery or store pickup. We are currently looking at a subscription model, as well, for monthly delivery. Additionally, we need to optimize for mobile, as the site currently does not work well on a mobile device.
4. WHAT are the current Requirements that this project must meet?
Here’s the bulk of what is needed; the requirements of the project. Here you’ll list out the product and user requirements that must be met. You can break these into chunks like:
User Requirements: What should a user be able to do or see when interacting with your product?
For our example, things like:
- A user must be able to view flower arrangements
- A user must be able to purchase a product
- A user must be able to select a monthly flower package
- An admin must be able to add new flower arrangements
- An admin must be able to add promotional content
This gives a preliminary scope of what needs to be designed and developed.
Technical requirements: How should the product be created? This would be any requirements to how the product might be implemented.
For example, the site must:
- support for the latest non-beta release of Chrome, Safari and Firefox as well as IE9 and above, etc
- be optimized for mobile
- be integrated with third-party billing software
- be integrated with store inventory software
- support and manage access roles, which control permission to view or modify data
Keep it short and simple
While there’s a couple of questions to answer, you don’t need to be verbose in your project requirements. Remember, this is just the starting point to get some ballpark “guesstimate”.
And the likelihood of requirements not changing along the way is slim. So don’t spend days crafting a bulletproof plan. Just organize your thoughts in a way that someone else could read the summary and get the gist. Once you move forward, you can deep dive into all of the information and flesh out the project and build a roadmap for how you will get it all done.
One last time, use the 4w’s
So, when you are asked for a project requirements remember the four questions to ask yourself:
- Who’s involved?
- When do you need it?
- Why do you need it?
- What do you need?
Then leave the “how” to your project plan, to be created with all partners on board.
Good luck!