Dealing with the Project from Hell (Just in time for Halloween!)

It happens to the best of us in the project management world. That one project that causes us to cringe every time someone utters its name. That project which causes us to lose sleep and count new grey hairs on our head as it lumbers forward.

Every project has its inherent stress factors. Some more than others. But every now and again, a project emerges that seems to take that stress to the next level. The circumstances can vary. Whether it be disinterested stakeholders or a sponsor that cannot seem to grasp the concept of a ‘predefined scope’. It could be a situation whereby the project team cannot come to grips with the deadline or deliverables and continue to argue about how the project should be executed. Or, in the worst circumstances, it could be ALL of those factors.

Whatever the situation, the project manager may find themselves with the most unenviable task of having to coordinate and deal with the project from HELL.

Whenever a project emerges that has copious factors working against it, the project manager needs to be extra vigilant. Even the most dire of project situations can often be salvageable. So it’s paramount to keep a few key points in mind:

Stay Focussed

It may seem somewhat trite, but a project manager is only human. And if their project from hell is but one of several other projects that fall within their scope, it is only human nature to try to avoid the situation. Yet it is in those circumstances where the project with the most problems associated with it should be tackled first. The project manager should begin to address the project, breaking apart its key constituent areas (sponsor, scope, stakeholders, resources, timeline, etc) and try to itemize where the key problems with the project exist. Amidst the frustration, it is inherently possible that a solution can be garnered if the project manager approaches the project as a detective would.

Be Diplomatic and Patient

Frustration can often lead to confrontation and animosity. And nothing can make an already tenuous project worse off than interjecting conflict. As the project manager, you must act as the key arbiter of any issues that may arise. If the problems with the project stem from personality conflicts between team members, then it becomes even more paramount that the project manager focus on smoothing fences between parties that disagree. Above all else, exercise patience. Many times, a conflict on a project between resources or stakeholders may have external factors associated with it. It is possible that team members have butted heads in other situations. Regardless, as the project manager, dealing with and finding a solution to any conflicts will go a long way towards getting the project back on track.

Don’t Get Discouraged

Any time a project is hitting the skids, the project manager may feel desperation start to set in. Especially in circumstances where the problem appears to be a lost cause. And in certain cases, that may be true. However, it is at those moments that the project manager should do their utmost to try to get things back on track. So it is crucial that one does not get discouraged and have complacency set in. Try looking at the project in a more positive light. Make attempts during project meetings to be a little more lighthearted. Whatever the technique, use the social skills in your arsenal to not give the impression of being defeatist. If the team members feel their project manager is discouraged and disinterested in the project, that will permeate through the team like a virus. Leading by example in times of project turmoil can go a long way towards breathing life back into the project.

Don’t Take it Personally

This is, arguably, probably one of the most important aspects of dealing with a difficult project. Often times, project managers take an almost maternal role with their projects. They develop a sort of symbiosis between themselves and the project and the success of failure of that project will often be very tightly tied with the feeling of success or failure of the project manager. Whenever a project starts to go bad, it is only human for the project manager to start to introspect and self-evaluate. Often times, their frustration with the project will start to morph into general frustration with themselves and their own abilities. And once they start second guessing themselves and their decisions, this will only spiral the problem into a deeper hole. While it is not easy to simply don your best Mr. Spock garb and be as unemotional as possible, it is imperative to try not to take the situation personally as a whole. Examining the project to determine its problem areas will help focus your efforts. If you discover the problems are related to aspects of the project that are outside of your control, that will go a long way towards restoring your confidence. And ultimately, it is important to remember: it is just a job and it is nothing personal.

Conveying Program Strategy

Dealing with project deliverables and conveying status in the form of success metrics or timelines (with milestones) is a key attribute of the project/program manager’s general responsibilities. Stakeholders, sponsors and team members will want to continuously be kept up to date on the various particulars pertaining to the successful movement of a project (or program) towards its net tangible outcome.

It goes without saying that projects and their superset programs generally have a set of quantifiable deliverables that are meant to be the natural outcome of the effort. Whether that be improvements in infrastructure, a product release, or a general process change or consolidation effort, every project and program will have some net outcome associated with it.

When one is dealing with the program level, often times, it is important to convey to stakeholders and the various team members of the constituent projects exactly what the end game of the program is. While it may seem obvious to some, as programs get instantiated and grow organically, they can periodically become more ambiguous or vague with regards to their overall strategy. A good example may be a ‘cloud’ strategy that is being adopted by a software company. While many may understand the concept at a high level, the actual strategy of execution for the program becomes a little more difficult to discern. And this often stems from the fact that some new initiatives are often the result of a brainstorming session at the executive level, which then percolates down.

Most project managers will understand how important it is to define ‘scope’ for their projects and ensure that actions being taken align with that predefined scope statement. In the same vein, a program (which can also have an aggregate scope), needs to very often define its overall strategy. And that strategy needs to be something with a little more bite than just a buzzword that was floating around during an executive offsite or brainstorming session.

From the standpoint of the program manager, what is often of paramount importance is to take the ‘high level’ strategy provided by the executives and give it some more tangible weight, through strategy discussions with the main stakeholders, key team members and the program sponsor or sponsors. So while ‘cloud’ may be a completely viable buzzword at the executive level, it is insufficient at the program level to convey the exact nature and long-term goal of the program as a whole.

With that being said, how should a program manager work towards defining the ‘core’ strategy of the program and how should that information be presented so that it is readily absorbed not only by the team members, but by the executives?

What is the Strategy?

While it may seem as almost a rhetorical question, in fact, it is often surprising how frequently you will get a diverse set of answers when one posits this question to a group of senior leaders. Their answers can often be attributed more to their position in the company versus the actual strategy itself. So in many cases, the answer provided by a marketing manager may differ from that given by a director of engineering, and so forth.

When it comes to strategy, a simple rule of thumb to follow when attempting to define it is to use the following three question approach:

1. Where are we today?

By this, the question is essentially alluding to what resources are available, what ideas do we currently have in the pipeline and what is currently in progress?

2. Where do we need to be?

In this case, the simple question can be summarized as asking what are the goals of the company or team? By positing this question after the initial one, it can almost immediately be determined if the current focus is matching the future expectations of everyone involved.

3. What are our options for getting there?

Once the corporation or team has a firm understanding of any and all discrepancies between their current focus and their desired focus, it becomes easier to discern what steps are needed in order to re-align current activities in order to achieve the desired goals. Also, specific constraints will surface during the discussions that will itemize what, if any, obstacles or bottlenecks might hinder the movement toward the desired goal.

Going from Point A to Point B

Based on the above, strategy can often be simplified in terms of simply going from one point to another. While it may seem like an oversimplification, that is essentially the crux of what a strategy defining exercise is attempting to convey. So something as simple as saying ‘We are currently a company that focuses on application level products but we are moving towards a client-less strategy’. The good thing about a simplified strategy statement is that, when it is well written, encompasses the business case in a simple, one line answer.

One very effective way to actually display the strategy in a graphical format, showing progress and dependencies is to use a PERT chart. For those unfamiliar with PERT, it stands for “Project/Program Evaluation and Review Technique’. A PERT chart is actually a pictorial way of showing movement of a project or program through its various paces until completion. The diagram below shows a simplistic representation of this concept:

As one can see based on a cursory view of the chart, it clearly shows movement from start to finish. PERT charts can actually become quite complex and often have intrinsic project timelines and completion dates as part of their function. But at a high level, they can also be quite effective to simply display where one is, where one would like to go, and the steps one must take to get there. The additional benefit of a PERT is that it can easily display activities that are dependent on one another versus those that can be accomplished in parallel with others.

Note: For further details on PERT charts and using them in your analysis, please consult the following posts:

PERT Analysis – Part 1

PERT Analysis – Part 2

Maintaining Focus on the Strategy

One of the most important aspects of a strategy session and its likelihood of success depends heavily on how much backing it has within the confines of the team or corporation. One must remember that a fundamental definition of strategy is not simply a brainstorming session. (Although it may start that way) It could often times be a fundamental shift in thinking, process and focus. With that being said, it is absolutely imperative that the mantra of the strategy be continuously re-inforced. People, when left to their own devices, can often become complacent as it pertains to any new ways of thinking or re-focussing of their efforts. Louis Vincent Gerstner, famous for changing the corporate culture at IBM, fought an uphill battle in moving the strategy of the company. Now while the strategy focus in your case may simply be a re-emphasis of existing efforts, a moderate shift in strategy, of a complete overhaul, what is important is that one maintains a high level of visibility of the strategy and ensures that everyone involved understands the focus and the movement forward.


If one wants to think of strategy, it is a simply a plan of action to achieve a specific goal. In military jargon, it might be a way to gain advantage over the enemy (destroying a supply line, taking over a key bridge, etc). In project terms, it is a goal to produce an end outcome or deliverable to achieve a specific result. (Usually increased revenue) Strategy can exist at the highest levels of a corporation or at the lowest levels of a small project. Regardless, the primary imperative is that the strategy is defined effectively and consistently applied. So long as everyone involved is aware of the strategy, can itemize it relatively easily and is aware of their specific tasks as to how it relates to that strategy, half the battle has already been won.