Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?
Limited Time For Writing Requirements
Some projects dedicate enough time to define the requirements. “Enough” is a subjective term, but the precise definition isn’t the point. Your project probably doesn’t allocate enough resources to do everything you want with requirements. Also note – this is not an iterative vs. non-iterative discussion. BUFR (big up front requirements) have an obvious and easy to measure allocation of time and resources dedicated to requirements management. Agile processes and approaches that define “requirements as you go” also allocate time and resources to requirements management. It might not be tracked as such, but the allocation is still there.
Regardless of the process you choose, your requirements gathering activities will want to exceed the allocated capacity. In our article about managing software delivery with timeboxes, we presented four alternative solutions:
- Increase Time to finish everything.
- Increase Cost / Resources to finish everything.
- Finish a subset of the work.
- Reduce the quality of the deliverables.
A single deliverable is a combination of both content and quality.
By analogy, the same is true of requirements. You can deliver a use case poorly or well. Delivering it well takes more time.
Finishing A Subset of the Requirements
There are times that you can’t increase staff (or when Brooke’s law prevents that from being effective). There are times when you can’t delay the product. This leaves you with two choices – reduce quality or reduce quantity.
Suzanne Robertson has just written an article at the Requirements Networking Group site describing how to approach reducing the quantity. Suzanne’s approach involves working with stakeholders to identify which requirements to write first. Check it out.
The first comment there raises the point that this may be impractical – to deliver less than was promised. It is a very valid concern, and one of the areas that many iterative projects struggle with. Join in on the conversation there or here.
There are times when the scope/time/cost factors will force a PM or BA to write requirements for only a subset of functionality. Usually, I have walked into these projects mid-stream. It isn’t fun. It is especially NOT fun when the team has no established methodology. They don’t know that what you have produced is less than ideal, and run with the incomplete Requirements as though they are gospel, yet not understood for what they are.
In these cases, there are often other factors working against you (the aforementioned scope/time/cost constraints, usually), and the project is in a less-than-optimal position. I think that the ability to effectively manage these types of projects separates PMs with *talent* from PMs with certification.
Always fun to write Requirements on the run :)
And it’s even more fun when a scope iteration impacts you in a way you didn’t anticipate.
I am enjoying your blog. You address a lot of interesting topics in a way I find easy to digest.
Best,
Josh Milane
Hey Josh, thanks for commenting.
I’ve definitely walked into the “can’t get it all done” situations too – usually when being parachuted in to help out a project that was initially staffed with people who couldn’t deliver, or a project who’s sponsors had impractical expectations – often mis-set by vendors.
Great observations about the impact of people not knowing that what you are delivering is partial. One approach to mitigating that affect is to use breadth first coverage of requirements / use cases. In other words, define the use case names, then use case briefs, then formal use cases. Each discrete deliverable is “complete” with a particular level of rigor, and people can be confident that the formal use cases are complete, while the use case briefs will require additional effort.
I’m not sure there is a reasonable way to address other requirements artifacts, other than managing their status (e.g. draft form vs fully vetted) with some custom attributes.
And thanks very much for the positive feedback! Keep reading and commenting.