PROJECT CONTROL AND Assessment
Every step taken up to now has been for one purpose: to achieve control of the project. This is what is expected of a project manager: that she manage organization resources in such a way that critical results are achieved.
However, there are two connotations to the word “control,” and it is important that we use the one that is appropriate in today’s world. One meaning of “control” refers to domination, power, and command. We control people and things through the use of that power. When we say, “Jump,” people ask, “How high?” At least they used to. It doesn’t work that well today.
I have previously discussed the fact that project managers often have a lot of responsibility but little authority. Let’s examine that and see whether it is really a problem.
I have asked several corporate officers (presidents and vice presidents), “Since you have a lot of authority, does that authority guarantee that people will do what you want done?”
Uniformly, they answer, “No.”
“What does get them to do what you want done?”
“Well, in the end analysis, they have to want to do it,” they say.
“Then what does your authority do for you?” I ask.
“Well, it gives me the right to exercise sanctions over them, but that’s all.”
So we find that having authority is no guarantee that you will be able to get people to do your bidding. In the end, you have to get them to do it willingly, and that says you have to understand the motivations of people so that you can influence them to do what needs to be done.
A second kind of authority has to do with taking actions unilaterally—that is, without having to get permission first. In this sense of the word, we do have a lot of organizational problems. I meet project managers who have project budgets in the millions of dollars (as much as $35 million in one case), yet who must have all expenditures approved. If a project plan and budget have been approved before the work was started and if the project manager is spending within the approved limits of the plan, why should she have to get more signatures for approved expenditures? Only if a deviation from the plan is going to result should more signatures be needed, and then the plan should be revised to reflect those changes.
There are two kinds of authority: One is power over people, and the other is the ability to make decisions and to act unilaterally.
Consider the messages being sent to these managers. On the one hand, they are being told, “We trust you to administer $35 million of our money.” On the other hand, they are told, “But as you spend it, you must have every expenditure approved by someone of higher authority.” One is a positive message: “We trust you.” The other is negative. Which do you think comes through loud and clear? You bet! The negative.
A negative message always takes priority over a positive one.
Interestingly, we complain that people in organizations won’t take more responsibility for themselves; then we treat them as though they are irresponsible and wonder why they don’t behave responsibly!
So the first meaning of “control” has a power connotation. Another meaning is summed up by the highlighted definition which was introduced in an earlier chapter: Control is the act of comparing progress to the plan so that corrective action can be taken when a deviation from planned performance occurs. This definition implies the use of information as the primary ingredient of control rather than power. Thus, we talk about management information systems, and, indeed, these are the essence of what is needed to achieve control in projects.
Control: To compare progress against the plan so that corrective action can be taken when a deviation occurs.
Unfortunately, many organizations have management information systems that are good for tracking inventory, sales, and manufacturing labor but not for tracking projects. Where such systems are not in place, you will have to track progress manually.
Achieving Team Member Self-Control
Ultimately, the only way to control a project is for every member of the project team to be in control of his own work. A project manager can achieve control at the macro level only if it is achieved at the micro level. However, this does not mean that you should practice micro-managing! It actually means that you should set up conditions under which every team member can achieve control of his own efforts.
Doing this requires five basic conditions. To achieve self-control, team members need:
1.A clear definition of what they are supposed to be doing, with the purpose stated.
2.A personal plan for how to do the required work.
3.Skills and resources adequate to the task.
4.Feedback on progress that comes directly from the work itself.
5.A clear definition of their authority to take corrective action when there is a deviation from plan (and it cannot be zero!).
The first requirement is that every team member be clear about what her objective is. Note the difference between tasks and objectives, which was discussed in Chapter 5. State the objective and explain to the person (if necessary) the purpose of the objective. This allows the individual to pursue the objective in her own way.
The second requirement is for every team member to have a personal plan on how to do the required work. Remember, if you have no plan, you have no control. This must apply at the individual, as well as at the overall project level.
The third requirement is that the person have the skills and resources needed for the job. The need for resources is obvious, but this condition suggests that the person may have to be given training if she is lacking necessary skills. Certainly, when no employee is available with the required skills, it may be necessary to have team members trained.
The fourth requirement is that the person receive feedback on performance that goes directly to her. If such feedback goes through some roundabout way, she cannot exercise self-control. To make this clear, if a team member is building a wall, she must be able to measure the height of the wall, compare it to the planned performance, and know whether she is on track.
The fifth condition is that the individual must have a clear definition of her authority to take corrective action when there is a deviation from plan, and it must be greater than zero authority! If she has to ask the project manager what to do every time a deviation occurs, the project manager is still controlling. Furthermore, if many people have to seek approval for every minor action, this puts a real burden on the project manager.
Characteristics of a Project Control System
The control system must focus on project objectives, with the aim of ensuring that the project mission is achieved. To do that, the control system should be designed with these questions in mind:
imageWhat is important to the organization?
imageWhat are we attempting to do?
imageWhich aspects of the work are most important to track and control?
imageWhat are the critical points in the process at which controls should be placed?
Control should be exercised over what is important. On the other hand, what is controlled tends to become important. Thus, if budgets and schedules are emphasized to the exclusion of quality, only those will be controlled. The project may well come in on time and within budget but at the expense of quality. Project managers must monitor performance carefully to ensure that quality does not suffer.
Taking Corrective Action
A control system should focus on response: if control data do not result in action, then the system is ineffective. That is, if a control system does not use deviation data to initiate corrective action, it is not really a control system but simply a monitoring system. If you are driving and realize that you have somehow gotten on the wrong road but do nothing to get back on the right road, you are not exercising control.
One caution here, though. I once knew a manager whose response to a deviation was to go into the panic mode and begin micromanaging. He then got in the way of people trying to solve the problem and actually slowed them down. Had he left them alone, they would have solved their problem much faster.
Timeliness of Response
The response to control data must be timely. If action occurs too late, it will be ineffective. This is frequently a serious problem. Data on project status are sometimes delayed by four to six weeks, making them useless as a basis for taking corrective action. Ideally, information on project status should be available on a real-time basis. In most cases, that is not possible. For many projects, status reports that are prepared weekly are adequate.
Ultimately, you want to find out how many hours people actually work on your project and compare that figure to what was planned for them. This means that you want accurate data. In some cases, people fill out weekly time reports without having written down their working times daily. That results in a bunch of fiction, since most of us cannot remember with any accuracy what we did a week ago.
When people fill out time reports weekly, without writing down what they did daily, they are making up fiction. Such made-up data are almost worse than no data at all.
As difficult as it may be to do, you need to get people to record their working times daily so that the data will mean something when you collect them. What’s in it for them? Perhaps nothing. Perhaps future estimates will be better as a result of your having collected accurate information on this project. In any case, you need accurate data, or you may as well not waste your time collecting them.
When information collection is delayed for too long, the manager may end up making things worse instead of better. Lags in feedback systems are a favorite topic for systems theorists. The government’s attempts to control recessions and inflation sometimes involve long delays, as a result of which the government winds up doing the exact opposite of what should have been done, thereby making the economic situation worse.
There is one point about control that is important to note. If every member of the project team is practicing proper control methods, then reports that are prepared weekly are just checks and balances. This is the desired condition.
Designing the Right System
One control system is not likely to be correct for all projects. It may need to be scaled down for small projects and beefed up for large ones. Generally, a control system adequate for a large project will overwhelm a small one with paperwork, while one that is good for small projects won’t have enough clout for a big project.
Practicing the KISS Principle
KISS stands for “Keep it simple, stupid!” The smallest control effort that achieves the desired result should be used. Any control data that are not essential should be eliminated. However, as just mentioned, one common mistake is to try to control complex projects with systems that are too simple!
“No problem is so big or so complicated that it can’t be run away from.”
—CHARLIE BROWN (Charles Schultz, Peanuts)
To keep control simple, it is a good idea to check periodically that the reports generated are actually being used for something by the people who receive them. We sometimes create reports because we believe the information in them should be useful to others, but if the recipients don’t actually use it, we are kidding ourselves. To test this point, send a memo with each report telling people to let you know whether they want to receive future reports; if you do not hear from them, their names will be removed from the distribution. You may be surprised to find that no one uses some of your reports. Those reports should be dropped completely.
Project Review Meetings
There are two aspects to project control. One can be called maintenance, and the other aims at improvement of performance. The maintenance review just tries to keep the project on track. The improvement review tries to help project teams improve performance. Three kinds of reviews are routinely conducted to achieve these purposes:
1.Status reviews
2.Process or lessons-learned reviews
3.Design reviews
Everyone should do status and process reviews. Design reviews, of course, are appropriate only if you are designing hardware, software, or some sort of campaign, such as a marketing campaign.
A status review is aimed at maintenance. It asks where the project stands on the PCTS measures that we have used throughout this book. Only if you know the value of all four of these can you be sure of where you are. This is the subject of Chapter 11.
Process means the way something is done, and you can be sure that process always affects task performance; that is, how something is done affects the outcome. For that reason, process improvement is the work of every manager. How this is done is covered in the next section.
Project Assessment
As the dictionary definition says, to evaluate a project is to attempt to determine whether the overall status of the work is acceptable in terms of intended value to the client once the job is finished. Project Assessment appraises the progress and performance of a job and compares them to what was originally planned. That Assessment provides the basis for management decisions on how to proceed with the project. The Assessment must be credible in the eyes of everyone affected, or decisions based on it will not be considered valid. The primary tool for project Assessment is the project process review, which is usually conducted at major milestones throughout the life of the project.
“Evaluate: to determine or judge the value or worth of.”
—The Random House Dictionary
Purposes of Project Assessment
Sports teams that practice without reviewing performance may get really good at playing very badly. That is why they review game films—to see where they need to improve. In other words, the purpose of a review is to learn lessons that can help the team to avoid doing things that cause undesired outcomes and to continue doing those that help. The review should be called a lessons-learned, or process, review.
I have deliberately avoided the word “audit” because nobody likes to be audited. Historically, an audit has been designed to catch people doing things they shouldn’t have done so that they can be penalized in some way. If you go around auditing people, you can be sure they will hide from you anything they don’t want you to know, and it is those very things that could help the company learn and grow.
As Dr. W. Edwards Deming has pointed out, there are two kinds of organizations in this world today: those that are getting better and those that are dying. An organization that stands still is dying. It just doesn’t know it yet.
The reason? The competition is not sitting by idly. It is doing new things, some of which may be better than what you are doing. If you aren’t improving, you will be passed by, and soon you won’t have a market.
The same is true of every part of an organization. You can’t sub-optimize, improving just manufacturing. You have to improve every department, and that includes how you run projects.
In fact, good project management can give you a real competitive advantage, especially in product development. If you are sloppy in managing your projects, you don’t have good control of development costs. That means that you have to either sell a lot of product or charge large margins to cover your development costs so that the project is worth doing in the first place. If you can’t sell a lot of widgets, then you have to charge the large margin.
Good management of projects can give you a competitive advantage.
If your competitor, on the other hand, has good cost control, it can charge smaller margins and still be sure that it recovers its investment and makes money. Thus, it has a competitive advantage over you because of its better control of project work.
Additionally, in order to learn, people require feedback, like that gained by a team from reviewing game films. The last phase of a project should be a final process review, conducted so that the management of projects can be improved. However, such a process review should not be conducted only at the end of the project. Rather, process reviews should be done at major milestones in the project or every three months, whichever comes first, so that learning can take place as the job progresses. Furthermore, if a project is getting into serious trouble, the process review should reveal the difficulty so that a decision can be made to continue or terminate the work.
In order to learn, we must have feedback. Furthermore, we tend to learn more from mistakes than from successes, painful though that may be to admit.
Following are some of the general reasons for conducting periodic project process reviews. You should be able to:
imageImprove project performance together with the management of the project.
imageEnsure that quality of project work does not take a back seat to schedule and cost concerns.
imageReveal developing problems early so that action can be taken to deal with them.
imageIdentify areas where other projects (current or future) should be managed differently.
imageKeep client(s) informed of project status. This can also help ensure that the completed project will meet the needs of the client.
imageReaffirm the organization’s commitment to the project for the benefit of project team members.
Conducting the Project Process Review
Ideally, a project process review should be conducted by an independent examiner, who can remain objective in the assessment of information. The process review must be conducted in a spirit of learning rather than in a climate of blame and punishment. If people are afraid that they will be “strung up” for problems, then they will hide those problems if at all possible.
Process reviews conducted as witch hunts will produce witches.
Openness is hard to achieve. In many organizations, the climate has been punitive for so long that people are reluctant to reveal any less-than-perfect aspects of project performance. Dr. Chris Argyris, in his book Overcoming Organizational Defenses: Facilitating Organizational Learning, has described the processes by which organizations continue ineffective practices. All of them are intended to help individuals “save face” or avoid embarrassment. In the end, they also prevent organizational learning.
Two questions should be asked in the review. The first is, “What have we done well so far?” The second is, “What do we want to improve (or do better) in the future?” Notice that I am not asking, “What have we done badly?” That question serves only to make everyone defensive because people will assume that you will punish them for things done wrong. Furthermore, there is always the possibility that nothing has been done wrong, but there is always room to improve.
Finally, the results of the review should be published. Otherwise, the only people in the organization who can take advantage of it are the members of the team just reviewed. If other teams know what was learned, then they can benefit from that information. In the next section, we look at what the report should contain.
The Process Review Report
A company may decide to conduct process reviews in varying degrees of thoroughness, from totally comprehensive, to partial, to less formal and cursory. A formal, comprehensive process review should be followed by a report. The report should contain, at a minimum, the following:
image Current Project Status. The best way to do this is to use earned value analysis, as presented in Chapter 12. However, when earned value analysis is not used, the current status should still be reported as accurately as possible.
image Future Status. This is a forecast of what is expected to happen in the project. Are significant deviations expected in schedule, cost, performance, or scope? If so, the report should specify the nature of the changes.
image Status of Critical Tasks. The report should describe the status of critical tasks, particularly those on the critical path. Tasks that have high levels of technical risk should be given special attention, as should those being performed by outside vendors or subcontractors, over which the project manager may have limited control.
image Risk Assessment. The report should mention any identified risks that could lead to monetary loss, project failure, or other liabilities.
image Information Relevant to Other Projects. The report should describe what has been learned from this process review that can or should be applied to other projects, whether in progress or about to start.
image Limitations of the Process Review. The report should mention any factors that may limit the validity of the process review. Are any assumptions suspect? Are any data missing or perhaps contaminated? Was anyone uncooperative in providing information for the process review?
As a general comment, the simpler and more straightforward a project process review report, the better. The information should be organized so that both planned and actual results can be easily compared. Significant deviations should be highlighted and explained.
KEY POINTS TO REMEMBER
The meaning of control that is important to project managers is the one that concerns the use of information, comparing actual progress to the plan so that action can be taken to correct for deviations from the plan.
The only way a project is really under control is if all team members are in control of their own work.
The effort used to control a project should be worthwhile. You don’t want to spend $100 to purchase a $3 battery, for example.
If you take no action in response to a deviation, you have a monitoring system, not a control system.
Project working times must be recorded daily. If people wait a week to capture what they have done, they rely on memory and end up writing down estimates of what they did. Such data are no good for future estimating.
Project Assessment is done to determine whether a project should continue or be canceled. Process reviews also should help the team learn in order to improve performance.
