Module 11
This chapter starts with a concept that not only have I never done, I never thought it could be done, until Meredith pointed it out to me. The concept is planning the monitoring-controlling cycle. The monitoring-control of my projects has always been dictated to me, and usually required by my contracts. For example, if I had to present the status of my projects on the third Wednesday of the month, I had to write the report Monday or Tuesday, and for that I had to gather the requested information shortly before. I don't recall anyone asking me if the monthly reporting was appropriate. Nor if the level of detail I had to report was needed. The accountants wanted the expenditures for the last four weeks, unless it was a five week month ....due on Monday, unless Monday was a legal holiday, in which case it is due on the preceding Friday.....I worked as a subcontractor for one major worldwide engineering and construction firm, that published due dates and reporting requirements for ALL their jobs - one year in advance. The Project Controls Reporting Cycle was its name. There were no deviations permitted. If their clients wanted different reports on different days, we had to do two sets of reports, one for the home office and one for the client. Still Meredith points out that if you can, designing the reporting and controlling relevant to what is being controlled is best, and this should be designed in the planning phase of the project. He has good explanations of that planning process.
Anyone from the home office who tries to get information from a construction superintendent, with the question, "How's it going?," always gets the same answer, "Just fine." Field people are loth to tell the home office of their problems, unless they are clearly home office problems, like late paychecks. Some reasons for this are: 1. The superintendent wants to feel 100% responsible for his job, hence any problems are his problems and not the home office's. 2. The home office may send someone to his job to "help" him with the problem, which he believes will make the problem worse. 3. He believes the problem is actually his fault, and wants time to cover it up. 4. Lastly, and this applies to all project managers, "Project Teams detest progress reporting because it vividly manifests their lack of progress." Which is one of the Laws of Project Management. Those laws have hung on the wall of all my project offices at least the last 15 years. I have not been able to contact the original publisher, International Systems, but want to give them the credit.
Your author, on page 445, subtlety points out the danger of having rewards or punishments for the project team too closely tied to the budget and reporting system. That provides a tremendous incentive for loading the system in their favor. Also, it provides an incentive for key people to avoid difficult or "snake bit" projects, when those are precisely the jobs that need good people. Another difficulty is that the project boss may overstate his progress to get a bonus one year, then leave the company before things catch up to him. This seems shortsighted, surely the big bosses will notice this and somehow get their revenge? Not really. To the big bosses, it will appear the jobs were going very well when the former project boss was on the job, then crashed after he left. They will blame the new manager, who will blame the old manager. That's one reason for project auditing, which we look at in Chapter 12.
The concept of "Earned Value Chart," which starts on page 450, discuss various presentations of the fact that a project could be over budget with respect to the schedule, but under budget for the amount of work produced. There are many approaches to this problem and what is presented is about the best you can do, if you have work items that lend themselves to quantitative reporting.
