Skip to main content

Do You Know Where Your IT Projects Are? Part 1.

In this four part series, Yogi Schulz describes 12 signs of impending IT project doom that are visible months before catastrophe strikes. 

Learn to recognize common project success or failure factors when they occur in your project.  If you aren’t aware of common success or failure factors, you won’t notice when they appear on

your project.  For example, if the project schedule is slipping a day or two each month, that may not be cause for concern.  However, if the rate of slippage is increasing, you might end up a month behind schedule within a year.  That slippage will definitely become a topic of great concern.

Build an understanding of corrective actions that work when a project failure factor looms.  For each success or failure factor, we’ll discuss corrective actions that can turn a looming failure factor into a success factor.  For example, if the project schedule is slipping, the corrective action may be to jettison some scope or to re-assign a few tasks to others.

Many factors can derail IT projects.  Analysis of successful and failed projects reveals that the 12 factors described in these articles are the most frequent contributors both to successful projects and to failed projects.

On unsuccessful projects, many of these factors were not recognized as important, not addressed, sloughed off as unimportant or swept aside as some administrative nicety that was seen as a distraction from “real” progress.  For example, why build a project plan?  That just consumes effort that is better applied to getting on with it.

On successful projects, most of these factors were addressed.  Typically how these factors will be addressed during the course of the project is described in the Project Charter document.  For example, there’s no point kicking off a project without a project sponsor in place who has credibility in the executive circle.

So, if you’re a project manager looking for a chance to bring that feeling of doubt about the likelihood of success of your IT project out in a constructive way, take a moment to think about these factors.  The factors are designed to uncover the specific type of difficulty your IT project may be experiencing.  If you just say to the project sponsor:  “I have this gnawing feeling that our project is not going well.”  That’s an unhelpful comment.  Worse, it communicates that you may not be a team player and that your negative views may undermine the project.

However, if you say to the project sponsor: “I believe that our project plan is weak in these areas.  As a result we are most likely under-estimating a few risks.  Here’s my recommendation about how to fix the problem.”  Now, you’re impressing the project sponsor.  Now, you’re providing early warning of a problem that could lead to disaster.  You’re providing ideas for how to fix the problem.  Now, the project sponsor will think: “I want to keep this guy around.  He’s a real team player who is adding value.”

Based on these ideas, you should be able to better describe various project problems and craft solutions that will avert disaster.

We’ll discuss the twelve common project success or failure factors and how to fix them for project success here and in future articles.

Project Goal

Good – I’ve led development of a crisp statement of the project goal.  Business goals are referenced.  For example, the goal of the project is to reduce the average customer wait time at the call center by one minute.

Bad – I’ve heard a lot of debate about goals and have heard various conflicting statements. Technology potential is referenced by some stakeholders.  For example, the goal of the project is to reduce customer wait time at the call center by introducing a cool, new, faster network to improve response time.

Ugly – I’m not sure what the goal is.  My effort to understand the goal or to achieve some consensus with other stakeholders has not been successful.  For example, the customer service manager thinks the goal is to increase customer satisfaction, the call center manager thinks the goal is to have every call answered before the third ring.

The Fix

Assemble the project team and facilitate a discussion to build a clear statement of the project goal in no more than two sentences; one sentence is better.  Using the SMART[1] framework to describe the goal is effective.  Often it’s useful to list a small number of objectives that support the goal.  For example, implement ERP may be the goal.  Related objectives might be about improving data quality or which ERP modules will be implemented or the sequence in which various business units or divisions will be implemented.

Have the project steering committee endorse the proposed project goal.  Endorsement by the steering committee achieves consensus within management about what the project is all about and what the steering committee really wants to achieve. 

Endorsement starts the process of building a shared understanding of what the project will achieve.  The understanding will be elaborated as the project progresses.  For example, it’s common for different vice presidents to have different perceptions of what the problems are or what the priorities for fixing them should be; One VP may want to start with manufacturing planning while another one wants to start with billing.

Successful project managers work hard to achieve a consensus on the project goal early in the project and then work to maintain that consensus.

Project Sponsor

Good – I know the senior executive, who is the project sponsor, by name.  I have confidence in that individual.  For example, the VP of Production is the project sponsor of the ERP implementation.

Bad – The role is diffused among multiple individuals.  I’m not sure who has been assigned to do what.  I’m not sure why there are multiple project sponsors.  For example, the VP of Production and the VP Finance are both project sponsors of the ERP implementation; both seem to defer to the other on decisions.

Ugly – There is no project sponsor or I don’t know who holds the role of project sponsor.  Sometimes organizations confuse the role of project sponsor and project manager. Sometimes organizations believe the two roles are synonymous.  For example, the VP who was project sponsor was head-hunted and is now gone; no replacement has been named even though a manager was promoted to the VP spot.

The Fix

Recommend appointment of the manager of the business area that has most to gain from the project as project sponsor.  This person becomes chairman of the project steering committee.  For example, the VP of Production is a good choice for project sponsor of an ERP implementation.  Because ERP typically crosses organizational boundaries, include other VPs on the steering committee.

Provide some orientation to the person to become effective in the role.  The role is to address major issues and support the project team; especially the project manager.  The role is not to be a figurehead for some overly ambitious project manager.  The role is not to become the scapegoat for some looming disaster.

Successful project managers work to build and maintain the relationship with the project sponsor.

[1]  The acronym has a variety of meanings; I like this one:
S – specific
M – measurable
A – achievable
R – relevant & realistic
T – time-framed

Don’t forget to leave your comments below

Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at [email protected].


Comments (4)