Project success stories are still too few and far between. There are some basic steps that all Project Managers and PMO Directors can take to immediately add value to both the IT organization and the business.

By Omer Perra and Michelle Bailey

Recent research published by the Standish Group has found a significant improvement in project success rates in the US over the last 10 years. The Group estimates that over one-third of all IT projects for 2003 (34%) can be classified a ‘success,' as opposed to 16% of projects 10 years ago. They approximate that this translates into $55 billion wasted on IT projects in 2003, down drastically from the $140 billion wasted in 1994. While these improvements are indeed dramatic, the bigger message from this study is that project management in IT has a long way to go. Said another way, almost two-thirds of all projects either fail or are challenged to meet expectations.

Even more alarming is that the parameters for “success” in this study are pretty straightforward and fundamental. To be considered successful, a project has to be on time, on budget, and meet the critical requirements from the project specification. How can it be in the 21st century that 2 out of every 3 IT projects fail to meet these three basic objectives? This study doesn’t even begin to measure the business benefits from IT. One can only wonder what proportion of the “successful” projects contributes appreciably to increased revenue.

There are a multitude of reasons why IT projects go wrong – the scope of the project changes, vendors over promise on their technologies, the business changes, funding dries up, users submit too many change requests, the amount of customization for an off-the-shelf package was underestimated, the stakeholders failed to account for corporate culture in user resistance, the managers with the best PowerPoint presentation (not projects) got the funding…you name it, there are a million of them. What they all amount to is a lack of clearly defined standards and practices in managing IT projects. It is not a coincidence that the doubling of successful projects can be attributed to better and improved IT management policies. The institution of Project Management Offices (PMO’s) at an estimated 65-80% of all organizations in the US is a testament to these improvements. But we are far from a project panacea, and if it takes another 10 years to get project success rates to 70%, outsourcing won’t just be a trend, it will be the rule.

Time and again we visit client sites that are suffering from a legacy of poor decision making. While project managers can do little about the past, there is a lot they can do to inject consistency into their IT organizations, and make success an expectation for the future. We find that the most basic disciplines that have tremendous impact are either lacking or poorly implemented at too many companies.

In our experience there are five key elements to success for any project, but at the core is an understanding that there is no such thing as an IT project -- only projects that use IT to solve business problems.

1) Don’t start any project without an Executive Sponsor.
First and foremost, make sure that your project has a strong and visible executive sponsor. This person is typically from the business side of the house (not IT) and clearly understands what the project will do for the business. Your executive sponsor is not somebody that is a passive figurehead, but rather an enthusiastic supporter of your work and is prepared to battle roadblocks and address a whole range of issues as they are thrown in your way.

2) Build an Executive Steering Committee
You should establish an executive steering committee that includes key stakeholders -- the investors, the users and the IT team. There is a big difference in expectations among those that build, those that buy and those that use, and all of their opinions are important and relevant to the successful implementation of any project. Without early buy-in and active participation from each of the constituencies, your projects are doomed to failure.

This steering committee must meet regularly and handle multiple projects, but before any project commences, this group must collectively establish clearly defined outcomes and benefits of projects, ensure that the necessary funding is available to meet the scope of any project, enforce a strong change control process and should implement metrics that measure the progress of all phases of project development and production phases.

In addition to making sure that they project is well defined and that expectations are being met along the way, the steering committee should be your marketing vehicle that builds the brand of the IT organization (and projects) throughout the company. This forum approach makes clear that the accountability for project success lies in the combined efforts of the business, the users and IT. No one wins if the project fails the business.

3) Formalize Polices, Procedures and Practices; Build a Business Case
The establishment of a good governance process is essential. In general we find that the more mature a governance process is, the higher the value to the IT organization and the fewer project failures. This process should not be inflexible, but should have contingencies and best practices that build in a disciplined approach to all phases of a project. These disciplines should include standard methodologies, documented guidelines, templates, and metrics for project selection, design specification, lifecycle management, rollout planning, fiscal accountability, escalation processes, compliance and business benefit.

Build a business case for every project (big or small) using the same template and methodologies so that you can measure all of your proposed projects on a level playing field. You can either do this yourself or buy one from a consultant, but ensure that it includes costs (one-time and ongoing), business benefits (one-time and ongoing), staff resources required and user metrics, as well as ROI measurements and timelines. If you can’t document and measure the elements that define success of a project, then you can’t be sure that you should be doing the project at all.

Don’t forget to make post-production planning discussions a part of your process. Look at what is needed to maintain an application, and enhance it over a series of years and you can expect better long-term returns. It’s usually easier, cheaper and faster to fix what you have than start again. Care and feed for your applications, but maintain controls that limit a flood of post-production changes.

One approach that we take is to survey users of an application that is slated for change prior to project commencement to gauge the value they are getting from existing functionality. These questions are a combination of the amount of time users spend using the application in a typical day, how productive it makes them in terms of getting their job done, and the impact on their productivity should the application go down. We then survey users post-implementation on the same elements to ensure that the value to the users has exceeded the pre-implementation state. For instance, we may find that usage has gone down, but productivity has increased, telling us that the project had a successful conclusion. This survey is then also used to delve into changes that may be required post-production, and to rank them in terms of importance.

4) Think ‘Project Portfolio’
It is very important to diversify your project portfolio as you would a stock portfolio. That means understanding the profile of projects being funded, and their expected impact relative to existing applications. Have a good mix of projects in terms of investment, scope, and risk; and also understand how they relate to your base application portfolio. For instance, it’s well understood that you don’t want to take on a few large risky projects with a protracted payback period or conversely, many small projects that have little risk (and usually little payoff). But assess these factors with a view toward the entire application portfolio, not just the projects being funded this year – you may reach completely different conclusions as to the optimal funding mix.


5) You Need Luck
As with anything in life, you need a little luck. If you have no luck, either find someone who does or you’re going to have to make it for yourself.

IT organizations have taken a lot of heat over the last couple of years. There has been significant criticism and doubt around the payoff of IT projects. While it may or may not be fair to place this blame completely on the shoulders of the IT organization, we do know for certain that any Project Office with a 30% success rate will fail to exist. We find that customers are very receptive right now to integrating best practices and techniques that will create a more disciplined approach in linking IT and the business together. While resistance to change is low with regard to the PMO, take action now rather than later in formalizing your IT Management practices. Use this time to build alliances between the business stakeholders and the IT organization.