Semantic precision has a brand new solution to this requirements management challenge based on an approach to business requirements, that leverages off a business architecture framework and is built on a business transformation management platform. See: www.semanticprecision.com
I think this item is excellent "Why is IT Project Failure Always an Option" http://java.sys-con.com/node/2007687 - extracts below
If the requirements in a single project are incorrect the outcome from that project is unlikely to be correct. But even if the requirements in a project are correct if the requirements across the set of projects that transform the enterprise are not correct (consistent, coherent etc. as a set) the net business transfromation result of all the projects across the enterprise is unlikely to be achieved.
I like the item below it makes the case that:
- project failure rates are high and unnecessary
- if you are not dealing with better approaches to requirements you're part of the problem
- a strategic view of requirements involves a direct connection between customer needs, IT spend, and strategic initiatives.
- maturity models are requirements
- an organization should be able to understands the strategic value of every project and be able to make daily decisions based on those values.
Extracts from the source below
"You [would] think that we'd be tired of the horrifying rates of failure, and the crushing consequences of those
failures ...
But if you are not spending more time understanding your customers - and developing tightly scoped
requirements to make great software to meet their real needs, not some imagined "needs mash-up" cobbled
together by the squeakiest wheels in your organization - you're part of the problem, and you're
accepting failure as an ever-present option.
It's time to stop the madness,... waste, ...cost overruns inpart from "inadequate requirements
management. ...
Most IT executives are familiar with the data on project risks, including overages and failure to meet
business needs. The risk described by Bent Flyvbjerg and Alexander Budzierin the September Harvard Business Review is that one out of six IT projects incurs "a cost overrun of 200%, on average, and a schedule overrun of almost 70% ...
It's time to get smarter ... and one way to do this it to take a strategic view of
requirements. A strategic view of requirements is not merely concerned with improving requirements or
improving projects; it incorporates a direct connection between customer needs, IT spend, and strategic
initiatives. It's requirements for grown-ups, and it involves maturing requirements.
The maturity model isn't just for app dev - it's for requirements as well. While most organizations
follow an ad hoc methodology for portfolio management and controlling project scope, a "requirements
mature" organization will find that all of IT understands the strategic value of every project (which
means that IT is aligned with internal AND external customers) and can make daily decisions based on
those values.
So, just what might this maturity process look like? It might look like a Requirements Center of Excellence. Here's one model for the increasing stages of maturity:
Stage 0: Ad Hoc. There is no requirements maturity. Requirements are created ad hoc, project scope is
based on "squeaky wheel"direction. ...
Stage 1: Individual. Although individual efforts may align with business strategy, there is no
consistent measurement of business return.
Stage 2: Team. Teams now share an understanding of business objectives; some individuals may share an
awareness of strategy. While individual projects may be measured for return, there is no organization-
wide validation of project return yet.
Stage 3: Business Unit. There is strong portfolio management across multiple teams. Teams and finance
consistently define and evaluate the project return across the portfolio. More than one business unit
may be at this level of maturity.
Stage 4: Organization. Throughout the organization, there is strong portfolio management based on
organizational strategy. The scope of projects is aligned with the strategy, and the entire portfolio is
regularly analyzed for business return.
... By making requirements strategic and by incorporating business strategy into requirements, not only will requirements mature faster, but those more mature requirements processes will lead to consistent business benefits.Which means great customer experiences, which come from great software.
Hi Michael - thanks so much for sharing Hollis's post, and for sharing through his post the Seilevel view that requirements are, indeed, strategic. Glad we are of like minds!
ReplyDeleteIf you'd like, you and your followers are invited to download a report on this topic, and on the path to creating a Requirements Center of Excellence, here: http://www.seilevel.com/requirements-resources/
We just shared this information at an IT executive dinner in Dallas featuring Forrester Research VP Mike Gilpin, and there was a lively discussion that followed...so your posts and thoughts are very timely!