Rescuing Troubled Projects

January 16, 2011

You are not impervious to having troubled projects in your portfolio. Any project can fail. Even the most seasoned and skilled project manager may, at one time or another, find themselves at the helm of a troubled project. Having a project in trouble does not necessarily signal the Project Manager is doing a poor job. Projects can go off course for a variety of reasons; some reasons are outside the span of control of the Project Manager. What are some of the common causes for projects to fall into troubled waters and what are some prudent steps to get the project back on course?
If you poll a group of seasoned project professionals with the question, “What are the chief causes of Troubled Projects?” you are likely to receive a variety of responses, though quite possibly there will be some commonly attributed causes. At the macro level, we put forth that projects generally fall into trouble for one or more of three reasons; 1) Poor Planning 2) Misaligned Expectations 3) Ineffective Risk Management. Let’s elaborate on each of these points.
Poor Planning: Planning is a foundation of project management. Within the context of this article, planning is not limited to the development of the “Project Plan”. Having a well defined Project Plan, with realistic estimates and work packages covering each necessary activity to achieve the project objectives, does not inoculate a project from falling into trouble. Proper planning includes identifying all project stakeholders, understanding their attitudes, influence levels, and communication needs, and ensuring the plan covers these needs. Additionally, proper planning for your project should include defining, gathering and properly documenting all of the project requirements. Vague or open-ended project requirements are a recipe for trouble in most situations unless your organization has mature processes or uses time boxing for requirements such as in Agile. Failure to capture all requirements and gain absolute clarity on them, can lead to too much change during Execution, and potentially derailing behavior on the project. It is not good behavior to debate with your key stakeholders “What the requirements really meant”; after the work has been performed.
For an example of aligning attitudes and expectations to avoid your project getting into trouble, imagine you work in a functional organization, and you know that project priorities and your Project Manager authority over team members is low. A functional manager assigns “his top person” to fill a key project role. Whilst this may “sound OK”, remember the type of organization you work in: this “top person” is likely to have competing objectives with the project, and it is probable that high-priority functional tasks will take priority over tasks for your project. So, instead of ignoring this risk or hoping for the best; set up the resourcing to succeed, by planning the work appropriately. This is one of many planning elements that can cause a project to veer into trouble.
Misaligned Expectations: Stakeholder’s expectations often change through a project’s life. Indeed, stakeholders themselves, including the sponsor, often change. Most project teams capture their stakeholder’s expectations at the start, and devise means of prioritizing and deciding when conflicting expectations exists. However, do you continue to pay attention to changing needs and changing stakeholders? Projects that fail to identify and respond to stakeholder changes (e.g. when new people come on board, and/or the organization needs to change direction) are prone to sway into trouble.
Have you worked on or known of a project where key stakeholders have suggested changes very late in the project (what could be called “constructive feedback” on what has been built)? Late changes, or the potential for them, can signal trouble quite quickly. A project should have a natural cycle that allows stakeholder’s “constructive feedback” and input in the requirements early, and to taper off as the project progresses through Execution. If you have properly planned, managed and captured stakeholder expectations, and have good communications in place, the level “feedback for changes” should be minimal and controllable.
Ineffective Risk Management: Risk management should underpin all project activities. Remember that risks can be positive (opportunities) as well as negative however there is no such thing as “positive trouble”. All trouble is bad. Risk management is not just about maintaining a Risk Register. It is about considering all risks, and devising ways – as a team – to categorize risks, devise ways to respond to them, agree on these responses and put actions into place to track them. Risks are related to all aspects of projects – schedule, budget, safety, quality and everything else. Ineffective risk management comes about when the project fails to carry out these activities properly. Trouble on projects can arise from the “unknown Unknowns”. Therefore, management and contingency reserves planning should be included in your risk response planning.

We have spent just a short time highlighting some of the things that can cause a project to sail into troubled waters. What steps can a project manager take to steer a project back on course if it finds itself in this position? Much research exists, and we do not propose to go into much detail in this article. Depending on the type of organization you work in, and the authority granted to you, the exact tasks will vary. Below are a few “corrective actions” that can span most types of organizations.
1. Early detection. Firstly, try to prevent it from straying into trouble. Projects do not normally fall immediately into trouble; they “take a path towards it”. Having a system and routines in place to provide early detection is key to limiting the impact when projects begin to display telltale signs of trouble. A project manager must be willing to “sound the alarm bell” and know that they have the support of the project’s key stakeholders to implement early corrective actions. However, many factors can prevent such early warning signs being recognized or heeded, which may be the subject of a future article.
2. Accept responsibility. The Project Manager and others must accept the responsibility for the project being off course (within their extent to control it). The Project Manager must also take responsibility for getting the project back on track – with the help of the right stakeholders. If the Project Manager cannot do this, management needs to work out how to help the Project Manager overcome the problems, perhaps with the help of a Risk Response Team that works alongside the main project team.
3. Be Flexible and open to feedback. Every project has a unique set of stakeholder and project team members. What may have worked well for you in previous projects, may not work best for your current project. Be willing to solicit feedback from your team and adapt the workings of your project as needed.
4. Be willing to re-contract or re-baseline. This is especially true if expectations have been missed. Consider the steps and processes used to identify, prioritize and agree on a collective set of project expectations. If needed, conduct a thorough review and be willing to go back to “square one” and revisit the business case for the project, ask “does it still align to strategy objectives” and “Is the project still worth undertaking?” Expectations do change and stakeholders change. Be willing to review expectations in your stakeholder routines and embrace changes via change controls if needed.

In conclusion, we have only covered a few aspects of troubled projects in this article. If you work on many projects in your career, it is likely that you will be, or have been, involved in a poorly performing project at some point in time. Key to limiting the damage is to know how to spot the signs, and to “stop the rot” early if you can. If it does happen to you, try stepping back and looking for the root causes of the problem (knowing that this can take time to do), don’t fall prey to rash reactions, and determine solid ways to address the problem or trouble proactively. Denial can be a powerful force preventing you from acting. Keep close communication with your project stakeholders, be open about things, and if you have to implement a mitigation plan, make sure you keep track of actions, and as positive progress starts to occur let them know how things are shaping up hopefully for the better.

The Color-coded Portfolio – Where is the Balance?

January 16, 2011

Regardless of whether you are a seasoned project manager or you are embarking on your first project, the use of “color indicators” or “symbols” to indicate the health or status of a project (or a program or portfolio) is most likely something you will relate to. We have touched upon it in a previous article titled “What Makes a Good KPI Framework”. The use of colors and symbols for project dashboards, project health, and project portfolio reporting is commonplace today in project and portfolio management. Whether or not you use traffic signal lights (i.e. Green, Amber, and Red) or other colors, the symbolism is the same. As an example, in the Green, Amber, and Red scenario, Green indicates “all is well”, Amber indicates corrective action is warranted, and Red indicates an important risk, issue or several of either need to be addressed and resolved. We support and encourage the use of this type of practice.
When you look into your organization’s portfolio, what do you see? Do you see a high portion of the same color (if colors are being used for metrics tracking) or a virtual rainbow spanning the reporting status spectrum? We contend that the key to using such status indicators is that they need to represent an accurate picture of health that can in turn provide a mechanism to enable “the right people to ask the right questions and get the right support”, to ensure work is appropriately managed. Let us elaborate.
To begin, let’s consider the purpose of project status indicators and why they are used. It is important that the agreed status (be it a Red light or something else) that signals “alarm bells” is not seen as an indication of poor project management or as poor performance by the project manager.
Status indicators are akin to warning bells on a ship. If you were traveling on an ocean liner, and a bell sounded indicating the ship was veering off course, would you rather know early, or wake to find the ship was in the Arctic when you were bound for the Caribbean (OK, this is a rather far-fetched scenario, but you see what we mean)? Project status reporting is similar in principle. If used properly, a project status report should provide early signals about the need for any corrective action and allow recovery back to the planned course (or an accepted re-baseline) with the least amount of variance.
A project manager who is reporting that a project is outside of the “all is well” boundaries of performance is raising the flag or sounding the alarm that the project is not progressing as planned, and corrective actions are warranted. The reasons why the project is “off course” may be outside the span of control of the project manager, or they may be within their control. The project manager is doing their job by sounding the alarm and aiming to ensure that sensible discussions can be held at the appropriate time to resolve the matter. Early detection of veering off course and quick action to head off impending problems is vital to minimizing the likelihood of problems that, if left alone, will negatively impact success. The Code of Ethics of institutions such as the Project Management Institute (PMI) supports accurate and timely reporting on projects.
At any given time, even the most seasoned project manager operating in an organization that has mature PMO and project management processes will have a project that sails into choppy waters. By definition, projects achieve something new, and there is no formula for guaranteeing the success of new initiatives (although it is of course important to learn lessons from previous initiatives). How your organization recognizes and responds to such challenges speaks volumes about the processes you operate.
There is no one magic ratio to indicate a healthy portfolio, program or project. Do you have standard rules (or metrics) to determine the indicator for each aspect of your project, or is it at the Reporter’s discretion to decide? This can be an important factor in how consistent your project status indicators are when you are reviewing a program or portfolio. Assessing against common standards is important. It is also important to understand the nature of the projects (their size, complexity, and risk). For example, you may have a high percentage of projects in the “all is well” category, yet these could all be low risk projects. Maybe one of your projects is an “outlier”, but it is much larger or riskier than the rest and could have a much bigger impact to your organization if it goes wrong. And size isn’t the only determinant of risk. Maybe one of your projects is small yet its success determines the success of many others, thereby being disproportionately important relative to its size. The concentration of summary status within a portfolio offers as much information about the organization assets as it provides about an individual project and the abilities of your project managers to manage their projects.
In conclusion, a portfolio at any given time will have a mix of projects, each with their particularities and status against metrics. The way that you use status indicators for reporting project performance and to anticipate future outcomes is an important mechanism to managing a portfolio. Instead of measuring a percentage of projects that are in the “not all is well” status, consider measurements such as how long projects stay in all types of status during their life, perhaps tracking it graphically. The duration of time that projects stay outside of an “all is good” (or whatever term you use) status may be a more telling measurement of project health than solely measuring the status of individual projects as a snapshot. If projects linger in “below par” status, it could be a signal of how your organization is responding or not to key actions required, or the project(s) not receiving needed resources or assistance. This may need calling out.

The Trouble with Continuous Multi-tasking, and How to Avoid It

January 16, 2011

Picture the following scenario: you have gone into a “quiet room” such as your office or den to write a long-term program or project plan that you have been meaning to get to for several weeks. The plan requires your full concentration, and it has taken you say three plus weeks to get to because of short-term issues and urgent requests from others that have continually taken priority.
‘Today’ is the first day you have managed to budget or decided to set aside time to work on it. You are fifteen minutes into your task, but you find yourself struggling to concentrate on it. Your mind wanders. Then you see an email come into the Inbox on your computer and also your mobile device, which you have put on the desk in full view – both flash at you with the new message alert. Without thinking twice, you open the email, digest its contents and click Reply. Upon finishing your response, you check something loosely related to it that you were working on last week…and in the space of twenty minutes you are disconnected mentally from writing the plan you set yourself the task of completing today… does scenario this seem all too familiar?
Take a moment to consider how much of your time at work you spend responding to ad-hoc tasks while having multiple tasks in progress at once, and compare this to the time you spend on what you consider to be your most important tasks. Does the balance of what you do match up with how you want it to be?
It is arguably true that we are all faced with more and more pressures to multi-task, particularly given the ease today with which we can be contacted, and with which we can contact others. Tackling several tasks in parallel can give us a feeling of high productivity (after all, it means we are achieving several things simultaneously, right?), but if we continually multi-task we may end up lacking the appropriate level of focus on the “must do” or important tasks we need to complete, and we may find it difficult to concentrate fully on these specific tasks when we need to.
The more tasks we undertake simultaneously, the more we increase our cognitive workload as those tasks vie for our concentration. If we get ourselves into a loop of continuous multi-tasking, we run the risk of paying “continuous partial attention” to the activities we undertake (because we have many things milling around in our mind). In fact the numerous switching from small task to task, then refocusing on larger tasks again can cause un-factored delays to your overall productivity.
It is true that 90% of a Project Manager’s job is communication, and project management requires us to wear many different hats, but that is not saying that we need to continually multi-task.
Much research exists into efficient ways of working. We do not propose to discuss such theory in this article; rather we wish to highlight some of the challenges of multi-tasking too much.
Here are a few suggestions to consider if you are faced with the challenge of “continuous multi-tasking”:
• Before you start work each day, think about what your known “must do” and important tasks are, and set yourself a goal to achieve them – whilst accepting that you won’t always be able to do everything, because unplanned things may arise that you urgently need to respond to, or other factors may impede your progress in your “target tasks” causing you to refocus on others. Don’t confuse what’s important or a “must do” with what’s urgent, however.
• As you think about your tasks, take a few minutes to analyze and categorize your daily task list into A, B, and C priorities.
o ‘A’s are your ‘must do – critical’ tasks that you know about, or potentially that crop up during the day. These need focus ahead of the B’s.
o ‘B’s are your ‘should do – important’ tasks. What you don’t complete today might become the A’s tomorrow.
o ‘C’ are the ‘nice to do – beneficial’ tasks that can hold off a while, or that you can work on when the A’s and B’s are done or progressed as far as they can be.
• When you know you need to focus on something important, block out time in your diary (calendar) and if necessary let people who work with you know that you will be working on it (you may want to let certain people know how to contact you in an emergency or if something comes up that is urgent to respond to, and to leave this particular “communications channel” open to them).
• Try switching off your electronic and phone messaging tools when you work on important tasks (or keep one “emergency channel or tone” available for the few people who you will allow to contact you).
• Turn off or set your status as “Offline” or “Do not Disturb” on your instant messaging application so others are not likely to “ping” you.
• If you are in a room, hang a ‘Do Not Disturb’ or ‘Priority Interrupts Only’ sign outside. Or a ‘Post-It’ note will do fine. If you are home and the family is there, would you consider wearing your office badge around the house which signifies you’re ‘working’ and invisible for the moment? You never know, it might keep you in a “work” frame of mind.
• When you have a complex or detailed task to undertake, know that it can take a while to get into the right frame of mind, so allow yourself time to “get into it”. Try to resist the temptation to veer off to “check new emails” and the like. If you have to, close Outlook or other email and take the phone off the hook.
• Remember that you are in control of the amount of attention you give to any given task.

In conclusion, the challenge of multi-tasking is ever-present today. How we choose to allocate time to our tasks determines what we are able to get done. Striking the right balance between multi-tasking and focusing on singular, important tasks that we want to complete is a challenge for us all.
We hope that reading this short article has not distracted you from something you were working on…!

The Anatomy of a Project Manager

July 31, 2010

Here’s some more “food for thought” from me, Gary Hamilton and Jeff Hodgkinson…what do you think makes a really effective Project Manager…?

The Unspoken Constraint of Project Management

July 31, 2010

I collaborated again with my colleagues in the US, Gary Hamilton and Jeff Hodgkinson, on another journal article. Gary kicked this one off, and it has proven very popular so far. I hope you find it an interesting read…

PM Power – food for thought…

May 31, 2010

I recently collaborated (again) with some colleagues in the US, Gary Hamilton and Jeff Hodgkinson, on another journal article. Jeff kicked this one off, and it has proven very popular so far.

The premise is this:

A Program or Project Manager needs to have a mix of attributes, but they have only two kinds of power: ’expert’ and ‘reverent or formal’ power. We believe that power or influence for a Program / Project Manager’s success primarily comes from their leadership qualities, and their expertise and ability to ‘walk the talk’. Manager’s power is primarily derived from the expertise and experience they possess in managing their work and/or the process or product contained within the chartered initiative. It is not necessary to know everything about the project being delivered, but the ability to energise people into action and to work towards a common goal, whilst recognising that each individual may have different perspectives on the meaning of success, is a prerequisite to achieving success.

I’d be interested in any views on this…see the link below for more details…

Some thoughts on Benefits Management

April 2, 2010

For a number of months I have written articles and presented at Seminars on the topic of Benefits Management and Benefits Realisation. I believe this is a fundamental issue for achieving successful portfolio, program and project ourtcomes.
A simple methodology can be applied to attain Benefits Realisation, to ensure:
1. Project benefits are clear, concise and relevant in ‘value creation’ terms from the Business Case onwards, and that they directly relate to your organisational strategy
2. People are held accountable for achieving these benefits
3. Benefits stated in a Business Case are actively verified in the scope development and “build phase”, and measured throughout the entire initiative, ie During the project lifecycle (particularly if it is released in phases), After the project is closed and When the product/output starts to be used.
4. Appropriate action is taken if required to alter direction (i.e. the organization changes course and the intended project benefits are no longer relevant)

A link to one article I have written is provided below – I would welcome all thoughts on it…

Project Success Planning – setting yourself up to succeed!

March 7, 2010

I recently co-authored an article about Project Success Planning (or PSP for short). Please find the link to one Journal link (to the Project Times) below:

http://www.projecttimes.com/articles/project-success-plans-planning-for-success.html

I would be interested in comments from everyone about it…

Welcome to thoughts about Portfolio, Program and Project Management

March 7, 2010

This Blog is about Portfolio, Program and Project Management. I will be writing about aspects of this discipline and will provide links to articles that I write along the way…I hope you find it useful…