IT Portfolio Mismanagement

By: George Spafford

October 13, 2006

Some IT organizations are using portfolios of IT projects to manage risks in an attempt to yield positive benefits to their organizations. The idea originated in finance and makes sense when the assets being held are relatively independent in nature, however, are IT projects truly independent variables like a third party investment? Are we allowing a historical high project failure rate to cause us to hunt with a very expensive shotgun spawning multiple projects consuming management attention, time and resources in the hopes that some projects may actually deliver some benefits? In this day and age of global competition and tight margins we need to be focused on how we use our IT resources.

Fundamentally, IT exists to enable business functions in the attainment of their objectives by improving productivity and managing risks. Functional area objectives should roll up to support the attainment of the organization’s goal and what we need to pay particular attention to are constraints.

Dr. Eliyahu Goldratt tells us to focus on constraints that are throttling our system and inhibiting our attainment of the goal. In the world of business, that goal is to maximize the sustainable return on shareholder equity. That means IT must work with the business to identify and prioritize the addressing of constraints in order to help the business attain its goal. The constraint that is limiting the system the most should be addressed first. Once that is addressed, then the next constraint should be dealt with and so on. This requires understanding of the business and a focused approach that has a reasonable assurance of success.

The Standish Group publishes their Chaos Report on IT project outcomes. In their Q3 2004 report they identified that only 29% if IT projects delivered on time, within budget and with the promised feature set. That is a very dismal number! Yet, if you look at projects they typically fail for non-technical reasons including poor requirements definition, ineffective communication, and improper oversight.

We don’t need endless swarms of projects floating around. What we need are coordinated projects aimed at addressing constraints. Furthermore, we need controls and processes in place to create a reasonable assurance of success. The business must be able to count on IT delivering on commitments.

To achieve this, IT must focus on quality management. Project failures, high levels of unplanned work, excessive costs, and missed expectations are all symptoms of a breakdown in quality.

Many IT groups have little to know training in quality management and have few, if any, formalized processes. In response to Sarbanes-Oxley, key controls and processes were grudgingly documented but the spirit of process improvement was absent. In response, there are three areas that I routinely urge business and IT executives to review – they are project management, the service development lifecycle (SDLC) and IT Service Management.

A large amount of the work handled by IT is in the form of projects yet the project management discipline hasn’t been formalized and subject to continuous process improvement. It’s no surprise that projects fail – the necessary controls to create a reasonable assurance of success aren’t present.

There is a wealth of best practice project management resources available including Projects in Controlled Environments version two (PRINCE2) and PMI’s Project Management Body of Knowledge (PM-BOK). There are user groups around these standards as well to facilitate knowledge transfer. Additionally, the Internet contains a wealth of project management resources that groups can further research and extend their knowledge and practices.

As with project management, there are many methodologies for the development of systems. CMMI from Carnegie Mellon is but one example. These methodologies aim to define how requirements are gathered, standard development practices, what documentation is needed, testing requirements, and so on. The intent is must be to develop quality systems in the first place before they are put into production. Rather than Systems Development Life Cycle as the SDLC acronym is best known to represent, I recommend that organizations think in terms of what is needed to develop quality services. Systems can be a subset and care must be taken to factor in the people, process and technology requirements for new services and changes to existing services.

The third area is IT Service Management (ITSM) is the concept set forth in the IT Infrastructure Library (ITIL). Its goal is for the development of services that meet the needs of customers and is very much a quality management framework tailored for the use of IT. While ITIL is often identified as a collection of best practices to benchmark against, at its core is a quality management philosophy stressing continuous improvement and a holistic approach to supporting the goals of the business.

In closing, IT can have portfolios of projects that are managed with the understanding that they are all expected to achieve their objectives. Groups using portfolio management to reduce risks with the hopes that some of the projects will actually be successful while others will fail are playing a very expensive game. Instead, IT organizations must focus on the needs of the business and truly build and sustain a culture of quality management to meet those needs.

http://www.standishgroup.com/