Publications

Project Management: A Case Study
By G. Carl Pack, Jr.

        Effective project management is the key to a successful project! Most people believe it, and yet, in projects that fail, whether it be in industry, government or business, you find that the correct qualities were not addressed when a Project Manager or leader was selected.

        A person may be recognized as a "great person", as a "nice person", or has done a "great job", but that doesn't make him or her equipped to manage a large project. This is due to the many factors which are commonplace on large projects and which are not formally addressed in the course of managing company activities.

        The chosen Project Manager should be given full authority and responsibility to manage the project. Usually on failed projects this authority and responsibility is split among several people and instead of a single source of direction and guidance, it falls to a committee. Good work rarely survives a committee. In a committee situation the direction and decisions have a tendency to change because of pressures from some members who are "part-timers", and have s special individual interest, or are probably just the wrong people to be involved. In addition, the pressures and politics of the company tend to influence some members' decisions, since they are unable to rise above them.

        The person selected should make decisions based on real factors, i.e., issues, scope, requirements, tasks, deliverables, target dates, dayto-day problems, budgets, workload and the people actually working on the project. It is important to be able to make project decisions without the pressure of company operations, and the "internal politics" of the company and its people.

        Once a person is identified, he or she cannot be successful with just having full authority and responsibility to manage the project. This person must have other skills and traits, such as:

        • General knowledge of the overall project scope
        • Ability to see the "big picture" quickly on issues, situations, impacts on
          decisions and staffing problems.
        • Ability to motivate staff
        • Ability to resolve issues/problems quickly
        • Ability to recognize issues/problems before they occur or cause damage
           to the project
        • Ability to organize
        • Ability to select qualified staff
        • Ability to function as a team player
        • Ability to get above office/company politics
        • Ability to communicate: up to management and down to staff
        • Ability t keep project on course and to accomplish goals and objectives
        • Have experience in the functions and industry relating to the project

        After the right person is selected to direct the project, it is necessary that the tools be in place to control the project. There should be different levels of control for all those involved. The top management (usually a Steering Committee) authorizing the project wants to be periodically assured that satisfactory progress is being made and the project is on time and on budget. This level of management wants to be able to quickly identify the problems, should there be any. They do not have extensive time to spend on project reviews and must have the confidence that the project status information they are getting is both realistic and on target.

        Another level of project control is for the Project Manager. This person needs to be able to know the status of the project in order to report truthfully to upper levels of management and to manage the staff reporting to him.

        On very large projects, the scope of tasks to be accomplished are assigned to separate groups or functional teams, usually led by a Project Leader. The Project Leader also needs a level of control in order to report the progress status upwards to management, but also have close control over the staff that reports to him/her. These are the people who are actually leading the individual tasks and delivering the actual work effort.

        What about the people doing the actual tasks and delivering the work? They need to know what is expected of them to effectively accomplish what is assigned. This presents a need for another level of control.

        Through all of this, it should never be forgotten that the goal of the project it to get something accomplished. The activity of controlling the project, at all levels, cannot impede that goal. On some projects, more effort is spent on controlling the project that on doing the project. The Project Manager cannot allow this to happen. The controls must compliment the work effort in order that the documents produced are really "working paper" and not "paperwork".

        One of the secrets in managing large engagements is to "divide and conquer". In our firm we use this philosophy and utilize control techniques which specifically address the "Use Factor". That is to say, how am I using this control and what do I want from it? We use only those controls which are meaningful and help to result in a successful project. Control techniques can also build the confidence of the sponsor, steering committee and/or top management. When a project is perceived as successful by upper management, it contributes significantly to the project's success, the project team's success and enhances their ability to accomplish the project successfully.

        It was noted in a recent newspaper article that "Leadership is 70 percent a matter of Symbolism, Credibility and Legitimacy". Proper controls can contribute to this image.

        In order to show how various controls can be used in the completion of a successful project, I will present a case history of a very large project and the controls used to complete this very successful project. This project had sever time constraints place on it which allowed for no slippage. The project scope addressed all financial and operating issues of the organization for which the work was performed.

        The levels of control used to monitor this particular project consisted of the following:

        • Formal Project Control Systems Flow • Formal Policies and Standards
• Formal Policies and Standards
• Project Scope Change Procedure
        • PC Based Project Scheduling Systems (Computerized)
        • Detail Punch List Systems (Computerized)
        • Review and Approval Checkpoints

        The project control systems flow of the project, shown below, is pictorial presentation of the process used to control the project. It reflects the timing and involvement of the project participants and indicates the roles the various participants played in relation to each other.

        On this project, the person appointed as Project Director and made responsible, was one of our firms Consulting Managers. He was appointed by the client. He worked very closely, on a daily basis, with the client project manager. During the early stages of the project they met daily to resolve start-up issues and administrative problems. As the project progressed, formal meetings were preset for Tuesday and Thursday afternoons. At these meetings the project progress was discussed along with issues of scope, manpower and interaction between project teams and project users. The client project manager was responsible for all the client users who participated in the project. Their responsibilities were to report independently to the client Project Manager who elevated their concerns to the Project Director.

        The involvement at these meetings was such that the issues, concerns and problems of the project were usually resolved by these two individuals. When there was agreement, regardless of whose opinion was accepted, the two individuals spoke as one. The solid common front prevented order from becoming chaos. When issues could not be resolved, the problem was elevated to the Project Steering Committee for resolution.

        The role of the Project Steering Committee, as shown on the chart, was one of project review. The Steering Committee consisted of Five representatives from the client company and three representatives from the consulting firm. The client committee consisted of the Chairman and CEO, who also served a the Steering Committee chairman; the company President and COO; the Controller and CFO, who served as the client Project Manager; and two Vice Presidents from the operations side of the business.

        Representing the consulting firm were the client partner, the engagement partner and the project director.

        The schedule for the Steering Committee was initially set for semi-monthly meetings. However, as substantial progress was made and the confidence increased, the meetings were scheduled in the every three to four week range. All requests for changes in scope had to be prepared formally, discussed with the client project manager and submitted with a cost impact study to the Steering Committee Chairman. He would, if appropriate, discuss the requested changes at the Steering Committee meetings to determine if the changes should be approved and made part of the project.

        After approving the formal policies and procedures, the Steering Committee directed its energies to controlling the project to assure complete compliance with the agreed scope and meeting the critical completion date.

        Through use of the project deliverable documents and the detailed task information from the approved computerized project scheduling system, it was recommended and agreed to monitor the project with a combination of tasks in relationship to the due dates. In addition, it was agreed to use an updated summary project Gantt chart to reflect the current status. The Project Director would also present a brief written report to each project team's status.

        To help, farther, understand the control techniques for this highly successful engagement, the chart above reflects specifically how the project was controlled for one team. The line items in the computerized project scheduling systems amounted to 101 tasks. Each task in the scheduling system had previously been prioritized as to sequence to complete, had been identified as to who would perform the tasks, who would participate in performing each task, when the task was scheduled to start , the number of hours assigned to perform the task and when the task should be completed. The tasks within this project were then combined into a number of common activities which were referred to as phases, which numbered twenty (20). The following chart reflects the listing of the phases for this project schedule and also indicates the number of tasks within each phase.

        For additional control, the phases were combined into groups (4) which reflected major categories of this effort.

        It was agreed to monitor the tasks m relation to the due dates m order to give the committee comfort that the project was indeed on schedule. The next chart reflects a sample of the Steering Committee report which was presented and discussed at each Steering Committee meeting.

        With the controls to management in place it was necessary to develop the tools to control the project team staff. The 101 tasks were broken down further by the each individual project leader to add additional tasks that were deemed appropriate or to define sub-events in each task in order to have better control over the work to be accomplished and to communicate more specific activities to project team members. There were 800 of these Punch List activities in this effort. The next chart reflects a report from the automated Punch List System which was used to control the Punch List activities. Each punch list activity had to be tied to a scheduled task number from the automated project scheduling system. All punch items has to be completed before that task could be considered completed. The Punch List System also produced reports that were team member specific to reflect the schedule of effort required of each team member or client user. The team staff worked to the Punch List schedule. The schedules were reviewed and updated weekly by the project team leaders as required. Minimal amounts of time were spent on the paper work related to this effort since the goal was to get the project effort completed efficiently and effectively. The lists were discussed as needed, with team staff, to assure coordination of work effort, expectations, deliverables and completion dates.

        The methods for updating the current status of the systems could not and did not consume great amounts of time and analysis. On this project, each project team member was required to enter a "C" on a copy of the Punch List report when a task was completed. This copy was specifically produced to obtain the completion input information. It left the original copy of the list always in the staff member's possession so as not to delay any work effort and to afford a document on which notations could be entered for their own current and future use.

        Updates on all systems occurred as reflected on the Systems Flow Chart.

        This project was completed within budget and ahead of schedule. It happened because the proper level of control was in place to "make it happen" along with the knowledgeable and competent staff assembled by the consulting firm form its worldwide resources.

This project was another example of bringing consulting strength to the needs of the client to effect a successful solution.