Stop project failure: 4 goals to help you improve requirements processes with COBIT 5

If you’ve ever looked at reports about trends in software success (like the Standish CHAOS study), you’ll be familiar with disheartening statistics that the majority of IT projects aren’t delivered on time, on budget or with the required features and functions. Needless to say this doesn’t do much to help IT’s credibility with the business. What can your organization do to make sure IT projects aren’t failing? You can start by taking a good look at your requirements process. This is the process that ensures you’ve got the right requirements in place for enterprise strategic needs in terms of business processes, applications, information/data infrastructure, and services.

 

This is my final post about the recommendations COBIT 5 makes for the development side of IT, and I think it’s fitting to end with requirements. Why does this process matter? If you’ve optimized this process you’re coordinating with all the stakeholders about solution feasibility, costs and benefits, and risk. And ultimately you’re creating optimal solutions that meet business needs while minimizing risk.

 

Goals for requirements

To improve the management of requirements, COBIT 5 suggests IT organizations measure themselves against four process improvement goals. Let’s explore each along with their recommended metrics to get a better idea of the impact of this process as a whole. 

 

1.                  Business functional and technical requirements reflect enterprise needs and expectations. We have all been there. Management has backed an important project. It is critical and an aggressive timeframe has been laid out. But we need to stop and take the time to ensure that the requirements are created accurately and clearly reflect the enterprise’s real needs and expectations. Two metrics are used to measure success against this goal: percent of requirements reworked due to misalignment with enterprise needs and expectations and level of stakeholder satisfaction with requirements. These two measures capture how well we are really doing. The first says what percentage of projects do not deliver to expectation and have to be reworked. This number should be small if we have control over the process. And once again, perception matters.

2.                  The proposed solution satisfies business functional, technical and compliance requirements. This is a similar objective to the process improvement goal above but it focuses exclusively upon the proposal phase. For this goal, one metric is recommended: percent of requirements satisfied by proposed solution. This looks at solutions proposed and evaluates them against requirements desired by the internal customer.

3.                  Risk associated with the requirements has been addressed in the proposed solution. Risk needs to be not only considered for development but also for the production solution that is enabled. Two metrics are recommended to manage this process goal: number of incidents not identified as a risk and percent of risk unsuccessfully mitigated. These go after measuring the risk in production and say that requirements need to explicitly consider risk and where a new risk is identified post production this represents a process deficiency. The first metric goes after this explicitly and the second looks at the risks found but not successfully mitigated.

4.                  Requirements and proposed solutions meet business case objectives (value expected and likely costs). Most organizations require a business case be created for all proposed solutions, programs, and projects. But most organizations do not also do a good job at measuring post value and cost. Doing better here is important. Two metrics are recommended to manage this process goal: percent of business case objectives met by proposed solution, and percent of stakeholders not approving a solution in relation to business case. The first metric obviously looks at the relationship between the business case and the proposed solutions requirements. The second looks at the stakeholder approval of the solution in relation to its business case.

 

So where should you start?

As always, my suggestion is that you start where the most immediate value can be driven. But if it were up to just me, I would start with the percentage of projects that do not deliver to expectation and have to be reworked. What do you think? What would be first on your list I would love to hear back from you.

 

Related links:

Blog post: 3 ways IT leaders can strengthen compliance and control

Blog post: Making COBIT 5 part of your IT strategy

Blog post: COBIT 5 guides IT leaders to better manage future orientation in their organizations

Blog post: COBIT 5’s scorecard measures IT’s relationship with its customers

Blog post: COBIT 5 scorecard measures the quality of IT’s financial performance

COBIT 5

Solution page:  IT Performance Management

Twitter: @MylesSuer

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Mr. Suer is a senior manager for IT Performance Management. Prior to this role, Mr. Suer headed IT Performance Management Analytics Product ...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.