Tuesday, October 11, 2011

Strategic Requirements management

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.

1 comment:

  1. 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!

    If 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!