The Curse of Rushed Requirements
When software development is outsourced, as it often is in the public sector, contracts are necessary. The goal of the contract is to describe the product desired and establish a framework for hiring and paying a firm to build that product to some prescribed level of quality.
The challenge for developers since the first wired circuits is to get a good definition of what is desired and how we would know if it was delivered. This definition is commonly defined through requirements.
Generally, humans are not very good at writing requirement specifications. Describing requirements effectively is a specialized talent. It takes practice to develop the analytical and writing skills, and it takes time to work with users to understand their needs.
Impatience with this challenging process is one of the attractions of agile development practices. The argument goes: “Since most of the time the requirements are incorrect or have gaps, why spend all that time up front? Let’s sit with users and understand from them what they want and need, and then build it while they watch so they can guide us and we don’t waste a lot of time building the wrong product.”
This approach sounds appealing, but it works better in some contexts than others. If the users know what they want, and they all agree what that is, and they can tell you or show you, then this can be an effective and efficient approach.
On the other hand, if the users aren’t good at explaining their requirements, or don’t understand what they are, or don’t agree what they are, agile practices may be slow to identify the confusion. Agile doesn’t magically resolve the underlying problem.
A project manager recently complained that a procedural deadline for contracting was tempting her sponsor to approve a sloppy requirements document because there was insufficient time to rework it without missing a key procurement milestone. The table is set for tragedy: Either encourage the sponsor to be disappointed now by missing the procurement deadline to allow cleaning up the requirements, or proceed to procurement with incomplete or inaccurate requirements and pretend to be surprised by future delays and increased costs.
Within a week of that conversation, one of the best-run agile projects I have worked on discovered a flawed assumption that developers had made based on a vague requirements specification. The development team’s assumption about its interpretation was reasonable. The specific use case that identified the problem had not come up in over a year’s worth of ongoing design sessions with the customer.
Now, in the middle of a two-year effort that had been going smoothly, a whole new dimension and function of the application has been identified that is mission-critical, poorly described in the requirements, essential for go-live, and likely beyond the allocated budget. The entire project is now at risk. Lawyers and juries may ultimately decide who is responsible for the mistake in a legal sense, but in my opinion, sloppy requirements are a key contributor.
Although requirements are never perfect or static, they do establish an important baseline for cost and management. Agile practices help explore and refine requirements but don’t eliminate the need for a solid requirements base to facilitate contracting and managing the project.
You have covered it well.