Overview
You have heard the old adage – plan the work and work the plan. In essence, that is the key to successful project management. You must first plan out the project and then monitor and control the execution of the program work.

Planning
It’s hard to overestimate the importance of proper planning. In general, project failures can most often be traced back to deficiencies in the planning process. There are three major deliverables from the project planning process – the Project Definition, the work plan, and the project management procedures.

Project Definition
Best Practice – Plan the Work, Utilizing a Project Definition Document
There is a tendency for projects to shortchange the planning process, with an emphasis on jumping right in and beginning the work. This is a mistake. The time spent properly planning will result in reduced cost and duration, and increased quality over the life of the project. The Project Definition is the primary deliverable from the planning process and describes all aspects of the project at a high level. Once approved by the customer and relevant stakeholders, it becomes the basis for the work to be performed. The Project Definition includes information such as:

• Project overview – Why is the project taking place? What are the business drivers? What are the business benefits?
• Objectives – What will be accomplished by the project? What do you hope to achieve?
• Scope – What deliverables will be created? What major features and functions will be implemented? What organizations will be converted? What is specifically out of scope?
• Assumptions and Risks – What events are you taking for granted (assumptions) and what events are you concerned about? What will you do to manage the risks to the project?
• Approach – Describe in words how the project will unfold and proceed.
• Organization – Show the significant roles on the project. The project manager is easy, but who is the sponsor? Who is on the project team? Are any of the stakeholders represented?
• Signature Page – Ask the sponsor and key stakeholders to approve this document, signifying that they are in agreement with what is planned.
• Initial Effort, Cost, and Duration Estimates – These should start as best guess estimates, and then be revised, if necessary, when the workplan is completed.

Project Workplan
After the Project Definition has been prepared, the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project. You should use a prior workplan from a similar project as a model, if one exists. If not, build one the old-fashioned way by utilizing a work-breakdownstructure and network diagram.

Best Practice – The Planning Horizon
Create a detailed workplan, including assigning resources and estimating the work as far out as you feel comfortable. This is your planning horizon. Past the planning horizon, lay out the project at a higher level, reflecting the increased level of uncertainty. The planning horizon will move forward as the project progresses. High-level activities that were initially vague need to be defined in more detail as their timeframe gets closer.

 

Project Management Procedures
Best Practice - Define Project Management Procedures Up-Front
This document contains the procedures that will be used to manage the project. It will include sections on how the team will manage issues, scope change, risk, quality, communication, etc. It is important to be able to manage the project rigorously and proactively and ensure the project team and all stakeholders have a common understanding of how the project will be managed. If common procedures have already been established for your organization, utilize them on your project.

Manage and Control
Once the project has been planned sufficiently, execution of the work can begin. In theory, since you already have agreement on your Project Definition and your work plan and project management procedures are in place, the only challenge is to execute your plans and processes correctly. Of course, no project ever proceeds entirely as it was estimated and planned. The challenge is having the rigor and discipline needed to apply your project management skills correctly and proactively.

Manage the Workplan
Review the workplan on a regular basis to determine how you are progressing in terms of schedule and budget. If your effort is small, this may need to be weekly. For larger projects, the frequency might be every two weeks.

Monitor the schedule. Identify activities that have been completed during the previous time period and update the workplan to show that they are finished. Determine whether there are any other activities that should have been completed, but have not been. After the workplan has been updated, determine if the project will be completed within the original effort, cost, and duration. If not, determine the critical path and look for ways to accelerate these activities to get you back on track.

Monitor the budget. Look at the amount of money your project has actually consumed and determine whether your actual spending is more than estimated based on the work that has been completed. If so, be proactive. Either work with the team to determine how the remaining work will be completed to hit your original budget or else raise a risk that you may exceed your allocated budget.

Best Practice – Look for Other Warning Signs
Look for other signs that the project may be in trouble. These could include

• A small variance in schedule or budget starts to get bigger, especially early in the project. There is a tendency to think you can make it up, but this is a warning: If the tendencies are not corrected quickly, the impact will be unrecoverable.
• You discover that activities you think have already been completed are still being worked on.
• You need to rely on unscheduled overtime to hit the deadlines, especially early in the project.
• Team morale starts to decline
• Deliverable quality or service quality starts to deteriorate.
• Quality control steps, testing activities, and project management time starts to be cut back from the original schedule.

If these situations occur, raise visibility through risk management, and put together a plan to proactively ensure that the project stays on track. If you cannot successfully manage through the problems, raise an issue.

Manage Scope
After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets, but by the project team working on major and minor deliverables that were not part of the original Project Definition or business requirements. Even if you have good scope management procedures in place, there are still two major areas of scope change management that must be understood to be successful – understanding who the customer is and scope creep.

Best Practice - Make Sure the Sponsor Approves Scope Change Requests
In general, the Project Sponsor is the person who is funding the project. While there is usually just one sponsor, the project could have many stakeholders, or people that are impacted by the project. Requests for scope changes will most often come from stakeholders – many of whom may be managers in their own right. It does not matter how important a change is to a stakeholder, they cannot make scope change decisions and they cannot give your team the approval to make the change. In proper scope change management, the sponsor (or their designate) must give the approval since they are the only ones that can add additional funding to cover the changes and know if the project impact is acceptable.

Best Practice - Guard Against Scope Creep
Most Project Managers know to invoke scope change management procedures if they are asked to add a major new function or a major new deliverable to their project. However, sometimes the project manager does not recognize the small scope changes that get added over time. Scope creep is a term used to define a series of small scope changes that are made to the project without scope change management procedures being used. With scope creep, a series of small changes, none of which appear to affect the project individually, can accumulate to have a significant overall impact on the project. Many projects fail because of scope creep and the Project Manager needs to be diligent in guarding against it.

Manage Risk
Risks refer to potential events or circumstances outside the project team’s control that will have an adverse impact on the project.

Best Practice - Identify Risks Up Front
When the planning work is occurring, the project team should identify all known risks. For each risk, they should also determine the probability that the risk event will occur as well as the potential impact to the project. Those events identified as high-risk should have specific plans put into place to mitigate them to ensure that they do not, in fact, occur. Medium risks should be evaluated as well to see if they should be proactively managed. (Low-level risks may be identified as assumptions. That is, there is potential risk involved, but you are ‘assuming’ that the positive outcome is much more probable.)

Best Practice - Continue to Assess Potential Risks Throughout the Project
Once the project begins, periodically perform an updated risk assessment to determine if other risks have surfaced that need to be managed.

Manage Issues
In spite of your best efforts at risk management, all projects of any size and complexity will have issues arise that need to be dealt with and resolved. If you have not done as good a job managing risks, chances are you will have more issues to deal with than you might have otherwise.

Best Practice - Resolve Issues as Quickly as Possible
Issues are big problems. The Project Manager should manage open issues diligently to ensure they are being resolved. If there is no urgency to resolve the issue, or if the issue has been active for some time, then it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Issues by their nature must be resolved with a sense of urgency.

In defining a project (also called defining the  "scope" of the project), you are setting parameters -- building the box to hold the project plan. The plan is the detail of how the project will be accomplished. The project definition tells you what is inside and what is outside the box. It sets limits on the project. A good project definition is defense against "scope creep"  that gradual (or not-so-gradual) expansion of the project as it unfolds.

When defining a project, it is also important to establish the difference between the necessary components and deliverables and those that are desirable but not absolutely necessary.

One way to do this is to define Needs and Wants. This yields a short list of those things that MUST be part of the project as opposed to a long list of all the things that COULD be part of the project.

Think of Needs as "black and white"  a Need must be met in order for the project to be seen as even minimally successful. A Want, on the other hand, is a "shade of grey."  some Wants are more important than others but, none of them are absolutely necessary for minimum success. Rank the list of Wants in order of importance  the most important at the top of the list and the others in descending order of importance down to the level of, "That would be nice but I really don't care."

Use the lists of Needs and Wants to evaluate What you propose to do with the project -- your proposed solutions. First, test proposed solutions against the Needs. Discard any that do not meet all the Needs. Next, test them against the Wants. Which solutions meet the most important Wants? Which meet the largest number of Wants? The solution that meets all the Needs and as many of the Wants as practical, is probably the best. 

Once you have defined the project, you can plan to deliver the required solution. Obviously, if you can meet all the Needs and the majority of the Wants, it is going to be seen as a resounding success. However, if all you can do is meet all the Needs and a few of the Wants, it can still be viewed as successful. 

Defining Needs and Wants is an excellent way to define the scope of a project and to set the parameters for project planning. It can be a catalyst for discussion about what is really needed from the project. And, it can force realistic decisions about what can and can't be done.

The project goal statement should be the driving force behind the project. It should be the touchstone against which everything done on the project is measured. A good project goal statement is SMART

• Specific
• Measurable
• Agreed-upon
• Realistic
• Time-framed

Specific: The goal should state exactly what the project is to accomplish. It should be phrased using action words (such as "design," "build," "implement," etc.). It should be limited to those essential elements of the project that communicate the purpose of the project and the outcome expected.

Measurable: If you can't measure it, you can't manage it. In the broadest sense, the whole goal statement is a measure for the project; if the goal is accomplished, the project is a success. However, there are usually several short-term or small measurements that can be built into the goal. Caution: Watch for words that can be misinterpreted such as; improve, increase, reduce (by how much?), customer satisfaction (who decides if they're satisfied and how?), etc. If you must include them, be sure to include how they will be measured. If you use "jargon" terms, be sure that everyone who reads them interprets them the same way. 

Agreed-upon: Does everyone in the organization have to agree that the project is necessary and desirable? No. Then who? Obviously, those who must do the project need to agree that it is necessary. Realistically, those individuals who control the resources necessary to get the project done need to agree that it is important. In addition, those who will be impacted by the project should agree that it needs to be done. Beyond that, agreement about the project is not likely to impact your ability to get it done one way or another.

Realistic: This is not a synonym for "easy." Realistic, in this case, means "do-able." It means that the learning curve is not a vertical slope; that the skills needed to do the work are available; that the project fits with the overall strategy and goals of the organization. A realistic project may push the skills and knowledge of the people working on it but it shouldn't break them. 

Time-framed: Probably one of the easiest PARTS of the goal to establish the deadline. Very little is ever accomplished without a deadline. This is particularly true of work that is in addition to everything else that you need to do in your day. Building the delivery deadline into the project goal keeps it in front of the team and lets the organization know when they can expect to see the results. 

Most effective project goals are between 25 and 50 words. They can be written on one side of a 3" x 5" card. They can be quoted at the drop of a hat.

Monitoring some projects is like herding cats; as soon as you get one piece pointed in the right direction, the others will find some new mischief to get in to. Still, you do have to monitor your projects in order to manage them. Tracking progress on a project should be a regular part of you daily routine, even if you have other duties that require your attention. Below are the things that should be check on regularly.

At the most fundamental level, you need to track the differences between what was planned and what is actually happening. This includes whether start and finish dates for activities are being met; how cost estimates are working out in reality; whether planned resource requirements are matching actual utilization; and, whether the expected outputs are being created. This may seem a bit self-evident but I have seen project after project slide further and further behind schedule solely due to a lack of effective monitoring of these most basic elements.

Regardless of the monitoring process you choose to use  face-to-face meetings, e-mail, written reports, periodic groups meetings, etc.,  you, as the project leader, have the responsibility of tracking the project. If you are not receiving the information you need, you must go and get it. Setting a clear expectation for progress and status reporting at the beginning of the project is an important step in keeping a project under control. However, if you set an expectation, for example, that status reports are to be submitted weekly, you must follow-up on it. If someone has not submitted a report by the deadline, you must contact them and get it. You can't very well make decisions about what should be done when the project gets off track if you don't know it's off track.

Monitoring the technical aspects of a project is usually where the energy is focused. Most project leaders, particularly inside organizations, are first and foremost, technical experts. In many cases, their technical expertise  not their project management skills -- is why they were given the project in the first place. However, if all the attention is placed on technical measurement, there is a strong likelihood that the things that will cause problems in the project will be team and interpersonal issues. I have never seen a project team "blow up" over a technical problem. Some projects fail due to insurmountable technical problems. Project teams fail over interpersonal issues. So, in addition to the monitoring those nice clean technical tasks, you must also keep an eye on the "health and welfare" of the team working on the project.

And, while we're on the subject of difficult-to-measure items, there is always the issue of monitoring the status of your project in light of every other project that your company is undertaking at the same time. Shifting priorities plague virtually every project. Keeping a "weather eye" on the changing priorities in your environment can warn you of impending problems in time to prepare for them.

Project monitoring is a process. It needs to be done constantly and consistently. Set the pattern at the outset of your projects. Plan how you will monitor progress right along with how you will accomplish the work. Set the process in motion and keep it moving from the beginning.

The issue of support from people outside your direct control is a common one. Most projects are staffed by people from several areas of the organization, rarely do they report (in the traditional sense) to the project manager. They are, in effect, "borrowed" resources and they're usually "borrowed" from someone who already had plans for them.

One way to build support is to carefully connect the goal of your project to larger goals in the organization. You should be able to show how achieving your project goal will further the goals of your own area. Try to develop the same connection between the project goal and the goals of those managers from whom you need support.

The farther up the organizational chain you can draw this line, the better. Start with your work group. Move on to your department. Then to your division, etc. Try to pick up the necessary managers along the way.

Depending on the project, you might try looking for goals that involve such things as interdepartmental cooperation; customer service improvements; productivity improvements; divisional revenue enhancements; new product introductions, etc. The tighter the connection, the stronger your case for the support. Using higher-level, longer-term goals as the basis for your request can frequently overcome short-term objections.

Talking to corporate executives across the country, I often find that project planning is an issue.  I developed this Trigger List to scan possible ideas to be considered in your projects. It is especially good when you're just brainstorming, and giving yourself permission to capture any and all ideas that pop into your head. (Download this Tip as Word doc here).

 

Resources

• Whose input do we need?
• Whose input could we use?
• Has anything like this been done before?
• What mistakes can we learn from?
• What successes can we learn from?
• What resources do we have?
• What resources might we need?

 

Executive issues

• How does this relate to the strategic plan?
• How does it relate to other priorities, directions, goals?
• How will this affect our competitive position?

 

Administration

• Who's accountable for this project's success?
• Lines of communication
• Methods of reporting
• What structures do we need?
• What planning is still likely to be required?
• What re-grouping will we need? How often?
• What people do we need?
• Current staffing?
• Hiring?
• Subcontractors?
• Consultants?
• How do we get involvement?
• What skills are required?
• Who needs to know how to do what?
• What training do we need?
• How do we get it?
• What other communication do we need?
• Who needs to be informed as we go along?
• What policies/procedures affected? What needed?
• What about morale? Fun?
• Staffing?

Finance

• What will this cost?
• How do we get it?
• What might affect the cost?
• Might we need additional $?
• What are the potential payoffs ($)?
• Who signs the checks?

Operations

• What is the timing?
• Hard deadlines?
• What might affect timing?
• Who's going to do the work?
• How do we ensure complete delivery?

Quality

• How will we monitor our progress?
• How will we know if we're on course?
• What data do we need, when?
• What reports, to whom, when?

Politics

• Whose buy-in do you need?
• How can you get it?

Stakeholders - Considerations?

• Board
• Stockholders
• Employees
• Suppliers
• Customers
• Community

Legal

• Issues?
• Regulations?

Space/Facilities/Equipment

• What requires room?
• How do you get it?
• What tools do we need? When?
• Phones
• Computers

Research

• What might you need to know?

Public Relations

• Is there value in others knowing about this?
• How do we do that?

Risks

• What could happen?
• Could we handle it?

Creative thinking...

• Who would have concern about the success of this project?
• What would they say, ask, or input, that you haven't yet?
• What's the worst idea you can imagine, about doing this project?
• (What is therefore the best idea, which is its opposite?)
• What is the most outrageous thing you can think of, about this project?
• How would a 12-year-old kid relate to this project?
• What would make this project particularly unique?
• What the worst that could happen?
• How could we deal with that?
• What's the best that could happen?
• Are we ready to deal with that?
• How do we feel about this project?

Many years ago, a good project manager might have gotten away with being a poor communicator. The business clients typically didnt like it, but as long as the project manager could deliver the goods, the client may have been inclined to let them do their own thing. In today's world, however, projects need to be undertaken in partnership with the business, and this partnership absolutely requires solid communication. In fact, many of the problems that surface on a project are actually the results of poor communication. Poor communication can lead to the following trouble areas.

• Differences in expectations. Project managers need to strive to ensure that everyone associated with the project has a common set of expectations in terms of what is to be delivered, when and at what cost. The place to initially set these expectations is with the Project Definition (Charter) document. However, many project managers do not keep key stakeholders up-to-date as expectations get changed. Perhaps it is just as simple as some stakeholders thinking that the project is going to be completed on December 31, when it has been extended until March 31. People make decisions based on the best information they have at the time, and if the project manager does not keep everyone under a common set of expectations, things can start to get out-of-sync fast.
  
  
• People are surprised. If people are not kept informed as to what is going on, they will be surprised when changes occur. For instance, if you are not going to be able to make your deadline date, you want to make sure people dont read it suddenly in a status report. Proactive communication means that you raise the potential of missing your deadline as soon as it becomes a risk. Then you continue to keep people up-to-date on the status. If you have to declare that you cannot meet your date, people are prepared. People get angry and frustrated when they find out bad news at the last minute, when there is no time left to have an impact on the situation.
   
• No one knows what the state of the project is . On some projects, people are not really sure what the status is. The communication on these projects is short and terse and does not give the reader a real sense as to what is going on. Again, people cannot make the best decisions if they do not have good information. If they are not sure about what is going on, they have to spend extra time following up for further information. In fact, if you send updates to stakeholders and they continually follow-up with you for more information, it is a sign that your communications are not targeted correctly.
  
  
• People are impacted by the project at the last-minute . This is a prime cause of problems. In this situation, the project manager does not communicate proactively with other people about things that will impact them. When the communication does occur, it is at the last minute and everything is rush-rush. For example, this happens when the project manager does not tell resource managers that team members are becoming available until the day they are released. Or it could include the project manager that knows for three months that a specialist is needed, but only asks for the person the week before. In each case, the other party is surprised by the last minute request and does not have time to adequately prepare. 
  
  
• Team members dont know what is expected of them. In the prior problem situations, communication problems surfaced between the team and outside parties. However, poor communication also occurs within a project team. Some project managers do a poor job of talking with their own team to explain what they are expected to do. Sometimes the project manager is not clear on when assignments are due. Sometimes the project manager has a vision of what a deliverable looks like but does not communicate that to the person assigned until the first attempt comes back wrong. Sometimes the project manager does not communicate clearly and team members spend time on work that is not necessary. Again, all of this causes extra work and extra frustration on the part of the project manager and team members alike.

Whats the solution?

Some project managers dont understand how to communicate well and are just poor communicators to begin with. If you think you are in this group, you should look for training or mentoring opportunities to become better skilled. However, in most cases, the problems with communication are not a lack of skills, but a lack of focus. Many project managers place communicating proactively on the bottom of their priority list. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum effort possible.

The key to communicating is to keep the receiver as the focal point not the sender. Try to think about what the receiver of the communication needs and the information that will be most helpful to them. If you are creating a status report, put in all the information necessary for the reader to understand the true status of the project, including accomplishments, issues, risks, scope changes, etc. If you are going to need a resource in the future, communicate proactively with the resource manager as early as possible. Then keep reminding them of the need as the time gets closer. For the most part, if you ever surprise someone, it is a sign that you are not communicating effectively. (The only exception is when the project manager is also surprised.) The project manager should also communicate clearly with their team. If you find people are confused about their end-dates or if they are doing work they dont need to do, think about whether you communicated to them effectively.

Many projects have problems. Poor communication can cause many problems and aggravate others. On the other hand, proactive communication can help overcome many other mistakes. Dont consider communication to be a necessary evil. Instead, use it to your advantage to help your project go smoothly with less frustration, less uncertainty and no surprises.

In most projects the project manager is responsible for the workplan and should update the workplan on a weekly or bi-weekly basis. In some cases, the project manager may ask each team member to update the workplan indicating whether their assigned work is completed.Team members typically are not allowed to assign themselves to new work, add new activities or otherwise alter the workplan. After the team members update the plan with current status, the project manager can evaluate the overall project status.

Team Resistance to Managing the Workplan

It's one thing to build a project definition and the workplan. It's another thing to effectively manage the project. If you could issue the plan and the work assignments and have everyone complete their activities on-time, the project manager's life would be much easier. However, the process of managing the team and the workplan is complicated because people don't always complete their work as expected.  

To understand how the project is proceeding and to ensure that it stays on track, the project manager needs to work with people and understand how the assigned activities are progressing. The project manager may need to go around and ask people how they are doing. The project manager may need people to send status reports and attend status meetings to understand the work status. However, people do not always respond well to these processes for a number of reasons.

• They may think the project management processes are cumbersome and are keeping them from completing their deliverables.
• They may feel they will be punished for bringing bad news or doing things incorrectly.
• They may not feel the project management processes are effective.
• They may have a normal human tendency against processes that feel like controls.
• Team members may have tried to follow the processes, but found they were not complete or they were not supported by other people on the project.
• They may feel that the project manager is not following the prescribed procedures.
• They may see people going around the processes without consequences.

Knowing and recognizing these normal human tendencies will help you design a set of project management processes that are appropriate to the project being managed. The project manager also needs to communicate the processes effectively, including their overall value to the project.

Changes to projects are almost inevitable. As project work progresses, discoveries are made, problems are encountered and solved, new requirements are discovered. All of these have the potential to change one or more of the three main constraints that bound any project -- Time (the deadline), Resources (the people, materials and money available to do the project), and Output (the required deliverables).

Any change that affects one of these constraints can seriously affect the ultimate delivery of the project. For instance, if the deadline is tightened, you will need more resources to deliver the same output. If the resources available are reduced (usually in the form of lost people), you will likely need more time to deliver the output. If the output requirements change (usually added functionality or features) you will need either more time or more resources. 

Sometimes, changes to a project occur in one major hit  a significant new feature or function is required. Usually, changes occur little by little, over the life of the project. These small changes, in and of themselves, are not significant. However, taken together, they have a serious impact on the project.

For purposes of self-protection as well as for good records, you should document every change to the project. There are several things you should make note of:

• Who is requesting that the change be made?
• What  exactly, and in detail  are they asking to be changed?
• What, in their opinion, is the priority of making the change? How important is it?
• What, in YOUR opinion, is the impact that making the change is likely to have on the project?
• What  exactly, and in detail  is going to happen to the existing project plans as a result of the change? What additional resources will be required? How much additional time will be required? Will it affect either the timing or the content of the delivery? Who needs to be notified about the change? Who is authorizing the change?

That last one, "Who is authorizing the change?" is the key. If you are in a position to authorize the additional resources, the additional time required, or the change in output, great. You can do it. If, on the other hand, you are not in a position to authorize it, your job is to get the information into the hands of whomever is in a position to authorize it. Write it up and get a signature.

You must keep current on the work being done on your projects. Information is the life blood of most projects. Regular, timely, accurate status reporting is critical.

Different projects have different information needs, but all of them share the basic need for timely, complete status updates on a regular basis. There is no substitute for face-to-face contact with project team members. Whenever possible, you should check on status personally. This doesn't eliminate the need for a good paper trail, however. So, you should also get written status reports on a regular basis.

There are four things you need to know from everyone:

1. What have you done since your last status report?
2. In the process of doing it, what did you run into, both positive and negative?
3. What did you do about what you ran into, both positive and negative?
4. What are you going to do next?

The first and last of these should be self-explanatory. Numbers two and three, could use a little more explanation. The information from "In the process of doing it, what did you run into, both positive and negative?" should give a clear picture of both the problems and successes that have occurred. Hopefully, the status report is not the first time you've heard about a problem that someone has run into. However, having the written record is a good way to ensure that problems, and their resolution, get tracked. But, you don't want to only focus on problems. It's nice to be able to track successes  those unexpected positive things that happen occasionally  in the same way. This is particularly important in the case of a discovery or an idea that could impact the direction of either the work being done or the project as a whole. As with problems, you need to track what is done with the successes.

The third question, "What did you do about what you ran into, both positive and negative?" should give you the details about the resolution or disposition of the problem or success. If it doesn't, or if you feel you need more information, go after it. You can't afford to have unresolved issues wandering around loose in your projects. 

When it comes to reports from people on the project team, the general rule of thumb for frequency is once a week. In some cases, once every two weeks may be enough. Rarely, however, is a gap of more than two weeks between reports desirable. Too much can happen in that time. You need to be more on top of things than that. When dealing with your need to report status to management, whatever they request is what you should do. If the status reports from your team are complete, developing a status report for the whole project should be relatively easy  just cut and paste.

Without encouraging "career-limiting behavior" I can only make suggestions about what you as a project manager can do the next time to cover your own posterior. (None of these suggestions address the behavior of the managers since this appears to be outside the scope of your authority and control as the project manager. Without the organizational authority to affect their behavior, there is little point in trying to impact them. You probably won't succeed and it may have serious repercussions for you personally.)

1. Don't take the situation too personally. There is a real danger in getting too emotionally "invested" in your projects. When this happens, anything that negatively impacts the project - whether you can do anything about it or not - takes on a sinister aspect. You must accept that there will always be things that will impact your projects over which you have little or no control. When these occur, you can only react as best you can with the good of the project as your primary aim.
   
   
2. Make sure that the impact of withheld information, resources, work output, etc., is clear. A good change-control process is helpful here. It allows you to describe the change being made as well as the impact of that change on the project. Document this and be sure that everyone who should be informed is informed.
   
   
3. Realize that shifting priorities are a fact of organizational life. Priorities change constantly in any organization. New challenges arise that require a response from the organization and that response requires that resources be moved from one activity to another. In most instances, those resources come from projects that are  as a result of the shift in emphasis  no longer as important as they were yesterday. Unfortunately, many times, the project manager is not told the reason they've lost their resources.
   
   
4. Document what happens. Always document the things that happen during a project. Never assume that "everyone knows why this happened." They may, but, then again, they may not, or they may have a completely different understanding of the situation. Try to document the occurrence in a factual way. Try to avoid accusations and conjecture about "why" the thing happened. Document what happened and the impact it had on the project. A good change-control system can help with this. This documentation should become part of the total project documentation and can be included as part of the final project report. A good, carefully worded narrative about why the project was delivered late can reference this documentation.
5. Use your sponsor. A sponsor is someone in a position of authority in the organization who has agreed to act on behalf of you and the project when an issue is outside your scope of authority and control. If you do not normally identify a sponsor for your projects, seriously consider doing so. One of the functions of a sponsor is to intercede in situations like the one you described. When a conflict occurs, the sponsor should be informed and asked for both advice and for direct assistance in resolving the conflict. The most common conflicts are over needed resources but they can also occur over issues of cooperation and delivery of work or information.

None of these suggestions directly address what to do about the situation that has already occurred. They are, however, something to think about for future projects.

It is not uncommon for a project to simply be too big or too complex to be delivered in its entirety by the deadline. In these cases, there is usually a way to deliver some (or most) of the output by the deadline and continue to provide the remainder once the initial pieces have been handed off. The problem is deciding which pieces are the most critical or most useful ? basically, where to put the limited resources for the greatest impact in the shortest time.

A Priority Matrix can be a useful tool for this. A Priority Matrix is a simple two-axis matrix in which the key features or functions of the project deliverable are listed and prioritize according to their importance.

List the features or functions down the left of the matrix. Limit the list to five or fewer items. Trying to prioritize every feature or function of a project is not only much more difficult, it is usually unnecessary. For most projects, there are a few critical features that must be included. All the others are simply enhancements or supporting pieces for these key items. Determine the five top features or functions. Create a set of five columns to the right of the features list. Head the columns 1, 2, 3, 4 and 5 respectively.

Prioritize the list with only one feature or function at each priority level. This is the key to this tool. Each item must have its own position in the priority structure. There cannot be two number 1 priorities. Once all the items have been prioritized, circulate the Priority Matrix among the stakeholders and customers of the project. You can add a list for their sign off if desired. Disagreements about the order of priority should be addressed and the final list approved by everyone.

The goal is to gain general agreement as to which features should take priority over which other features if all work cannot be completed by the deadline. The finalized Priority Matrix becomes a tool for decision-making about which PARTS to focus on as the project unfolds.

1. Project Charter Review
   Gain an understanding of the scope of the project, obtain background on the business unit and project type being presented, and establish the most efficient and cost-effective manner for meeting the expectations of the project sponsor.
   
   
2. Identify Project Organization: & Team Requirements
   Identify requirements as well as purpose for an executive steering committee, oversight board, or advisory team in addition to the personnel requirements for composition of project teams from both the business unit and the IT organization.
   
   
3. Conduct A Collaborative Project Team Kickoff Meeting
   The kickoff meeting will establish the baseline for the project activities to take place. Issues regarding project scope should be addressed and gain group consensus. Individual roles and accountabilities will be defined for all project stakeholders. Project auditing measures will be determined, and criteria for success will be agreed upon.
   
   
4. Analyze Business Requirements That Are Expected In The Project Deliverable
   Review all project-related documents, tools, findings, and recommendations and map them to the project plan, tasks and major milestones.
   
   
5. Audit Project Tasks & Resource Requirements for Each Project Activity
   Create a review process and evaluation of team member's workload, proactively identifying and resolving resource constraints or issues.
   
   
6. Review  & Monitor Project Goals, Objectives and Predicted Risks Through Project Life-Cycle Events
   Always keep aware of the project environment and any impacts they may alter the original goals or stakeholders expectations.
   
   
7. Establish Project Business Rules
   Practice the 3 C's cooperation; coordination and communication or your project is destined to fail.
   
   
8. Establish and Practice Change Management Principles & Processes
   Realize project plans are roadmaps and often detours come about. Be prepared for them before they happen.
   
   
9. Gain Group Consensus By All Stakeholders Before Making a Decision
   Remember projects are comprised of teams all with a voice in the outcome.
   
   
10. Live up to the label  - P.R.O.J.E.C.T.
11. P Planned

• R Rational
• O Objectives &
• J Justified
• E Expectations
• C Coordinated &
• T Team Driven

Dwight D. Eisenhower once said "In preparing for battle, I have always found that plans are useless, but planning is indispensable."

Project Management Training Sessions

I ran a couple of sessions with the same material, for the same organization, but with different groups. We ran simulations where the students were tasked with physically building a small but complex device.

Initially they try to build with virtually no planning, then they get another crack at it with this experience behind them, and finally they create a project schedule aimed at making the building process as efficient as possible.

Process

With the first group, this network planning session was extremely chaotic. It was difficult to discern any progress with the team. Several people voiced some frustration during the exercise, and indeed, nobody in the group managed to put together a complete network. Nobody could express which tasks were on the critical path, and nobody had a defendable expectation of how long the overall project would take. 

For the second group, there was far more visible organization. The teams disseminated and shared their knowledge very effectively. At the end of the planning session, each of the four component teams produced schedules that looked very similar, with critical paths and durations that all came in within 20% of each other. Every one was a credible plan of attack for building the device.

Both groups managed to identify all of the same optimizations to bring the overall project duration down, and had good ideas of how to resource the project effectively.

 

Results 

When they were unleashed to build the device one last time the first team, that had been so chaotic in the planning stages, ran like a fine tuned engine and completed the project in record time. The second group, despite building a credible schedule, ran out of time and was not able to finish.

The real kicker here is that the group that finished in record time, did so in a time that was within 10% of what was expected from the other group's schedules! It appears that while one group did a great job of building a schedule, the other group did a great job of planning how to build the device.

 

Conclusion 

In the real world, clients couldn't care less how pretty the schedule is if you never manage to deliver the product. That chaos during the planning activity was the necessary walking through of how the successful group would coordinate to get the job done.

It really isn't the plan that is important, but the activity of planning. The discussions and debate, sometimes heated arguments, can go a long way towards helping the team arrive at a common understanding of what needs to be done. 

Apparently, Eisenhower also once said "What counts is not necessarily the size of the dog in the fight, but the size of the fight in the dog." It seems that Dwight was a pretty wise fellow. -J.P.