In 2014, the Project Management Institute (PMI) researched how vague or incomplete requirements can affect entire projects; the findings were not entirely surprising: customers spent more money than initially planned in 51% of cases and 47% of projects failed to meet goals due to inaccurate requirements management. Common sense holds that it is in the customer’s best interests to become involved in working out clear product requirements at the pre-project planning phase (or task a contractor with this job) to reduce the risks of release delays, budget overruns, and poor quality project outcomes.
As project managers are aware, technical requirements will sometimes remain undefined or unclear for various reasons, which can create difficulties for the engineering team. Some companies are reluctant to formalize or even line requirements management in the activities list. Why is this, bearing in mind that poor requirements equate to poor performance? Typically, the underlying reason is that customers are more concerned with “high-level” business requirements. requirements are typically gathered from non-IT users or departments, it is only natural that business requirements happen to be more familiar and important to such product-owners. The customer may simply not possess any sufficiently skilled resources to translate business requirements into technical ones. Sometimes, situations can occur when a customer is working with an outdated or legacy product with lost (unreliable, incomplete, or unsupported) documentation and missing experts.
While some customers will have technical resources in place and a well-maintained product, the requirements for the developer team can only be described as poor. This can happen when there are certain conventional misconceptions such as requirements management being completely unimportant in Agile projects. The Agile manifesto prescribes that one should value working software over comprehensive documentation, which can mean that certain customers mistakenly believe that technical requirements and documentation are useless as everything will change anyway. Below, I prove that this statement can be terribly misleading.
What is the common process for technical requirements management?
Let us suppose that the customer understands that providing technical requirements is important but does not have the necessary resources or knowledge to document them properly. Defining technical requirements is a natural step in the project planning process. A dedicated specialist (analyst) must read the documentation, talk to product owners, carefully study the business requirements, and examine the product architecture. Afterward, the analyst will use relevant standards and methodologies to write technical requirements or Software/System Requirements Specification (SRS) that are accurate and sufficiently clear for the engineering team to proceed with the project. As soon as the requirements are documented and approved with the customer, the project workflow will go according to the planned schedule regardless of the methodology.
Are Agile projects any different?
Customers’ business departments typically do not understand why they need to spend time writing documentation. They need a product and so that is naturally what they are looking to purchase. Therefore, misleadingly charmed by the Agile methodology, customers may decide that, since a “working product” is more important than “comprehensive documentation,” documentation is not needed whatsoever—comprehensive or otherwise. This is the most common and deceptive approach. Below are some fundamental misconceptions to avoid falling into this trap.
- An Agile project does not need requirements management. Requirements management is actually integrated into the Agile methodology in the form of a product backlog. Prioritizing and re-prioritizing user stories, planning iterations and releases, daily stand-ups, burn-down and burn-up charts, adding acceptance criteria to user stories, demos, and retrospectives; they all contribute to the requirements management at every stage of the project.
- Product changes are not controlled in Agile projects. Of course, changes are far from uncontrolled in reality. Change requests are described as user stories, put on the backlog, and prioritized by the product owner.
- If the backlog is constantly changing, there is no need to strictly document the requirements. While the Agile methodology admits that the product backlog changes throughout the project, the main value the Agile methodology offers is flexibility; a large project can be cut into smaller pieces, or “sprints.” However, to deliver a high-quality product and remain within budget and schedule, the requirements for each sprint should be clearly stated and agreed upon in advance. Otherwise, the number of requirements will grow uncontrollably.
Six Tips for Creating Technical Requirements
Starting work on a product without understanding the final result is difficult. There is always a risk of becoming a character in the famous sketch about seven red lines. If you do not have the resources or knowledge to write technical requirements and documentation, these recommendations could help you implement your project successfully.
- It is important to understand that working with requirements is an essential aspect of a project, not the contractor’s whim. Coordinate this step with the contractor and budget-related costs. Remember this or there will is a major risk of missing deadlines, going over budget, or releasing something without all planned functionality and performance and reliability issues. “Buy nice or buy twice” as the saying goes.
- Plan some time for analytics. A good analyst will both ask the right questions to help determine a product’s high-level profile (WWWH — Why? What? Who? How?) and find out the real needs behind stated wants.
- Agree on a communication roadmap — the “who, how, and when” for information about requirements, changes, progress, and problems. It makes sense to work out a communication plan and choose convenient communication channels prior to starting a project.
- Decide who makes changes to the backlog when for what reasons and how these changes are prioritized and tracked.
- Select a product owner before the project starts—they will be the access point for the project manager and engineers. The product owner communicates with the engineering team and tracks progress. According to PMI, >37% of projects fail due to low involvement by the product owner.
- Plan enough time for “sprint zero” as described in my previous article. Spend two or three weeks writing HLD and HLA, setting up CI/CD, planning and evaluating the main tasks, and—most importantly—documenting your future product’s requirements.
