Project administration methodology

INTRODUCTION

What This Article is About?

This article describes how to implement project planning, tracking, and reporting in order to control a large, complex project when many of the project team's managers and participants have limited prior experience implementing formal project management. The Project Administration methodology, which evolved as a byproduct of the Somers Project, is one step removed from hands-on project management. It provides a project administration service for the project managers, helping them to define their plans, coordinate their activities across many organizations, and motivates them to maintain their committed schedules. The techniques that became Project Administration as the Somers Project progressed will be described against the backdrop of this live example. It is hoped that readers will find this information useful for planning and controlling their own projects.

Project Administration Objectives

Project Administration focuses on two objectives. One is relieving the project team to as great a degree as possible from the burden of project management's administrative responsibilities. The second objective is achieving schedule control. It views project management as a process control system. Once plans are built and the project is executing, a feedback loop is provided in the form of clear, easy to understand status reports which the project participants and managers use to adjust their activities. The commitment of the project's executive sponsor is leveraged to motivate the project managers and participants to respond to the feedback. It is the challenge of the PA (Project Administrator) to ensure that the reports are clear, focus attention on what needs to be done by whom, and see that each project manager and participant knows that everyone including the executive sponsor is receiving the reports.

What is the Somers Project?

Somers is a brand new five-building site built to house 2,300 headquarters executives and staff for the five lines of business, and their domestic divisions, of the IBM Corporation. It lies 50 miles north of New York City in rural northern Westchester County. See area map (Figure 1) and site diagram (Figure 2). The central services building (CSB) houses the 58,000 square foot raised floor (computer room) facilities and the computer operations staff as well as the other common site facilities such as the cafeteria, conference rooms, auditorium, supplies, medical staff, security, banking, sundry shops, etc. The four office buildings (OBs) house the headquarters executives and their staffs.

Figure 1. IBM Somers Location

Regional Headquarters I/S (Information Systems—formerly known as data processing) is part of the ES (Enterprise Systems) line of business. Regional HQ I/S has been consolidating an increasing number of computer centers in the New York, New Jersey, and Connecticut area for the other IBM lines of business and their divisions over the last several years. Each system HQ I/S takes over is “regionalized” so that its software and operating characteristics become similar to the other systems in the region for ease of maintenance and operations. Regionalization in this and other IBM U.S. regions has saved the corporation a considerable sum of money and headcount.

Figure 2. IBM Somers Site Plan. Certificates of Occupancy (C/O) were issued in November 1988 for the Central Services Building, December 1988 for Office Building (OB) #2, February 1989 for OB #1, June 1989 for OB #3 and August 1989 for OB #4.

Thus in preparing for the move to the new Somers headquarters facility it became the task of Regional HQ I/S, which already operates many of the systems in the area, to prepare the site for the systems we operate wire the buildings and all their offices for workstation communications and printing capability, move all regional computer systems to the new site, and move the executives’ workstations to the new site as each of them moved.

Figure 3.

John Stone was the director of Regional HQ I/S at the start of this project. His July 1988 memo to his organization (Figure 3) outlines his objectives for the Somers Project:

Project 1: Fitup the Somers CSB I/S facility and four OB.

Project 2 Move 2,200 headquarters lines of business people from lower Westchester to Somers, and

Project 3: Relocate all regional customer computer systems to Somers.

And his criteria for success:

• Meet the committed schedule
• No disruption in customer service
• Achieve the stated financial goals

Project Management Challenges

The Somers Project had neither a sharp starting point nor a firm set of end objectives. Planning for the site had begun in the early ‘80s. HQ I/S could plan the floor layouts and cabling and order equipment, but could not do any physical work at the site until the C/O (Certificate of Occupancy) was available for the CSB. But construction delays made the C/O dates for the five buildings almost impossible to predict.

The end was not well defined because negotiations continued with other organizations to regionalize and move their systems during the life of the project. When the project was over, a number of systems had been moved that were not anticipated at the start.

Project timing was squeezed from both ends. C/O dates were constantly being delayed. And leases on office space where our future Somers tenants worked were coming up for renewal, challenging us to build schedules that would prepare the facilities and move people and equipment to Somers before we incurred the costs of lease extensions. Thus the project teams, when finally under way, had to execute as efficiently as possible to avoid penalties.

This was far and away the largest, most complex project the Enterprise Systems Regional HQ I/S had ever attempted.

Complexity

Figure 4 conveys, at a high level, an example of the complexity of the project in terms of both the many hardware interfaces and organizational interfaces. The upper portion represents the Somers site and the lower portion a typical site in lower Westchester. The center of the diagram indicates the names of each organization responsible for the components directly above and below them. For example, Network Implementation is responsible for wiring 3299s and workstation drops in both the Somers OBs and lower Westchester sites. Eight different organizations are represented across the middle. Three—NSD, NPN, and RECS—are outside the Regional HQ I/S directorate.

Regional HQ I/S Project Management Achievements

The C/O for the CSB finally materialized at the end of August 1988. The project team fitup the CSB and prepared the facility for the first occupants to move by the end of October. Over a fourteen-month period from August 1988 to October 1989, the 150-person project team moved eighteen computer systems and 2,300 executives and staff personnel to the five-building complex. Twenty-six first-line organizations crossing three corporate vice presidencies defined 210 plans containing 5,472 tasks. They coordinated 30 person-years of work effort, an average of 112 tasks involving 88 person-days of work effort per week. Fifty major milestones were completed on schedule to the exact day with no disruptions to customer service, and the project's financial objectives were exceeded.

Figure 4. Somers Project Fitup

ENVIRONMENTAL CONDITIONS FOR SUCCESS

Four environmental factors contributed to the success of this effort. Three are the raw materials, the fourth is the glue.

Raw Materials

1. Strong executive sponsor. At the start of the project HQI/S director, John Stone, made his vision for this project perfectly clear in his July 1988 memo to the organization. All levels of management recognized that their performance appraisals would be tied totheir contribution to the project's success. When Phil Daddona took over as director in September 1988, he continued that commitment.

2. Competent, experienced, motivated doers. “Competent” participants are expert at what they do and get it done right. Competent people at all experience levels make a significant contribution. The optimum mix of experience levels is a challenge when forming a project team.

“Experienced” plan contacts, responsible for planning, were able to give accurate estimates of how long each of their team's tasks should take.

“Motivated participants fill in the missing pieces. No matter how much care is taken in the construction of detailed project plans one can never account for all the detail or unforeseen events that must be handled.

“Doers” don't obsess over their plans, what they're going to do, or how they are going to do it. They act. They make it happen.

3. Sufficient resources. Without sufficient money, materials, space, supplies, tools, equipment, etc., project success will be threatened.

The Glue

4. An independent project management organization. Project Administration takes place in a separate organization reporting directly to the project's executive sponsor. It provides a project management service for the project teams and relieves them of most of the planning, tracking, and reporting responsibility. This organization consists of a PA (Project Administrator) and several project managers. The PA helps the participating organizations define their plans, and then tracks and reports their progress. The project managers are called upon as required to manage parts of the project that the responsible line managers have difficulty handling. Thus the organization provides all the project management tools, skills, and services needed by the project teams. Pete Lambertson's Relocation Planning department provided the independent project management organization function for the Somers Project.

EVOLUTION OF PROJECT ADMINISTRATION

Startup

I joined Pete Lambertson's Relocation Planning organization April 15, 1988. My function, although not known by that title at the time, was Project Administrator. The C/O for the CSB was anticipated in May. Planning of the facilities had been underway for some time. Each organization had a task plan and, at a high level, there was a management objectives Gantt plan for CSB fitup hand-drawn by Pete on a set of flip charts. Coordination meetings consisted of reviewing lists of task dates maintained in text form. No project management tools were employed. When the C/O date for the CSB slipped from May to June everyone was relieved that some additional preparation time was available. It was believed that a project management tool could pull the existing plans into a coherent interrelated sequence of events.

The Project Management Tool

This article will not address the choice of a specific tool but, instead, will describe in general terms the characteristics that a tool should have in order to support the Project Administration methodology It cannot be overemphasized that the key to PM success is not the tool, but rather closing the loop between planning and doing using feedback and motivation.

Determining Responsibilities

At the beginning of May I began to interview participating managers about their rolls in the project. Each manager was asked to assign a plan contact person, usually a team lead, who would be able to provide as much detail about their organization's plan as required. Later the plan contact would act as spokesperson, reporting progress against their plan as it was executed.

Building Plans

May, June, and July were spent building detailed plans with each organization. Each plan contact visited my office with his hand-written plan. We would bring up the project management tool and I would enter the plan as he described it. Because the tool created and displayed his Gantt plan as he spoke, the plan contact would get very involved in his plan construction.

Figures 5a and 5b show the contact naming his plan and picking a start date. Figure 5c shows the Gantt calendar displayed with his start date at the beginning. The columns are defined in parentheses on this figure for the reader's reference. Figures 5d through 5j show an example of the task entry screen sequence that the contact saw as his plan evolved during the interview. For the purpose of this illustration, the plan is kept small and the tasks are sample tasks.

Figure 5c.

Each task was defined in termsof its business-day duration, who would perform the task, and how many person-days of effort each worker would expend. At the end of the task entry sequence, Figure5k, we would go through a question and answer session to determine dependenties. “What must happen before this task can take place?” is the key question asked of the plan contact. This usually led to the specification of additional tasks the contact had not anticipated, or the identification of required tasks he depends upon from other organizations. Figures 5l through 5o show the detendency definition screen sequence.

Figure 5q shows the result of auto-scheduling the plan after having defined the dependencies. The “C”s indicate tasks on the critical path. With the first task starting March 8, the resource summary below indicates that Sig Holtz will be working overtime, 5.9 days, the week of March 13. Now the contact tells us his plan's anticipated start date is March 20. In Figure 5r we shift the first task in the plan to March 20 and lock it (indicated by the “L”) so that the task won't move when the plan is re-auto scheduled. Figure 5s shows the result of re-autoscheduling. Note that Sig Holtz's overtime disappeared because the work he was doing now spans two weeks. The plan contact is satisfied that this plan represents what his organization will do. Figure 5u is a copy of the printout the contact will take back to discuss with his manager and the rest of the team. Managers were expected to either concur that this is their plan or send their contact back for rework. Through this process every manager became committed to his plan of record.

The plan-building interview is key to bringing project management disciplines to a project team quickly and efficiently. Neither the participants, their managers, nor the team leads needed to be burdened with learning a PM tool. Yet they were able to take advantage of its capabilities in defining their plans, and they were a fully committed to the result. By scheduling interviews, we were able to control how quickly the plans were built. No matter how thoroughly prepared the plan contact was when he came to the interview, our interaction with the PM tool always produced a surprising amount of additional details the contact had not anticipated.

The speed, flexibility, and ease of use of the PM toolwas critical to expediting this process and holding the plan contact's interest. The tool needed to have the ability to copy, move, export, import, shift, and delete ranges of tasks. And it was important to be able to see changes in the utilization of resources at the bottom of the Gantt as changes were made to the Gantt so that the plan contact could play what-if scenarios to his satisfaction. A tool requiring longfill-in-the-blanks data entry sequences with delayed graphic feedback after each change would have lost the contact's involvement.

Reconciliation I

There are two phases to plan reconciliation. The first phase reconciles plan interdependencies. During July, as final plan rework was taking place, plan interdependencies were reconciled. These were tasks a contact claimed another organization was doing for him. In some cases, we could recognize the task in the other organization's plan. In other cases, the other organization had defined the task in wording that was not clearly recognized as the needed task. Sometimes the other organization didn't know about the task they were expected to do and we had to reconcile who was actually going to perform the task. Usually interplan reconciliation could be accomplished over the phone.

Where there was a great deal of interdependence between plans, they were combined into a single large parent plan and the pieces owned by different organizations were called subprojects. Subprojects appeared in their parent plan separated by a space and each contained an indented heading with the name of their organization or function.

An important feature of the PM tool we used allows a task, group of tasks, or an entire plan to become a single task in another plan. Thus your plan, with dependencies on other plans, could reference tasks they depended upon in those plans. Other plans could reference tasks in your plan.

This feature can be used to summarize all plans in a project into a few lines on a single plan by referencing groups of tasks or an entire plan as one task line on the summary plan. We never used this capability on the Somers Project, but many people feel that this ability is necessary to provide high-level reports to management.

Once all plans were built, interrelated, and committed, the entire group of interdependent plans was autoscheduled to produce an integrated cross-organizational set of plans.

Reconciliation II

The second reconciliation phase involves reconciling the “Management Objectives” plan with the detailed plan put together by the plan contacts. Peter Lambertson's hand-drawn Gantt on flip-chart paper represented the management objectives plan for the CSB fitup phase of the project. Management's fitup schedule predicted the first Somers tenants would move into the CSB 60 days after the CSB C/O date. The integrated detailed plan built from the interview process showed 120 days of work effort. The two plans needed thelr differences recontiled and a schedule agreed to that was possible.

Reconciliation consisted of managers negotiating with the owners of those tasks appearing to have excessive buffer. After several weeks of negotiations, they all agreed that a 58-day plan was doable and the detailed plan was updated with the changed task durations.

The Kickoff

With the plans defined and reconciled, and a firm CSBC/O date looming ahead in late August, it was time to begin the tracking and reporting process. We held a project kickoff meeting Wednesday, August 3. All participating organizetions were represented. John Stone kicked the meeting off by restating his goals and his commitment to the project management process. He told the organization that they were to do whatever I told them. Thispublic statement of support for the PA function is a key requirement for its success.

The Gantt chart project plans that had been built over the last three months were distributed in hard copy and projected on the screen. At that time, the project contained 1,845 tasks in 27 plans owned by 19 first-line management organizations. The tracking and reporting process to control the project was described. A meeting schedule was established for the weekly Somers Project Status Meeting. Rules dealing with lateness and slippage were discussed. No change in the schedule would be made unless the levels of management whose milestone dates would be affected agreed to the change.

Ongoing Plan Building

Following the CSB fitup phase, each office building required a fitup and move plan, and each computer system required a relocation plan. Because specific building C/O and CPU relocation dates were uncertain until only a few weeks before they were to happen, plans would continuously be built and refined as needed.

PROJECT EXECUTION CYCLE

The weekly project execution cycle provided a closed-loop feedback mechanism through which the project managers and participants are able to adjust their activities to maintain the planned schedule. The loop consisted of

• The plan contacts report prior week's progress against their plans;
• The PA publishes status meeting minutes containing project status reports, reasons for lateness, and project health assessment;
• The participants and their managers execute the planned activities during the week, making adjustments based upon the reports; and
• The plan contacts report progress against their plans again.

The REP File

The REP (short for REPort) file is the turnaround document used by the plan contact to report progress against his plan back to the PA. When a plan is committed to, a REP file is produced from the list of tasks in the Gantt plan and sent to each plan contact via the IBM VM time sharing network. This is a communication network that connects all computer systems throughout IBM. All IBM professional employees have access to this facility and can send messages and files to each other anywhere in the world. Figure 5v shows the REP file that the plan contact would receive for the sample plan that was built in Figures 5a through 5u. Figures 6a through 6c show the instructions plan contacts used as a reference if they had questions while filling out the REP file and the PA was not available to assist. The example in the instructions is from a live plan shown after four weeks of reporting progress.

The REP file in Figure 5V is made from the three left-most columns of the Gantt in Figure 5s followed by a Reporting Week column and a Percent Complete/Date Complete column. Note the letters in the Reporting Week column of Figure 6b. Letters are used instead of week ending dates because they reduce the typing required to fill out the REP form and they allow reports with a single print position to represent the reporting week. Examples of such reports appear later in this article and will make the advantage of letter week IDs clear. After 26 weeks of plan execution using “a” through “z,” the reporting week becomes “a” again. Thus each full year of project execution takes two cycles through the alphabet. The 62-week Somers Project went two-and-one-half times through the alphabet.

The Reporting Week ID identifies what is being reported for the most recent week. In the Figure 6b example, week “d is recognizable as the current reporting week because it is the highest letter. Each week that his plan is active, the plan contact edits his REP file and sends a copy back to the PA, keeping the original. This takes him no more than ten minutes and requires no special training. The PA only uses the information on the lines with the current week ID. All other information is from prior weeks and is ignored.

The plan contact may update the same task over several weeks. Each week, the plan contact changes the week ID of each active task to the current week ID and overtypes the percent complete figure with the new data. When a task is 100 percent complete, the date completed is entered instead of the percent. When a plan is completed, the REP file provides an audit trail of the completion dates of every task in the plan. Note that the Percent Complete/Date Complete column may also be used for comments and instructions. Many minor changes can be made to the plan using the REP file without the contact having to visit if the changes do not affect milestone dates or anyone else's clan. Figure 6b has several examplesof such changes.

Reminders to Report Status

The weekly reporting period for the Somers Project ended on Sunday. This is because the most significant milestones were completed over weekends. REP files were due by noon Monday. Sunday night reminder notices would be generated and sent via the VM network to all project managers and participants highlighting the plan contacts and managers of all plans that were active last week and should be sending REP files by Monday noon. There were usually a few stragglers. One plan contact never got comfortable with the REP file and preferred to give his updates over the phone. We were accommodating.

By early Monday afternoon a second reminder was sent showing those who had sent their REPs and highlighting those that still were outstanding. Figure 7 is a copy of the second reminder notice for week “h showing that four REPs are still not in. “X” in the REP column mark the received REPs, the “-”s are REPs that have not yet been received. The “LT” column uses the alphabetic (single-print position) week ID to indicate which plans were active last week and which plans are active this week. The “SEQ NO.” column contains either the plan's sequence number assigned in the order that plans were built for the project, or the subproject identifier. The sequence number for a parent plan containing subprojects has a “/” followed by the number of subprojects in the parent plan. For example, the OB4 plan is sequence number 42 with seven subprojects. Four of the seven subprojects were active last week and/or this week and appear on this report. The MANAGER and CONTACT columns identify plan ownership. The heading of the report says seventeen plans should be represented at this week's status meeting. The SHOULD ATTEND column has sixteen plans flagged. This is because one of the MANAGER/CONTACT owners (Woodyard/Martinez) will be representing two plans.

Updating the PM Tool Plans

By Monday at 5 p.m. all progress for the previous week ending Sunday night was received. The PM tool was cranked up and the plans updated. The PC is used as both a PC and a terminal. The PC's terminal emulator allows the PA to jump between terminal and PC modes at the push of a button, making it convenient to transcribe tracking information from the REPs to the PM plans. Manual transcription is necessary in order for the PA to ensure that the REP data is valid and to interpret any status information that may be unclear.

Task Status

We did not know how much work had been done since the start of the project because work had begun years before. And we did not know how much work remained because negotiations were continuously under way to regionalize additional systems. Therefore, we could not report on the percent complete of the project. We decided instead to develop a “now oriented measurement system that would focus participants on what needed to be done today to stay on schedule. Some examples will illustrate how this worked.

Figure 8a shows two tasks, Task 1 and Task 2, at the top of the page. Task 1 is of ten days duration and also ten person-days of work effort. So, on each day of duration one person-day of work effort should take place. Task 2 depends on Task 1 and is two days of duration and two person-days of effort. The Gantt calendar shows a five-day week with Friday the 13th as the end of the reporting period denoted by the vertical line, and Monday the 16th is the beginning of the following week. Equal signs are the PM tool's representation of the completed portion of a task. Dashes are the open portion. One can see that after five days of execution Task 1 should be 50 percent complete by the end of the reporting period, with five days of equal signs up to the reporting line, and five days of dashes following to indicate the amount of work remaining.

The bottom of Figure 8a reflects the plan contact's report that after five days of execution, as of the reporting date, Task 1 is only 30 percent complete. The completed portion of the task is shown by equal signs and the remaining open portion is dashes. The PM tool, when told that the task is 30 percent complete after five days of effort, was able to calculate the new projected completion date for the task based on this information. The “v” indicates the originally planned completion date for the task. Note that the PM tool calculated a new completion date for the task of the 27th, a week later than originally planned, and pushed the dependent task out one week.

The adjustment in Task 1 can ripple through the entire project schedule, depending on the degree of dependence on Task 1. Seeing their tasks shifted as a result of this delay resets everyone's expectations and they now strive for later target dates. It was decided that recalculating the schedule based upon reported task lateness would jeopardize schedule control. The Project Administration methodology instead uses a lateness concept. The bottom of Figure 8b illustrates how this works.

Figure 7.

When Task 1 is reported as 30 percent complete, three equal signs represent the three days of work that have been completed. One can see that the two remaining dashes to the reporting date line represent two person-days of effort that should have been completed by report time but were not. Thus the task is two person-days behind. Also, since the uncompleted portion of the task should have been started two days ago, the task is two days late. The “2/2” to the right of the task is the task's status. Note that the task has not been projected to complete later than originally planned. The Project Administration philosophy says the owner of that task is expected to do what is necessary to keep the project on schedule. Only when all managers whose milestones would be affected agree to a slip is a change in schedule allowed.

Figure 8c provides some examples to illustrate the need for both person-days behind and days late to denote task status. All the tasks in this illustration are two person-day tasks with a duration of four days, so each day of duration represents one-half a person-day of work effort. On the first version of Task 1, since no progress has been reported as of the reporting date (no equal signs), the task is two person-days behind. Counting back to the beginning of the uncompleted protion of the task, which is the beginning of the task in this example, it is fourteen days late. The second Task 1 is the same task but now it is scheduled to start a week later. It is also two person-days behind, but only nine days late.

Figure 8c.

Task 2 is 50 percent complete. Thus one person-day of work remains and it is one person-day behind. Counting back to the uncompleted portion, it is ten days late. Task 3 is complete and its status, therefore, is zero person-days behind since there is no work remaining to be done, and zero days late since there is no uncompleted portion to count back to. Note that it doesn't matter when the task is done, once it is done its status is 0/0. Task 4 is supposed to be 50 percent complete at reporting time and it is. Therefore it is on schedule and its status is 0/0. If it were ahead of schedule the equal signs would go past the reporting date line and it would still be 0/0.

Status for a group of tasks can be added together to produce summary reports for a subproject part of a plan, an entire plan, or the entire project status for the week. And status can be applied to task owners and rolled up through the management chain to report on how much lateness is owned by any level of management. We will see examples of this type of reporting later on.

The status calculation just described is not a feature of any PM tool of which I am aware. It was developed for the Project Administration methodology in order to focus participants on what needs to be fixed each week and how much work is involved.

The Gantt Reports

Tasks’ status values were only shown on a Gantt report if a task had progress reported against it that week or if it was behind. Tasks without status values were either completed in a prior week or are scheduled for sometime in the future and no progress was reported against them.

Figures 9a through 9d represent a plan from the Somers Project week “g,” week ending March 19, status report. It is the system relocation plan for the WPLIC1 computer system (IC1 for short) which will be moved to Somers the weekend of April 2 and 3.

The vertical line just to the left of the March 20 date represents the end of reporting week “g,” Sunday March 19. The week ID letters appear just above the calendar dates. Note the names of the participating organizations’ subprojects, HARDWARE PLANNING, OPERATIONS, etc. The numbers to the right of some of the tasks are the status values of those tasks. On the first page of the report you will see some 0/0 status figures for tasks in the VM SOFTWARE plan. Notice that there are hand-written notes, providing additional information of which the reader should be aware, like which subprojects are already closed.

On the second page of IC1, Figure 9b, you see the VM SOFTWARE status total of 0/0 circled. And just below, the INFORES subproject with no status reminds the reader that this subproject is active this week and will be expected to have status reported next week. The Gantt is a very powerful reporting medium for project management because so much information can be displayed in such a small space. Notice the CUSTOMER SERVICE END USER SUPPORT subproject has some lateness. The first two tasks circled are one person-day tasks and, even though there are no equal signs to show partial completion, you can tell they are 10 percent and 30 percent complete because they are .9 and .7 person-days behind. And you can see that they are almost fifteen days late as well. The third late task is five person-days behind and five days late so the total status for this subproject is 6.6 person-days behind and 34.6 days late.

Interior of one of the buildings in the IBM Sommers Office Complex

Continuing to page 4 of the plan, Figure 9d, is the total “Project status for week “g” = “6.6/34.6” for this plan. Below the status total is the resource summary indicating how hard people are expected to be working each week of this plan. Plan contacts used the resource balancing capability in a variety of ways. No attempt was made to impose a standard. Most used people's names, some used organization names, and some used generic names like“VM Swr Person.”

Figure 10

Summary Reports – Project Status by Plan

Status information was transferred from the Gantts to a spread sheet program which produced all the summary reports. Figure 10 is the Status Summary by Plan Report for the same week as the IC1 Gantt. The report shows plan status for weeks “e,” “f,” and “g.” The current week ending March 19 is week “g.”

The left two columns contain the plan sequence number and the plan names as described above in the reminder notice. WPLIC1 is plan sequence number 39 and contains twelve subprojects. The top line of the WPLIC1 plan section is the status total line for the plan, the sum of the subproject status totals. Notice only nine of the twelve subprojects have been active over the last three weeks. The “*”syndicate subprojects that have not yet become active. The “C”s indicate subprojects that are complete and closed. You can seethe IC1 CS status of 6.6/34.6 from the IC1 plan we looked at, and the WPLIC1 total status of the same value. The project status totals for the week at the bottom of the “Week g Mar 19” column are 14.88 person-days behind and 506.8 days late.

The right-most column contains the percent of the total project status that each plan and subproject contributes. For example, WPLICl'S 6.6 person-days behind is 44.4percent of the total 14.88 person-days behind. Its 34.6 days late is 6.8 percent of the 506.8 days late total. So, by glancing down the PERCENT column, the reader can very quickly determine which plan is making the greatest contribution to lateness this week. And it happens to be WPLIC1, with CHQVM just behind it.

Summary Reports – Project Status by Organization

This report, Figure 11a, was the most compelling to management and probably the greatest contributor to schedule control. It shows the organization hierarchy for the part of Regional HQI/S that participated in the project, up to and including the director, and it allocates this week's 14.88 person-days behind and 506.8 days late to the managers responsible. As you can see, Daddona is the director (he replaced Stone) and he owns all eleven active plans and all 14.88person-days behind and 506.8 days late, or 100 percent of this week's lateness. He has three third-line managers under him(Green, Kublano, and Divers). Green's organization owns eight of the eleven plans and 55percent of the person-days behind, and Divers owns two of the plans and 45 percent. when this report comes out, Daddona will be calling Green to ask some questions.

Green can see from this report that Dath, Southworth, and Tartaglia (his second-lines) all have active plans. Dath owns the biggest piece, 40.9 percent, of Green's 55 percent, so Green will be calling Dath first to get the story. Dath has first-lines Curren, Phung, and Kersten. He can see that Phung owns the whole 40.9 percent, so he will be questioning Phung, etc.

Figure 11b is the first page of a seven-page report (the rest is not shown) that tells each manager which of his plans are active this week and account for his numbers on the STATUS BYORGANIZATION report. The first list is Daddona's with all eleven active plans. Then Green with his eight plans. Green can see that OPERATIONS and the CHQHWP subproject are responsible for his entire late status. Below Green, Dath can see his five plans and the CHQHWP subproject that makes up his entire lateness.

Figure 11a.

Figure 11b.

The reader should be able to see that, if he owned lateness on the ICI plan, his list of plans would point him directly to the IC1 Gantt where he can quickly see which tasks are in trouble. The intent was to make it so easy for everyone to see who owned the lateness and where it came from that managers would have no choice but to respond.

Figure 12.

Project Status – Trend Graph

Figure 12 shows the status trend from the start of the project, August 5, 1988, through March 19, 1989, i.e., week “g,” the reporting date used in this example. The top line is days late and the bottom line is person-days behind. The vertical axis goes up to 1,100 because, in the early days of the project, before the reporting system was stabilized, erroneous data drove week “d's” days late almost to 1,100. As you can see, person-days behind was for the most part under control.

The numbers do illustrate a philosophical point about the limitations of numeric status reporting. When the numbers are small, which in the PA methodology is good, you can be assured your project is pretty much under control. But when the numbers are large you cannot be sure things are bad. You need to know if the late tasks are critical or inconsequential to making your key dates. The 506.8 days late in the example we are examining are from non-critical tasks in two plans. Without some kind of commentary on the meaning of the status figures, the reader does not know how concerned to be. The 111.1 days late in the OPERATIONS plan, for example, are tasks to label output bins. If the bins are not labelled, the project will not fail. Yet, until they get done, the numbering system will reremind us each week that they are open, and those tasks will get five days later each week. They could be taken off the plan and not affect the outcome, but the plan contact does not want management to forget that they need to be done.

Status Meeting

Plan contacts would report progress by Monday afternoon. By Monday night all the Gantts would be printed. Tuesday morning the summary reports and trend graph were produced. Early Tuesday afternoon the plan package was assembled and reproduced for the meeting. And Tuesday late afternoon the status meeting took place. At that meeting the plan package was distributed and reviewed. The package consisted of the Trend Graph, the Status by Plan, the Status by Organization, and the Gantts. Plan contacts explained their lateness and corrective actions.

The Status Meeting Minutes

The minutes are the commentary that needs to accompany the status numbers so managers can respond appropriately. Tuesday night was spent writing the minutes. The target was to have the minutes in everyone's electronic mail box first thing Wednesday morning. Figures 13a through 13h are the minutes for the week we have been examining, i.e., week “g” ending March 19. The sections the reader should take note of are numbered 1 through 9 in Figure 13 and listed below:

1. Assessment of the Status Report is a single paragraph summarizing for the director and his third-lines the health of the project and what to be concerned about.

2. Interpretation of Status is a reminder to the reader that plans are a focal point for information about lateness, not a measure of incompetence. Throughout the life of the Somers Project no organization's plan was ever late because they messed up. Usually delay of some external deliverable caused them to start a task late. Thus management is cautioned to always read the minutes before responding to lateness. We called this concept “No Fault Project Management.”

3. Status by Plan

4. Status by Organization

5. Key Dates

6. Plan Review Discussion is the section managers need to read before responding to the status report. It describes why each plan was late and corrective actions to be taken. Here you may read about why OPERATIONS, IC1CS, and CHQHWP were late that week.

7. Plan Representation is a table with codes in the REP column indicating which plans should have been represented at the status meeting but were not, and which plans were represented. The format is similar to the reminder notices and uses the letter week IDs to show which plans are active last week, this week, and next week.

8. Status Meeting Attendance is a table of managers, plan contacts, and interested individuals associated with the project. The “ * ”s indicate who was present at the status meeting. Attendance was already down to six at this late stage of the project. The ideal management process should require no meetings at all.

9. What's Next

Figure 13a.

Plan Package Mailing

Participants and managers who were unable to attend the status meeting received a copy of the plan package in the-mail. The package was mailed immediately following the status meeting to all managers and participants that did not attend the meeting. The minutes were not included in the package because they were not ready until the next morning. Minutes were delivered only by electronic mail.

PROJINFO

This is an online network facility that provided all the reports contained in the plan package except the trend graph. It could be accessed from any terminal. The data was available Tuesday afternoon immediately before the status meeting. And the minutes were added to it Tuesday night. Anyone who could not attend the status meeting still had access to all the information by the time of the meeting.

PROJINFO also contained general information such as the status meeting schedule and room locations, instructions for filling out the REP form, a description of how to read the Gantt reports, and instructions on how to use PROJINFO.

The Remainder of the Week

The rest of the week was used for building new plans as dates firmed for buildings and system moves. And it was used to refine the Project Administration process.

Sunday Night

The cycle repeats, starting with the first electronic mail reminder notice to the owners of plans that were active last week to report status via REP file by Monday noon. The reminder was in everyone's electronic mail first thing Monday morning.

SUMMARY

I have seen many project management efforts get sidetracked by the quest for the right tool. It cannot be emphasized strongly enough that the success of a project has little to do with tools. Project management requires a process control system. The Project Administrator provides that system. After initial planning, the whole PA job consists of measuring progress, feeding back the measurements in a manner which causes appropriate adjustments based on that feedback, and measuring again. Success depends upon the ability of the project team to understand the feedback, and the motivation of the project team to respond to the feedback with the appropriate adjustments.

The burden that administrative responsibilities place on the project team distracts it from the task at hand. The PA provides a service whose objective is to lighten this burden as much as possible. The Project Administration methodology described in this article provides planning assistance and feedback that is not only easy for the team to understand, but also compelling. A committed executive sponsor provides the motivation for the team to respond.

It is hoped that readers find these concepts of use and are able to adapt them to their own environment.

Good luck!

Ed Mahler joined IBM in 1969 as a systems engineer in a New York City sales branch office where he handled large and intermediate accounts in process and distribution industries for 14 years. As lead systems engineer on national and international accounts he provided a broad range of technical and project management assistance to customers.

Ed joined the I/S Branch Office in Harrison in 1983 as a branch technical specialist supporting internal sites. In 1987, he was the system architect on a large internal application development project. In April 1988, he joined the Regional Headquarters I/S Relocation Planning department in White Plains where he developed the Project Administration Methodology to manage the Sommers project.

Ed is now the Project Management Coordinator for IBM's Regional HQ Programming Services organization.