Although most project teams conceptually understand the importance of documenting requirements before embarking on a new project, in practice, there is not enough discipline around this process. We get it; this happens because of time constraints and a general lack of consistency across project groups, leading to confusion and bad habits. While the complexity of the requirements will vary, the approach to collecting and using them should stay the same. This blog will explore five key takeaways from a young consultant who has recently completed their first functional design document on a systems implementation project.
Lesson #1: Zoom in and zoom out regularly – keep the requirements aligned to the business case.
Requirements are a means to keep a project within its defined scope or help surface discussions about processes or needs not considered when entering the project initially. Business requirements should theoretically align to the project objectives, which should ultimately tie to specific business case items. This alignment is crucial for ensuring the overall success of the project. When the correct requirements are fleshed out and captured, project goals are controlled adhered to. However, project teams should watch out for instances of ‘gold plating,’ where additional, non-essential requirements are added to which do not conform to the strict business needs and therefore not driving towards the business case but drive a solution towards nice-to-haves and unnecessary aesthetically pleasing characteristics. Having the wrong requirements, as well as unnecessary ones, will only lead to project cost overruns, missed timelines, and ultimately frustrated end-users!
Lesson #2: Methods and structures create accountability within a project… and an organization
Properly structured and documented requirements are particularly useful in creating accountability on the projects (and within an organization, more broadly). The structure should include documenting both the author (literally the person who wrote it down in the meeting) and the owner of each requirement (the person who needs to justify its existence). These are often times not the same person. For instance, you might designate a person from each business functional area as the author of the requirements in their respective area, or a consultant or internal analyst could be the scribe. However, requirements must be validated by the requirement owner, who could be, for example, the leader or manager of a functional area…. Or even a process owner. This approach not only enhances project governance and process control but also encourages individuals to take their project responsibilities and requests more seriously. If a requirement appears to be out of scope or if there is a missing requirement within a specific functional area, there will be a designated person to consult for further information. The designation of accountable parties should be determined by the type of project, which could range from operators to middle managers and up to executives.
Lesson #3: Requirements can be hidden in plain site
Project teams and called upon subject matter experts often assume they can develop requirements solely based on their own understanding of existing processes while sitting at their desk or at a table in a conference room. However, these requirements are often embedded in the daily operational activities of the personnel executing these processes. Often times team members will draft requirements in terms of how they imagine they should be doing things, or what they assume is happening around them. Ideally, documenting workflow-related requirements involves observing process-owners as they perform their tasks ‘live’ and recording their activities. It is important to understand there may be time constraints when it comes to in-person observations, however, businesses can selectively apply this approach to processes or functional areas where there is significant uncertainty regarding process standardization, or where are significant costs are incurred in their current state. In certain cases, depending on the project and the client, it may be recommended to provide a pre-populated list of requirements for processes that are most standardized. This approach is recommended primarily when time constraints are significant, as such a list can offer a solid foundation from which to develop any additional requirements that may be necessary. It is also important to avoid letting the current state functionality or operations restrict requirements. It is critical to break free from that mindset at the start by staying agnostic to design and instead focusing on desired future state goals, motivations and capabilities with the correct understanding of current state processes.
Lesson #4: Use the correct diction and syntax
Linguistics is very important when crafting the requirements. For example, a client may write the following requirement: “user must be able to export shipments.” One person might think this means the user should be able to download a CSV file of their shipment data, while another might assume it involves handling international/cross-border shipments. When writing requirements people have to be thoughtful of their word choice and avoid leaving room for interpretation.
It is also common to gravitate towards more prescriptive language, especially if there is some familiarity with the future state process or technology being implemented. However, this is not best practice. For example, someone might say a requirement is “to be able to notify customers of an order update via email with a link to the portal detail.” This is not an ideal requirement because it uses prescriptive language, implying how the requirement should be implemented. It can be rephrased to something like “ability to notify and display order updates to customers.” This keeps the requirement more open-ended and allows for flexibility once it is time to formally move into design once requirements are validated. By focusing on functional requirements rather than prescriptive statements, teams can ensure that the solution remains adaptable to various implementation strategies. Clear and well-articulated requirements pave the way for more room for creativity and an agile project outcome.
Lesson #5: Validate cross-functionally
Once the requirements are written, it is ideal to conduct a requirement validation step. During this process, the business team should invite necessary stakeholders to join workshops to review and confirm the validity of the requirements before progressing to design. While it is common practice to organize these workshops by functional business area, limiting participation to only those people in each area; if a requirement is later found to impact another functional area, it may necessitate re-validation during the design. To prevent this, the project team should identify dependencies during the requirement creation process and ensure that representatives from all potentially relevant affected functional areas are included in the validation sessions. By ensuring that all relevant stakeholders are engaged in the process, the project team can avoid costly rework and delays that often result from overlooked dependencies or miscommunication between functional areas. This approach also helps people think differently about future processes during design workshops because of their deeper understandings of other peoples’ areas of the business.
Ultimately, the lessons learned from first-hand experience doing a functional design highlight that careful attention to requirement documentation can significantly influence the structure and outcome of a project. Requirements documentation and validation serve as the foundation upon which the entire project is built, guiding decision-making, resource allocation, and risk management. When requirements are clearly defined and thoroughly validated, they not only prevent scope misalignment but also enhance the ability to deliver solutions that truly meet the needs of the business.
