February 20, 2017 | Project, Program, Portfolio Management
Observations and Thoughts on Requirements
“‘Begin at the beginning,’ the King said gravely, ‘and go on till you come to the end: then stop.’”
– Lewis Carroll, Alice’s Adventures in Wonderland
And for software development utilizing a Waterfall approach, the beginning is Requirements and as we all know, a very critical phase in such projects. Having managed, participated and run requirements gathering sessions over the years, I thought I would share some of my observations and thoughts from that experience.
Too well is almost as bad as too bad
Requirements gathering is hard and people don’t always agree with each other, so coming up with a common set of requirements that a group of people will sign off on should invariably result in friction. No friction means either it’s a really simple project or no one cares enough about the project to give a damn.
So in other words – pain is good, too much pain is bad and the art is finding the right level of pain.
Beware of committees
From the perspective of requirements, buy-in is definitely a desired outcome, but sometimes collaborative decision making is a recipe for gridlock and excuse to evade accountability for results.
“Cadillac specs on a Yugo budget”
Requirements without consideration of project constraints (budget, schedule, etc.) is a shortcut to disappointment and changes down the road.
Everything costs money
Including the time it takes to talk about it. This is an obvious but often times neglected point in requirement discussions.
Later is an expensive privilege
Generally in a Waterfall approach, “we will figure that out later” is often times a precursor, at some later point, for a change request.
Be careful what you ask for
When people ask other people for their thoughts/opinions in requirements sessions, most people will offer their thoughts/opinions, cos most people are nice that way.
Unfortunately there is no rule that says these have to be useful or even relevant and so can take the team down a blind alley/rabbit hole, or be used to revisit previously closed decisions, etc. creating angst and frustration for everyone involved.
Requirements are political
“Politics is who gets what, when, and how.” – Harold Lasswell
Since requirements is essentially putting pen to paper of what someone is going to get at some point in time, it reflects to a greater or lesser extent the politics of the organization.
Sign-off does not mean success
If an extreme focus is placed on requirements completion on a very rigid time-frame, what results sometimes are requirements that are quick to capture and non-controversial while outright skipping over the hard discussions that truly flesh out usable high quality requirements.
For example, requirements like “Accounting will be correct”. It is so high level that it is both completely accurate (and so enables user sign-off) and completely devoid of any meaningful detail (which has the benefit of being very quick to capture in requirement sessions).
Small things make a big difference
It is amazing how many issues can be avoided by proactively doing small simple things that help preclude common means of misinterpretation especially if teams are scattered across the globe.
For example, things like clearly capturing number/date conventions (e.g. “mm/dd/yy” or “dd/mm/yy”), what size paper the report should print on (e.g. A4 or letter), not using colloquialisms, spelling out acronyms, etc. can really head off issues later on in the project.
Change is inevitable
Developing requirements and never expecting them to change to adapt to changing business environment/strategy/etc. is unrealistic the larger the project is (especially if the lag between the requirements and implementation is very long).
Penalizing teams for making changes or having a very painful and arduous change process can sometimes be counterproductive.
And at the end of the beginning, remember –
“A hard beginning maketh a good ending.” – John Heywood
For more information on how Lake Shore Associates can help you with your project management needs, visit www.lakeshore.is. We will be most grateful to work with you.
