Yesterday, I wrote about the Requirements 101 presentation I gave to my team about what I believe makes for good solution requirements.
(I was not able to limit myself to the 15 minutes I devoted to this as an agenda item because I like the sound of my own voice way too much, but thatās beside the point right now).
The important thing is that I generated some great discussion, which is exactly what I was hoping for. This was not intended to be a lecture, especially given that there are people in my group who are far better at this stuff than I am. The slide above prompted some great input.
Iād argued that the requirement āthe monthly transaction report must be available on the next business day after the end of the calendar monthā was a bad one, but I was intentionally tricking people. On the face of it thereās nothing wrong with this, and it was a trick because after soliciting feedback on the requirement and getting everybodyās input I only then let them know that the report in question takes 30 hours to generate and therefore, I argued, the requirement was not achievable. I said that issues could have been avoided by having the right people (probably technical SMEs of some description) at the table during the requirements phase of work.
Some people pushed back and said that if this really was a requirement of the hypothetical project to which itās attached then work would simply have to be undertaken to reduce the time taken to generate the report. If, on the other hand, the project didnāt have the time and/or budget to support this work then that would be a separate issue to a certain extent, and there would be courses of action other than removing the requirement that could be pursued ā but that this doesnāt make the requirement any less valid. People argued that itās hard (if not impossible) to know that you need some additional technical input at this stage of the process without the benefit of hindsight. āYou donāt know what you donāt know,ā as one person succinctly summed up.
These are excellent points. In fact, often when Iām helping people document their initial requirements for a project I like to tell them (with my tongue firmly in my cheek) that anything is achievable, it will merely come down to how much time and money they have.
My point in including the example in my slide-deck is that I do believe there are opportunities to validate things like this before requirements are finalized and signed-off by stakeholders. If we are able to take advantage of these opportunities to move conversations like this one forwards in the project timeline then it will avoid back-and-forth between business and technical teams, avoid costly rework, and avoid nasty surprises further down the line.
I still feel thatās all true and that my point is a valid one, but of course letās be realistic ā how much effort do we really want to spend validating that each individual requirement is achievable considering every known and as-yet-unknown constraint (bearing in mind that we havenāt even moved in to the āexecutionā phase of work at this point in our story and the solution hasnātĀ been designed)? Should we really wait to secure the availability of a highly-sought technical resource to sit in meetings where they will only have minimal input to provide?Ā Wouldnāt it be more efficient to get the stamp of approval in our requirements as-is and move forwards, allowing the solution architects to identify issues like this later (and suggest where compromises or alternative approaches may be necessary or beneficial)?
I suspect the answer ā as is so often the case with the questions I pose on this blog ā is all about finding an appropriate balance, but I donāt have any solid guidance here for you all.
What are your thoughts?
