Project Management 101

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.

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.

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?

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.

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.

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.

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.