There’s trouble ahead: early warning signs of project failure

Introduction

I’ve written a number of articles on project failure, covering topics ranging from  definitions of success to the role of biases in project failure.  As interesting as these issues are, they are somewhat removed from the day-to-day concerns of a  project manager who is  more interested in avoiding failure than defining or analyzing it. In a paper entitled, Early warning signs of IT project failure: the dominant dozen,   Leon Kappelman et. al. outline the top twelve risks associated with IT project failures.  This post summarises the paper and lists the top twelve signs of impending trouble on projects.

Background and research methodology

The authors  focus on early warning signs – i.e. those that occur within the initial 20% of the planned schedule. Further, to ensure comprehensive coverage of risks, their conclusions are  based on inputs from academic and industry journals as well as from experienced IT project managers.  The paper provides a detailed explanation of their research methodology, which I’ll quote directly from the paper:

The research team first searched the literature extensively to develop a preliminary list of early warning signs (EWSs). The two authors experienced in IT project management then added several EWSs based on their personal experience. Next, 19 IT project management experts were asked to assess the list. On the basis of their feedback, we added new items and modified others to develop a list of 53 EWSs. Finally, the research team invited 138 experienced IT project managers (including the original 19 experts) to participate in rating the 53 EWSs using a scale from 1 (extremely unimportant) to 7 (extremely important). Fifty-five (55) of these managers completed the survey, yielding a response rate of nearly 40 percent. The respondents had an average of more than 15 years of IT project management experience. The budgets of the largest IT projects they managed ranged from 3 million to 7 billion dollars. About 30 percent held the title of program or project manager and nearly 20 percent had consultant titles. Director or program analyst titles accounted for about 15 percent each, 10 percent were vice presidents, and the rest held titles such as CEO, CIO, chief scientist, chief technologist, or partner.

Although the list and the rankings were based on the subjective opinions of experts, the large number of participants ensures a degree of  consensus regarding  the most important factors.

The troublesome twelve

After ranking the fifty odd risks, the authors focused on those that had scores above 6 (out of  a maximum possible of  7 as discussed above).  There were 17 risks that satisfied this (somewhat arbitrary) criterion.  Some of these were similar, so they could be combined. For example, the four risks:

• No documented milestone deliverables and due dates.
• No project status progress process
• Schedule deadline not reconciled to the project schedule
• Early project delays are ignored — no revision to the overall project schedule

were combined into: ineffective schedule planning and/or management.

This process of combining the top 17 items resulted in twelve risks, half of which turned out to be people-related and the other half process-related.  I discuss each of the risks in detail below.

People-related early warning signs

1.       Lack of top management support: This was the number one risk out of the fifty three that the authors listed. This isn’t surprising – a project that lacks executive support is unlikely to get the financial,  material or human resources necessary to make it happen.

2.       Ineffective project manager: Project managers who lack the communication and managerial skills needed to move the project ahead pose a serious risk to projects. The authors point out  that this is a common risk on IT projects because project managers  are often technical folks who have been promoted to managers. As such they may lack the interest, aptitude and/or skills to manage projects. Interestingly, the authors do not comment on the converse problem – whether the project manager’s lack of technical/domain knowledge contributes to project failure.

3.       No stakeholder involvement and/or participation: A large number of projects proceed with minimal involvement of key stakeholders. Such folks often lose interest in  projects when more immediate matters consume their attention.  In such situations a project manager may find it hard to get the resources he or she needs to get the project done. Stakeholder or sponsor apathy is an obvious warning sign that a project is headed for trouble.

4.       Uncommitted project team: The commitment (preferably, full-time) of a team is essential for the success of a project.  Management needs to ensure that team members are given the time (and incentives) to work on the project. A point that is often left unconsidered is the intrinsic motivation of the team – see this post for a detailed discussion of motivation in project management.

5.       Lack of technical knowledge/skills:  Project teams need to have the technical skills and knowledge that is relevant to the project. Managers sometimes wrongly assume that project staff can pick up the required skills  whilst working on a project.  Another common management misconception is that project personnel can master new technologies solely by attending training courses.   Getting contractors to do the work  is one solution to the problem.  However,  the best option is  to give the team enough time to get familiar with the technology prior to the project or, failing this,  to switch to a technology that the team is familiar with.

6.       Subject matter experts are not available: It is often assumed that subject matter experts can provide adequate inputs into projects whilst doing their regular jobs. This seldom works – when there’s a choice between the project and their jobs, the latter always wins.  Project sponsors need to  ensure that subject matter experts are freed up to work on the project.

Process-related early warning signs

1.       Unclear scope: The authors label this one as “Lack of documented requirements and/or success criteria.” However I think it is better described by the phrase I’ve used. All project management methodologies emphasise the importance of clear, well-documented requirements and success criteria –  and with good reason too. Lack of clarity regarding project scope means that no one knows where the project is headed – a sure sign of trouble ahead.

2.       No change control process:  As the cliché reminds us, change is the only constant in business environments.  It is therefore inevitable that project scope will change.  Changes to scope –however minor they may seem- need to be assessed for their impact on the project. The effect of several small (unanalyzed) scope changes on the project schedule should not be underestimated! Many project managers have a hard time pushing back on scope changes foisted on them by senior executives. Hence it is important that the change control process applies across the board – to everyone regardless of their authority.

3.       Ineffective scheduling and schedule management: Many schedules are built on little more than guesswork and an unhealthy dose of optimism, often because they are drawn up without input from the folks who’ll actually do the work (see my article on estimation errors for more on this). Schedules need to be rooted in reality. For this to happen, they must be based on reliable estimates, preferably from those responsible for creating the deliverables. Once the schedule is created, it is the project manager’s responsibility to update it continually, reflecting all the detours and road-bumps that have occurred along the way.  A common failing is that time overruns are not properly recorded,  leading to a false illusion of progress.

4.       Communication breakdown: Project communication is the art of getting people on the same page when they are reading different books. In my post on obstacles to project communication, I have discussed some generic difficulties posed by differences in stakeholder backgrounds and world-views. One of the key responsibilities of a project manager is to ensure that everyone on the project has a shared understanding of the project goals and shared commitment to achieving them. This is as true in the middle or the end of a project as it is at the start.

5.       Resources assigned to another project:  In my experience resources are rarely reassigned wholesale to other projects. What usualy happens is that they are  reassigned on a part time basis,  as in “we’ll take 20 % of Matt’s time and 10% of Nick’s time.” The problem with this is that Matt and Nick will end up spending most  of their time on the other project, leaving the one on hand bereft.

6.       No  business case: A not uncommon refrain in corporate hallways is, “Why are we doing this project?” No project should be given the go-ahead without a well-articulated business case. Further still, since an understanding reason(s) for doing the project are central to its success, these should be made available to every stakeholder:  a shared understanding of the goals of the project is a prerequisite to a shared understanding of the rationale behind it.

I’m sure there aren’t any surprises in this list –  most project managers would agree that these are indeed common (and often ignored) early warning signs of failure.  However, I suspect that there will be substantial differences of opinion regarding their ranking. Wisely, the authors have refrained from attempting to rank the risks – the list is not in order of importance.

Conclusion

Good projects managers  anticipate potential problems and take action to avoid them.  Although the risks listed above are indeed obvious , they are often ignored. Affected projects then  limp on to oblivion because those responsible failed to react to portents of trouble.  Granted, it can be hard to see problems from within the system,  particularly when the system is a  high-pressure project.  That’s where such lists are useful:  they can warn the project manager of potential  trouble ahead.