Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Are IT projects truly independent variables like a third party investment? Are we allowing a historically high project failure rate to pressure us into spawning multiple projects that consume management attention, time and resources in the hopes that some of those projects may actually deliver some benefits? In this day and age of global competition and tight margins, we need to focus on how we use our IT resources.
Fundamentally, IT exists to enable businesses to attain their objectives by improving productivity and managing risks. Functional objectives should roll up to support the attainment of the organization’s goal; 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 the attainment of our 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.
Chaos Report on IT Project Outcomes
The Standish Group
publishes the “Chaos Report” on IT project outcomes. In their Q3 2004 report they revealed that only 29% of IT projects were delivered on time, within budget and with the promised feature set. That is a very dismal number! Yet, if you look at specific 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 control.
Three Areas to Monitor
Many IT groups have little or no 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 subjected 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 to facilitate knowledge transfer. Additionally, the Internet contains a treasure trove of project management resources that enables groups to 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, and they provide guidance about standard development practices, documentation, and testing.
The intent of IT managers must be to develop quality systems in the first place before projects are put into production. Rather than SDLC, 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), which is the concept set forth in the IT Infrastructure Library (ITIL). Its goal is the development of services that meet the needs of customers and it 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 core it’s 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.
