WHEN YOU TAKE OVER A STALLED PROJECT

Unless a good reason exists, I like to share my lessons learned. There’s no point in repeating mistakes that can be avoided if only someone had told me so. I believe that strongly. If a better way exists, wouldn’t you like to know about it? I would, so the four steps outlined below are a succinct summary of points that I’ve learned work and, even better, work reliably.

A project is stalled if it is drifting along and nobody is working on it. Somebody decided that it needed to be dealt with. Kill it or finish it.

The author is a practicing PMP (Project Management Professional). For more information, visit the Project Management Institute (PMI).

Here are the steps and their order. Following the steps do not guarantee that you will successfully turn it around. The steps, however, are best practices that have been tested and proven to work and work well.

1. Take stock of the project. Determine the current status of the project against the schedule (time) and budget ($). Analyze the results. It will guide you to the items that need attention. Why it it behind schedule? Was the cause a process or resource?

2. Develop a plan. It may be that the original plan just stalled because the sponsors ran out of money. Or perhaps the sponsors changed their mind. Find out. If funding can resume then you may just need to restart the original plan. Start imagining the solutions as you uncover the reasons that stopped the project. Be creative but pragmatic in developing the plan. Your developed plan, when ready, should be presented to the stakeholders or the parties that have a stake in the outcome of the project. The stakeholders are often the same ones of the original stalled project.

3. Reducing the scope of the work or the desired outcome is the easiest way to restart a stalled project. For example, should less work be performed? Can the result or outcome be reduced in quantity (five instead of 10) and/or quality (two instead of three layers)? The sponsors who provide the resources (like money) may be more inclined to resume if they learn that a lesser version of the outcome is possible.

4. New sponsorship must be found. This is critical. The sponsors may be new or of the original group. Do as much as you can to ensure that the new sponsors are committed to the project. You must get this commitment in the form of a Project Charter. It formally creates a project. A true charter will include a section that authorizes the expenditure of resources on the project and explains how it will be done. The charter is signed by the sponsors. It is a legal document.

Congratulations! The charter marks the start of the un-stalling. It marks the start of a new project lifecycle. After your team receive the charter, start the planning in earnest.

PROJECT MANAGEMENT: A BEST PRACTICE FOR PREVENTING SCOPE CREEP

A most insidious thing that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

After the project baseline has been created, the requirements of the project are cast in stone. The requirements were derived from the project’s scope. That means that any changes to the project’s scope will cause the requirements to change.

Until those changes are approved, the scope does not change and the requirements do not change. The requirements that any proposed changes will make are not official; they are preliminary.

Until those changes are approved, there are only “preliminary” requirements and “baselined” requirements. Train your people to distinguish between these two. Train your people to refer to the requirements of proposed changes as “preliminary” requirements. The official requirements are the ones that were cast in stone after the project and its corresponding scope were baselined. These requirements are “baselined” requirements. Thus, baselined projects have baselined requirements. Proposed changes bring preliminary requirements.

HOW IT WORKS

Consistently using these adjectives reinforces the fact that a baseline already exists and that any other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are added to the baseline. There is only one way for preliminary requirements to become a part of the project’s requirements—the origin of the preliminary requirements, namely the proposed change, must be approved.

The careful use of terminology is an effective way to create an environment that discourages scope creep. Here’s an example.

One way that a customer or a stakeholder can try to introduce change is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if it’s necessary.

THE SANCTITY OF THE BASELINE

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. The project baseline is the reference standard of the entire project.

The baseline captures the project scope. The scope, as discussed earlier, includes the requirements. The requirements are expressed in terms of time and costs. Time represents the project schedule. Costs represent the resources.

The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans.

At that point, it is very very important for the Project Manager (PM) to notify all stakeholders that "from this point forward, the team will be strictly adhering to the change control process." The PM must emphasize the seriousness of the change control process. After the stakeholders have signed off on the project plan, i.e., the baseline, the PM must emphasize that any changes must first be approved before its attendant requirements are added to the project's requirements.

DISTINGUISH DISTINGUISH DISTINGUISH

A proposed change can take the shape of an addition, revision, or subtraction of the project objective. If the change is accepted without going through a formal change control process, it becomes a part of the project scope. It becomes a part of the project’s requirements. This is scope creep. The scope changes incrementally, i.e., it creeps.

Train your team to always make the distinction between preliminary and baselined requirements and the environment will change. It’s a subtle thing but it works. Everyone will stay alert and know the difference between the original and the still-unaccepted requirements.

To reiterate, the team should never use the term “requirements” by itself. Never say or write it by itself with stakeholders and especially customer-stakeholders. Requirements are either preliminary or baselined. This reminds everyone that the scope and project requirements were already agreed upon and documented in the baseline.

IT IS ALL PSYCHOLOGICAL

I consider this to be a best practice for psychological reasons. Stakeholders, especially customer-stakeholders, tend not to take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, these stakeholders will continually propose changes that effectively create new requirements. Left unchecked, if these changes are passively acknowledged, stakeholders will learn to expect the acceptance of their proposed changes without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted.

IT BECOMES A TEAM EFFORT

Through this practice, the PM will not be forced to implement the ban on unauthorized changes alone. Team members will stay alert and know the difference between the original and the still-unaccepted requirements. This involves them in the fight against scope creep. The team helps the PM with one of the most vexing problems that confront a PM during the execution phase of the project, namely, scope creep. Training your team in the manner described above turns the effort to control scope creep into a team effort.

PROJECT MANAGEMENT: HOW TO DEAL WITH VAGUE OBJECTIVES

It’s not unusual for an objective to be initially defined vaguely for any number of reasons. It may be a first-time objective. It may not have been thought through all the way and it’s your assignment to flesh the objective.

Do not make the mistake of accepting a project that has a vague objective(s)!

In fact, even if the objective seems straightforward, I think it’s a good idea to check it against your SMARTs. This familiar technique—you can google it easily—ensures that the objective is really clear. If it doesn’t pass your SMARTs, then you have to push back and insist on further clarification.

Remember, you have to clarify it before you accept it.

SMART is an acronym for the five standards that must be met by your project objective.

Specific + Measurable + Agreed-upon + Realistic + Time-bound


Here are the details.

Specific

An objective must have enough specific detail so you know what the final product or service is supposed to resemble.

Measurable

Quantify the objective and use an objective standard if possible and desirable. Reduce subjectivity since it leaves too many things open for conflict.

Agreed-upon

The standards of performance must be established before the project gets underway. This is especially important when there are numerous stakeholders.

Realistic

Negotiate. Exploit the flexibility of the triple constraints. Frequently, a project seems too difficult or impossible because of the project’s constraints. If the constraints are negotiable, risk is lessened and the likelihood of success improves.

Time-bound

A deadline motivates action. A lack of urgency tempts people to procrastinate. Always have a time constraint.

Additional Remarks:

The SMART process is iterative, i.e., it uses successive rounds to zero in on the most precise solution. Be forewarned that this is a time-consuming process. On the other hand, time-consuming as it is, you can be sure that it will save even more time by preventing (or at least minimizing) the chance that you will have to re-do the project.

Try to meet all stakeholders at each round of the process. Do this for everyone’s sake. Stakeholders who are neglected or even just feel left out frequently tend to put pressure elsewhere on your project. Invite them since you need to protect their self-esteem and sense of participation.

Summarize and paraphrase each stakeholder’s input until the stakeholder agrees that you, the PM, understands.

At the end of each round, prepare a draft statement of the negotiated objectives and circulate it. Invite feedback and discussion.

You’ll know that the objective is clear when it passes the SMART test and is accepted by all stakeholders. Ideally, this group should include even those stakeholders whose objectives were eliminated. This group may not like the final decision but the important thing is their acknowledgment of the fact that their objectives will not be in the final project. Remember: the objective has to pass the SMART test and is accepted by all stakeholders.

This post originally appeared in my other blog. I transferred it here as part of the project to separate work-related materials from personal materials.