WTF?! No-BS PM -- Project Monitoring and Control

If you have no plan, you have no control!

Control is exercised by comparing where you are to where you are supposed to be, and taking action to correct for any deviations from plan.

Perhaps it goes without saying that the purpose of project management is to ensure that a project is completed on time, within budget and scope, and that the deliverable performs at the required level. Nevertheless, this is sometimes forgot ten. Furthermore, the only reason for planning a project is to enable the project manager to control work so that these tar gets are met.

However, all the planning in the world won’t ensure project control unless you have some way of measuring progress-that is, a way of knowing where you are. The definition of control is shown in the box. If you neglect any aspect of it, you can't have control. E.g., if you know that a deviation from plan exists but take no corrective action, then you are not controlling the job, you are simply monitoring it.

This does not mean that you get excited about every small deviation. There are tolerances in any control system.

E.g., the normal temperature control system in a room may vary about 6 degrees Fahrenheit, or about 3.5 degrees Celsius. Typically you can control construction projects to tolerances of about plus or minus 5 percent. For product development projects, this is likely to be around 15 to 20 percent. Trying to control any tighter than this means you are going to waste more time than you will gain benefits.

To know the real status of a project requires that you know about all four constraints-performance, cost, time, and scope.

MEASURING PROGRESS

We’ve discussed the four constraints that apply to all projects: performance, cost, time, and scope (PCTS). To know the actual status of a project, you need to know the values of all four constraints.

The easiest one to know is usually cost. This includes labor, materials, and capital equipment. In terms of work progress, only labor cost is tracked. Labor cost is the actual number of labor hours applied to the project multiplied by the labor rate paid to the people doing the work. Labor rate should always be expressed as burdened rate, not just the direct dollar-per-hour rate paid your employees. The burdened rate is the direct labor paid plus the overhead-what it costs the company for heat, water, utilities, rent, and employee benefits. This is the true cost per hour to do work. Unless you include overhead, your product development cost will be far too low.

Even though labor cost is usually easy to calculate, many organizations have no system in place to track it accurately.

Engineers, programmers, and scientists are often told to record only 40 hours per week for labor, even though they may actually work 60 hours on a project. This does not capture the true cost of the development effort, even though you don’t pay for the 20 extra hours expended on the job.

A basic premise is that you don’t want to plan a project so that overtime is required in order to meet original targets.

If you do, and unexpected problems arise, as they always do, then you won’t be able to use overtime to correct the problem. In addition, long periods of overtime have a severe effect on productivity. Studies have found that after about three weeks of overtime (at around 10 to 15 hours a week) productivity has declined to the nor mal 40-hour level, and errors have in creased.

This is bad enough, but what is often not measured is the indirect cost of absenteeism and turnover. When a professional person leaves because of job burnout, the cost to replace him or her is often $100,000 to $300,000! That's right. When you consider recruiting costs, loss of productivity while the replacement is learning the job, and agency fees paid, you find the cost to be extremely high. And even for skilled labor, the replacement cost is often in the tens of thou sands of dollars. Turnover is expensive!

Working time should be recorded daily.

Don’t plan a project so that overtime is required to meet the original completion date.

A Pitfall

When I was a young engineer, I had to record my project time weekly. I filled out and turned in my report on Monday morning. At that time, I didn't know what I know now, which is the value of these reports. To me, it was just a bother. Now I understand that the reports are necessary to know if the project is under control.

I also suffered from being unable to remember what I did a week prior to my report. We were supposed to record time at least to the nearest hour, but I had difficulty remembering if I was even at work on the previous Monday, much less what I worked on to the nearest hour, so I just put down what I believed I had done. I'm sure it was pure conjecture, but I didn't care. I had done my duty.

The only solution to this problem is to write down one's time at the end of the day. It takes about five minutes, which is not a big burden. However, I have had many knowledge workers complain about this becoming a bur den-and I have concluded they are really afraid of account ability. They haven't worked productively, or they are taking longer to do something than they estimated and are afraid of the repercussions. I'm sorry, but accountability is something we must all accept in exchange for the salaries we receive.

I've also had them complain that they are professionals and shouldn't have to record time. My response is that if they worked as consultants, the client would expect them to re cord time, so that they wouldn't have to pay for time the consultant worked for another client.

No matter the reason, tracking time is essential for control purposes, and I suggest that it be to no more than one-hour increments. However, it also needs to be down to the task level, not just to the project. That is, every task in the schedule must be tracked individually. If people just charge time to the project, that is useless for control purposes.

Tracking Performance, Time, and Scope

It can truly be hard to measure performance and scope in development projects. It’s relatively easy for something like building a brick wall. Your plan says the wall should be 10 feet high, 50 feet long, and a certain thickness. You measure these dimensions; it turns out the wall is the correct length and thickness, but it’s only 8 feet tall. I.e. scope is only about 80% of what it should be. This also means the work is behind schedule. Although progress is not perfectly linear, the schedule performance is about 80% of target as well.

Performance is judged by inspection. The mortar between bricks looks good, the wall is nice and straight, and it’s properly vertical, as shown by a plumb bob. Of course, there may be internal defects that inspection won't reveal, but you simply can't be certain of everything, so you make some assumptions.

Now try to apply this same measurement to knowledge work! Where is the engineering design, exactly? Or the code being written? Or the drawings being made? You simply can not measure these like you can a brick wall. This is why I prescribed the rule that knowledge work be broken down into one- to three-week increments, with a "marker" signifying completion. We don’t pretend to know where the work is during the week, only at the end of the week. It should be complete. Either it’s or it isn't. This is the best we can do. Our control will be more granular than is the case with other systems, but it will be functional to an acceptable tolerance.

A Progress Report Using a Gantt Chart

The Flaw in Most Tracking Systems

It may be that 80% of all project tracking is done using Microsoft Project (or some similar scheduling software).

Schedule status is shown by running a small bar inside the normal bars in the Gantt chart, as shown in ill. 1.

If you examine this schedule carefully, you will note that the weekends are shown as shaded vertical areas, and the schedule bars simply cross over them. Because they are shaded, we know that no work is scheduled on weekends. If it were, weekend days would not be shaded.

According to this schedule, task C is complete, task A is one day behind schedule, task E is right on target, and task D is one day ahead. Overall, the project seems in pretty good condition. (Now, it’s important to remember that this information is provided by the people doing the work.) If you were the project manager, you would no doubt feel pretty secure. No major problems are evident with the project. However, shortly after you receive status information from everyone, a member of the team drops by your desk and casually mentions that she felt sorry for Mary last week. You ask why, and she explains that Mary had a very difficult time with her work. Rather than taking the 40 hours she had planned to work, she actually had to work nearly 80 hours to get the job done.

This is a surprise to you, but then, Mary is a salaried worker so there has been no cost to your project budget, and she is on schedule. So, you agree that this is unfortunate, but it’s now in the past. The only thing to do is get on with the job.

Some of you reading this may not have fully realized the implication of Mary's situation. If she estimated she could do the work in 40 hours and actually needed 80 hours, then something is potentially very wrong. If her estimate last week was off by 100 percent, why should you believe her future estimates will be correct? They may be, but you shouldn't take this for granted.

The thing to do is to ask Mary what is going on. There are several possibilities. One is that this was a fluke and Mary is confident that future work won’t give her the same difficulty. In this case, you tell her to let you know if this assumption turns out to be wrong, so you can help her in whatever way you can.

Another possibility, however, is that Mary has come up against a "moment of truth." She realizes that she is in over her head. This work is taking much longer than she estimated, and there is no reason to believe this is going to change. Now you have to make some decisions. You may have to replace Mary with someone who can do the work as scheduled. Or, if nobody is available to do this, you may have to reschedule the work to show it taking twice as long as planned. This, of course, may impact the project end date, but it may be necessary. Or you may be able to subdivide the work so that someone can help Mary and thereby maintain the schedule.

One thing is certain-if Mary continues to work 80 hours a week for an extended period, you will come into the work area one day and find her collapsed on the floor. Furthermore, the quality and quantity of her work will get worse and worse.

The key point here is that reporting schedule progress alone does not provide vital information about the work effort being expended to stay on schedule, and when that level of effort is excessive, it indicates a problem that you need to address. For this reason, as I said earlier, you need to measure both time and cost (as well as performance and scope).

One common way to do this is a method called earned-value analysis. I have found that most organizations struggle with this approach, so I recommend that you initially just track schedule and cost in simplified form. Then, as your organization becomes more adept at managing projects, you can migrate to earned-value tracking. For in-depth material on using the earned-value approach,.

REPORTING PROGRESS

One widespread method of showing progress is the "stoplight" approach. Beside each task being tracked are one or two cells that are colored red, yellow, or green to indicate status. Green, of course, means the task is on schedule and budget. Yellow suggests concern about status, and red means that there is a definite problem. If you use two cells, the first one indicates status last week and the second status for the current week (or reporting period, if different than a week).

These simplified reports should always be backed up by hard data, so that any problem areas can be examined to determine their threat.

Reporting schedule progress alone does not reveal problems with the effort being expended on a project.

SUGGESTIONS / CAUTIONS

Don't try to solve project problems in a status review meeting-move these to a special meeting.

Never chastise someone in a meeting-never!

I have sat through many status meetings, and have observed some common flaws that should be avoided.

First, any problems that exist in a project should be dealt with outside the status meeting. Trying to solve problems during the status meeting bogs everything down and wastes the time of all attendees who are not directly involved in that aspect of the job. The problem should be dealt with in a special meeting that is scheduled after the status meeting ends.

Also, there should be no bloodletting in the review meeting. Even if people are "guilty" of actual misconduct, they should be confronted in private, not in public. Chastising people in front of others only leads to hard feelings, de creased morale, and a pervasive decline in incentive. Those members of the group who are not chastised know that it may be their turn next week, and everyone becomes overly cautious and risk-averse. This can be especially bad in an innovation project, because it often leads to "ho-hum" products.

Consider that what you really want to do about problems in projects is solve them. Your objective is not to beat up on people who have them. In addition, it’s clear that if you have no problems, it may mean that everyone is playing it too safe.

Working Together describes principles for managing projects who is now president and CEO of Boeing Commercial Airplanes. Several of these principles are important to follow in monitoring projects.

Clear Performance Goals

If every member of a project team is not clear about his or her performance goals, and how these will be measured, you have a prescription for disaster. In establishing goals, you should ask two questions:

What is the desired outcome? How will we know it has been achieved? The way in which the second question is asked allows for those situations in which no tangible deliverable is produced. Knowing the outcome has been achieved may only be possible qualitatively, rather than quantitatively.

The Data Sets Us Free

Status reports that conclude "I think it's okay" or perhaps "It's fine" leave much to be desired. As I said, it’s fine to use a stoplight report, but it should be backed up by data that validates the stoplight information. It’s amazing how often problems are described in vague terms. "There's too much thinner in the paint." How much is too much? Is it just a small amount or a large amount? By providing a measurement, people can tell how serious the problem actually is.

"We're working too much overtime." This is a judgment. Is the actual level two hours a week? Ten hours? Twenty hours? Unless we know the actual number, we have no idea if the problem is serious or not.

You Can't Manage a Secret

When people are afraid of being chastised for having a problem, they may hide it from everyone. Doing so prevents any action being taken to solve the problem. This may not be too serious if the problem affects only one group, but in projects this is never true for very long because all components of a project are interdependent. A problem in one area will eventually affect all of the others.

Encouraging employees to bring problems to everyone's attention so that those problems could be addressed. It’s definitely a good practice to follow.

Whining is OK--Occasionally

It’s common for managers to dislike emotion in the work place, but it’s a fact that human beings are emotional creatures, and the best policy is to allow people to "vent" occasionally. Let them express their fears, concerns, or even anger, so long as it does not get out of hand. To require them to suppress their feelings just means that they will come out somewhere else, and usually in a destructive form.

Propose a Plan, Find a Way

Still, we are all paid by organizations to solve problems, not just whine about them, so after we have vented, we are all expected to propose a solution. As I said earlier, this should be done in a special meeting rather than in the status meeting, but it should be done.

Only if a person has tried to solve a problem and has been unsuccessful should he or she ask for help. If the individual is unsure of his or her authority to implement certain courses of action, then someone in authority can be consulted, but this is not the same as dumping problems onto managers to solve.

Listen to and Help One Another

The word "team" is sometimes forgotten in projects. Unless it’s a one-person project, there will be others involved, and the climate should be one of cooperation and collaboration. In addition, you can't help someone unless you listen carefully to what they are saying. This practice promotes better team work and communication in any project team.

SUMMARY

It’s important to remember that the purpose of monitoring progress in a project is to ensure that it’s completed on time, on budget, and at the correct scope and performance levels.

This is another way of saying you are trying to exercise control. However, the word "control" often denotes the idea of controlling people, and this is not what you are trying to do! Rather, you are trying to control the project work, not the people.

In fact, the only way you will ever exercise control as a man ager is if every member of your team has control of his or her own work.

This cannot be achieved through micromanaging, either.

You must establish conditions whereby every individual is able to exercise self-control, and you intervene only when that individual demonstrates that he or she can't quite exert the control necessary to keep work on track. In the same way that you need an overall project plan to have control, every individual must be planning his or her own work at a sufficient level of detail to maintain control. You don't need to consolidate these plans into the project master plan-to do so would result in a huge, unwieldy plan. But you do need to see to it that the individual plans are being made.

Consider this. If any individual in your team goes out of control, she will eventually sink your entire project. If she uses up all of the float, she winds up on the critical path, and from that point on, every additional minute she slips pushes out the project end date by that same amount.

Finally, progress needs to be stated in measurable terms.

Having people say, "We're on track" is nearly useless. This is the one flaw in stoplight reporting. It allows people to "happy talk" themselves and others. Engineers are notorious in thinking they will solve technical problems in a flash, when in fact they have no idea how long it will actually take.

Unless you impose a healthy dose of skepticism on the team, it’s easy for everyone to fall into this trap.

This does not mean that you should become a tyrant and go around beating on everyone to determine their progress. It does mean that you take an active interest in progress, and let everyone know that your concern is solving problems, not attacking the staff.