The Rigour Curve
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:
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’.
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