So you’re about to start a project to build a new website. And by website I really mean any digital property, such as an ecommerce site, intranet, mobile app, etc. Where do you start? Everyone usually wants to jump in the water and start building right away. But, build what? And why? These are critical questions that will help you compile a roadmap for your project. Roadmaps begin with fundamental high-level business objectives and end with a clear path for development. Below are the five steps to use to build that roadmap for your web development project.
1. Document Your Business Objectives
Treat your business objectives as your bible for the project. These should be high-level, project business objectives, i.e., the business reasons for the project, which should come from the primary sponsor of the project and the various stakeholders and can be distilled from interview sessions at the very start of the project. These objectives should be written in business vernacular, so that anyone in the organization can understand their meaning. Normally, you should have between three to seven objectives for any given project. Once the objectives are defined and approved by the sponsor and stakeholders, every aspect of the project should be tied back to the overall objectives. Each Functional Requirement (see step 2) should connect to one or more objectives. This is a good test of the requirements: if it doesn’t meet an objective, it should not be a Functional Requirement. The rest of the project will flow from them, from UX and creative through development and test cases. You should also be able to determine your Key Performance Indicator (KPI) from the objectives. These also should be directly tied to one or more objectives. Your KPI should be used to determine your measurements for success of each objective. Therefore your success is based on your objectives.
2. Document All Your Functional Requirements
The next step is to document all your high-level functional requirements—the “WHAT” your project needs to do. They usually are written with the opening phase of “The system shall” or “The website shall." Similar to writing the objectives, functional requirements should be high-level and in business vernacular, so that everyone working on the project understands their meaning. Requirements should be succinct—don’t make them about more than one thing.
Requirements are not the “HOW” something will be implemented. Those details should be left to design and architecture discussions. But, sometimes for practical explanation, a note of “how” can accompany the requirements (but not be part of the requirements).
As noted above, all functional requirements should support a business objective. Now, that’s a nice little bow around this project.
3. Prioritize and Add Additional Data Elements
Now that all the Functional Requirements are defined, it’s time to add more data to them. Since there can be hundreds of requirements, this is a good point in time to categorize them. For example, if you are building an ecommerce system, you might use categories like product display, product recommendations, cart functions, checkout process, etc.
The next vital piece of information is the prioritization of the requirements, which should be set by the business team and approved by the project sponsor. Use simple priorities like high, medium, and low, where “High” is a must have. Use this scale: “High” requirements are critical to the business activities; “Medium” requirements are important but not a business critical function; and “Low” requirements are “nice to haves.” This is a tedious but necessary step that can cause a lot of discussion and dissent among the business team. Provide an outlet for rationale of these comments.
Optionally, a good piece of information is a high-level of estimated effort. This is somewhat contradictory, since we haven’t determined “HOW” we will accomplish the requirement. But it’s good for the business stakeholders to get a sense of the complexity of the requirements. If you want to add this information, at this point, use a very general estimation scale such as T-shirt sizes (X-Small, Small, Medium, Large and Extra-Large) or the Fibonacci sequence (1, 2, 3, 5, 8, 13 and 21).
4. Determine the Minimal Viable Product (MVP)
In this step, the work you have completed to date starts to come together in a roadmap, which will have multiple releases. The first release in the roadmap is the Minimal Viable Product (MVP). The MVP will usually consist of the “High” priority items identified in step 3. But, due to some of the complexities of requirements, some may be removed from the MVP. Contrarily, requirements of “Medium” or “Low” may be added to the MVP if they are less complex or easier effort (low hanging fruit) requirements. This provides some quick “win” within the MVP. This process of determining the MVP should be a team effort but approved by the project sponsor. The requirements that do not make it into the MVP will be placed into other releases of the roadmap.
5. Build Releases in the Roadmap
Now that you have determined the MVP, this will be the first release of the roadmap. Now review the remaining requirements. Naturally, “Medium” priority requirements should be in the next release(s). This release(s) should also include the “High” priority, more complex requirements that were removed from the MVP. You may add some “Low” priority requirements that have dependencies in these releases. The final release should include any remaining “Low” priority requirements.
There you have it: a functional roadmap for your business project. Now that wasn’t so hard, was it? If you’d like to discuss this in more detail and see how we can assist you, contact us at Trellist.