The Good Old Days.
We are always looking for new ways to illustrate the utility of opmodal which will strike a chord with potential clients. Given we were inspired to create the product to solve problems we were encountering ourselves, it made sense to use some of those challenges to make the point.
It occurred to me recently that one of the hardest parts of my job as a Business Analyst, back when I started in the late ‘90s, was obtaining stakeholder sign-off for the Business Requirements I had been sweating over for some weeks.
There would always be a list of reviewers in a neat little table at the beginning of my requirements document which seemed like a great idea at the time the process started.
And then I would be variously challenged with nailing down written agreement from a group of individuals who fell into one of a few broad categories:
Don’t Care
Not My Responsibility
Probably OK But I Ain’t Signing Anything
The Minutiae Fetishists
Grammar Pedants
Actual Subject Matter Experts Who Ask Me Questions I Can’t Answer
Why Are We Spending Money On This Instead of That?
It was, without exception, the toughest part of the job.
And the reason that it was difficult had nothing in particular to do with the specific challenges of getting some reasonably quorate sign-off out of the above cast.
Rather – it was because I had to get that sign-off, otherwise the IT team, or the Supplier or whoever else was actually going to deliver these changes simply wouldn’t accept the requirements.
We wouldn’t pass through that particular ‘stage gate’ of the project, they wouldn’t start work – and it would be my fault.
Put simply – there was a degree of rigour applied to the process of gathering and agreeing the input Business Requirements for a change.
Halcyon Days.
A Grumpy Old Man Speaks.
My sense is that this rigour has declined markedly in the last 25 years or so, while in parallel there have been substantial increases in the rigour applied to subsequent phases of projects.
Increasingly automated testing, and a culture of testing teams ensuring they hold the project to account with respect to logging test evidence and updating statistics (if not providing independent validation of the testing veracity) have definitely improved the pre-UAT test quality.
User Acceptance Testing itself can continue to be a challenge, other than on very localised changes with a closely aligned and engaged user base. Meanwhile there are elements of project delivery which have, and always have had, lip service paid to them. At best. I’m talking about you, ‘Benefits Realisation & Measurement’.
Why do fewer projects than ever seem to care so little about ensuring business and the subsequent / associated design and technical requirements are correct before embarking on lengthy and expensive project work?
How can we meaningfully test against requirements which weren’t signed off by the stakeholders regarding what the outcomes ought to be?
How do we prepare expected results with no requirements to measure against?
How do we stop technical debt and Heath Robinson operating models spiralling out of control?
In a supposedly ‘cost conscious’ corporate landscape, purporting to be focussed on ensuring justification of spend and measurement of delivered versus project benefits – how on earth is that even possible with no record of who asked for what, and why?
As tempting as it is to think this is just me getting old and grumpy, I do genuinely believe that every single aspect of a project would be improved if only someone, somewhere would insist the business requirements were signed off by the stakeholders asking for the change.
Cheer Up!
As it happens, we believe that opmodal can be a key enabler to help organisations achieve this transparency and traceability. Not to mention a very helpful tool to help with a number of the other depressed metrics in the Rigour Curve.
(Funny that.)
In a series of posts, we will be illustrating exactly how we believe opmodal can do that for you all.
Perhaps if we work together, we can all (project) party like it’s 1999, once again. ;)
Nicholas Ross, opmodal Co-Founder
Commentaires