Managing the colossal project
how a major financial institution was able to successfully design and implement a master program office and enterprisewide project management information system (PMIS)
Howard M. Plevyak Jr., IBM Global Services
James E. Pierce, Bank One Corp.
The objective of this paper is to present a case study of how one major financial institution was able to successfully tackle the complex problem of managing a colossal project using a project office approach and enabling project management information system (PMIS).
Throughout a career in project management, the project manager (PM) will continually be looking for, and often inventing due to necessity, “tools” that are stored away at the end of each project for reuse. This paper will discuss the project office approach used and associated toolkit developed to successfully manage a colossal Year 2000 program. Although Year 2000 is behind us now, there are definite applications of these tools for all projects.
Typically the size and magnitude of a project dictate the level of project management process and rigor that must be established to control the effort. Trying to manage over 75 simultaneous projects encompassing scope with over 1,000 applications (i.e., 105 million lines of code), 13 mainframes, 400 minicomputers, 65,000 PCs, and over 10,000 pieces of network equipment, required a level of discipline and control that warranted the project office approach. In this case, the project office approach was implemented via the “Master Program Office” (MPO). The MPO provided the infrastructure of project management processes, enabling tools, mentoring and training, and administrative services to those implementing the massive corporate, and multi line of business initiative. The MPO monitored the PMs for adherence to standards through regular reviews, tracked their progress, and created executive management status reporting from the data supplied by the PMs to aid executive decision making.
Note that the PMs did not directly report to the MPO, but were assigned to their respective lines-of-business / corporate organization. A dotted line reporting relationship existed between business-staffed project managers and the MPO for performance and reporting. PMs were accountable to report progress to the MPO and manage their projects according to the standards established by the MPO. This approach is described in the “Repository-Coach” model (Miller, 1998). Under this model, the project office shares project management best practices and tools across business functions and uses the project office to coordinate project communication and actively monitor project performance. The project office is a permanent organization with staff and has supervisory responsibility for all projects.
The MPO concept was new to the organization, as was any kind of project management or project related standard. Although some lines of business had previously had some experience with reporting to a multi-line-of-business project group, the majority of the institution managed projects in a silo and with little project management discipline.
For the Year 2000 Program, approximately 75 projects and associated reporting groups were actively working through the major lines of business, and corporate organizations. Most teams were geographically separated which made it even more of a challenge to communications. To overcome this challenge, Lotus Notes was chosen as the key communication enabler and formed the cornerstone of the MPO’s project management information system. A general knowledge of Lotus Notes is assumed and will not be discussed in detail here.
Implementing structured project management and the MPO concept to an environment of project management adverse bankers was not without its challenges. However, like many initial project offices, it begins with exceptionally strong leadership and full cooperation of executive management. In this particular case, executive leadership was extremely strong which allowed the MPO to succeed.
A key enabler to the acceptance of the MPO was the usability of the project tools that made up the Project Management Information System (PMIS). The PMIS was used to track and maintain control over the company’s portfolio of Year 2000 projects. A Lotus Notes database, dashboard-type control panel, along with electronic mail, served as the “user front end” to allow navigation through the various project management data collection and control applications as follows:
Exhibit 1. Here is a sample of what the Project Management Information System (PMIS) contained …
•Scope management (e.g., the project charter)
•Milestones (planning integration and scheduling management with milestones)
•Change management and the change control board
•Project risk and quality management (i.e., project audit and reviews)
•Defect or “bug” management
•Executive and project status reporting
•Weekly reporting cycles
•Training and education
Project Management Information System (PMIS)
The PMIS is a Lotus Notes based set of applications accessed through a dashboard-type control panel shown in Exhibit 1, and was used by the entire project team, from the lowest level team member to senior management.
The dashboard control panel is a menu of various applications that works as a portal to launch the project management applications. It was also designed to house a bulletin board used to send general announcements to the project team.
Key to the PMIS success was designing a user-friendly interface and implementation of an enterprise-level infrastructure that supported the PMIS applications and the geographically separated teams. This is not to be taken lightly, as failure to understand both the MPO and the “field” project managers’ needs early on, will inhibit user acceptance, create tool frustration, and cause inaccuracies in progress reporting. Lotus Notes allows replication of the PMIS database to a laptop, which then allows working in a disconnected “off-line” mode. This set-up allowed team members to hold working sessions off-line and then replicate “on-line” to share their work products and efforts (e.g., plans, meeting minutes, email, issues, etc.) with the rest of the team and the MPO.
A project charter/scope document was required for each project/reporting group as well as the project at large. Once approved by the Executive Sponsor, user access was restricted to “read only.” Changes in scope were submitted to the Change Control Board for approval (see Change Management and the Change Control Board below). Once approved, MPO personnel made necessary changes to scope documents and a new baseline was then established based upon the accepted change.
Key Lesson -> It is the critical that the project team understand and agree that the PMIS project charter/scope document act as the only point of record for approved project scope. Some early teams, circumvented this process which created confusion amongst the Year 2000 Program regarding project objectives, scope, and responsibilities. The MPO tightened controls and placed more emphasis on this during PM training, which resolved the issue.
Milestones in the PMIS were not true milestones as classically defined as “a significant event in the project, usually completion of a major deliverable” (PMBOK® Guide, 1996). Milestones for our purpose were more like activities (i.e., Phase, Activity, Task, etc.) in that they had a start/finish date and represented multiple tasks related to accomplishing a significant effort or major “activity.” The start date was the beginning of the first related task, and the finish date was the end of the last related task for the activity. This activity represented a significant level of work, which warranted tracking by the MPO. Since the company was not familiar with project management, increased detail at the MPO level was required to ensure the Year 2000 Program remained on track. The MPO could not possibly manage individual tasks on every project plan (75+) for each reporting group. Nor would this have been of value or practical. A tradeoff and balanced decision was made by the MPO to manage at the activity level (i.e., verses true milestone) due to the exposure and risk to the company that would result if the Year 2000 effort did not complete successfully. In addition, each reporting group had their own PM that monitored progress at a detailed task level.
Each reporting group determined the appropriate milestones for their area of responsibility. Some reporting areas that were more structured with their project management pulled these “milestones” directly from their detailed project plans. Other nonproject management savvy reporting groups created their “milestones” based on known deliverables and activities.
Once milestones were identified, they had to be approved through the Change Control Board and loaded in the PMIS Milestone database. As progress was made toward the completion of a “milestone,” the milestone record in the milestone database was adjusted appropriately by each reporting group.
Note: In our example, percentage complete was used to show progress; however, any means to show progress could be used (e.g., completed hours/total hours, etc.).
Changes, additions, and deletions to a reporting group’s milestones required approval from the Change Control Board. Edit rights to make these changes were limited to the MPO staff only.
Multiple views were created in the milestone database to benefit various users of the information.
The MPO relied on the PMIS milestone database exclusively to track each group’s progress. Milestone metrics were used to track individual team and Year 2000 Program aggregate progress. Progress summary and detail reports were produced and distributed regularly (biweekly) to the project managers and senior management. These reports were also used by the MPO to discuss project delays and cross impacts with the project managers.
Change Management and the Change Control Board
Controlling changes for anything that affects the project management “triple constraint” (i.e., cost, schedule, and performance/specifications of a project) is critical to success and maintaining control. This control was obtained by utilizing a Change Control application via the Lotus Notes database. Critical elements (e.g., triple constraints) in each application were restricted to read only. Only MPO personnel were authorized to make these changes and then only with the approval of the Change Control Board (CCB). The CCB acted as a committee of cross-representatives from all major reporting groups and the MPO.
Note: In many cases, one CCB member represented multiple reporting groups (i.e., one person from a line of business represented multiple reporting groups within that line of business).
The CCB convened weekly (some members via teleconference) to discuss each of the requested changes. Changes were logged and tracked in a Lotus Notes database. Prior to the weekly cutoff date, users would submit change requests via the Change Control Board database. In the weekly meeting, chaired by the manager of the MPO, each change was reviewed and discussed as to the nature and justification of the change. Each CCB member would consider impacts of the requested change on their area of responsibility. Conflicts were discussed, and a vote determined whether to accept, reject, or defer (i.e., more information needed) for each change request. If the change request representative or “champion” was not present at the CCB, the CCB would defer that item to the next meeting.
In the event of an urgent change, an Emergency CCB was convened to discuss, then approve or deny the particular change request. The MPO manager determined the need for these Emergency CCBs through quick project manager phone requests and discussion.
Once approved, changes were implemented into the proper Lotus Notes application by the MPO (this was largely automated to reduce duplicative data entry and errors).
The Change Control database not only provided a simplistic and controlled method for requesting changes, but also became a repository of historical changes that could be accessed for quick reference when disagreements occurred or memory failed a team member.
Two hours were allotted each week for this meeting, but the average actual time was less than one hour. Initial meetings were rocky, but after a few weeks, changes stabilized and the team became comfortable with the CCB process.
Project Risk and Quality Management
The MPO conducted weekly meetings with the project managers of high-risk projects to discuss general progress of deliverables. These meetings were also used to clarify information provided in the status reports (see Project Communications—Weekly Reporting Cycles section).
An internal Audit and Quality Assurance team was also a key contributor to maintaining diligent risk management and overall quality of project deliverables. QA and Audit both performed deliverables reviews to ensure quality was being maintained. QA/Audit review reports were posted to the MPO/PMIS General Library, and risks/issues were created for outstanding discrepancies discovered as a result of each review. QA, Audit and the MPO then tracked these risks/issues to closure.
The Issues database was a central location that housed each project team’s items of concern requiring resolution. An issue was defined as a “project impact that required action to minimize its effect upon the project’s cost, schedule, or performance/specifications (i.e., milestone or deliverable quality).” It provided all project team members a central repository and global view of all outstanding issues and the status of issue resolution. Issue status was tracked with the following scheme: (1) Open—no resolution; (2) Resolved—the accountable party has recommended a resolution that is awaiting the initiators approval; (3) Closed—resolution accepted.
Key Lesson -> Initially, only two status codes were used, open and closed. This was changed to include “resolved” after initial issues were discovered by the MPO not to be officially closed (i.e., accepted by the initiator).
Note: Tasks required to close an issue were captured and tracked in the individual project plans or Milestones database when warranted.
Once a new issue was created the Issues database would automatically send an email to the responsible party to alert them that a new issue had been created. In addition, an e-mail notification was sent when an issue’s status was changed, (i.e., resolved, closed, or reopened after a resolution was rejected). This e-mail notification system greatly expedited communications and gently reminded the issue owner to work it to closure. Reminders were also sent via email to the issue owner when status updates were not current. This helped the MPO keep the issue data fresh and up to date.
The timeliness and progress of issue resolution was determined by an issue color code: (1) Green—lack of resolution is not impacting project deliverables; (2) Yellow—need for final resolution is becoming important, but not urgent; (3) Red—immediate final resolution is critical.
Multiple views were created in the Issues database to benefit various users of the information. The Issues database was closely monitored by MPO staff to facilitate timely resolution of all issues. Issues metrics were also generated to track issue closure performance and were included in the executive status summary and project communications meetings.
Defect or “Bug” Management
With all IT projects, there is a certain amount of testing that takes place. A sister of the Issues database, the Incidents database allowed testers to document “bugs” and make comments to the application development team. For the application programmers and system engineers, it provided a means to document changes and communicate back to the tester that the defect had been eliminated.
An incident was coded with three potential statuses: (1) Open—no resolution has been made; (2) Resolved—resolution has been made and is ready for retesting; (3) Closed—resolution has been retested successfully.
The MPO monitored this database to assure timely resolution of incidents and to track the quality of software development.
Effective communication is a key success factor for every project. The MPO developed a communications program that included a weekly Quick Response Team (QRT) leadership meeting and Think Tank, various project team level meetings, executive and project level status reports, event calendar, and contact database and documentation library. Each was important in enabling effective team communications across the Year 2000 Program.
The QRT Meeting and the Think Tank—A QRT leadership meeting was held every Tuesday morning to review project status and major issues. This QRT meeting allowed the Year 2000 Program Director to provide high-level focus and marching orders for the week. QRT membership included the major leads of the Year 2000 organization. The actual meeting was held in the Year 2000 Program Think Tank or “war room.” The Think Tank room shown in Exhibit 2 was designed to provide a place for each project team to post their project schedule, issue summary charts, and deliverable status metrics. Each team had a 4x8 foot tall white board they used to post charts summarizing critical project information. The Year 2000 Program Director performed a whiteboard walk around the room, and obtained status from each of the major leads. This system was very effective in obtaining quick status and allowed cross team exchange of information on the Year 2000 Program’s overall status.
Executive and Project Status Reporting—Weekly status reports were required by each reporting group. A template was created in the Status Report database that preloaded specific metric information for each reporting group. The information was interpreted by the project manager who then provided a subjective status color (i.e., Green, Yellow, or Red) with narrative justifying the status and explaining the metrics.
The MPO would review each status report and create a consolidated report, offering a general overall project status with brief explanation and a detail of each reporting group’s individual status (i.e., Green, Yellow, or Red).
Information derived from the status reports and metrics provided the basis of the Executive Management Reports. The consolidated report and the Executive Management Report status summary presentations were filed in the PMIS for reference by the project team.
Key Lesson -> One key lesson was in the ability to adapt to constantly changing reporting groups (i.e., project organization breakdown structure). Large program efforts over a 2?-year effort will inevitably go through changes in the organization and company structure. This dramatically complicates the MPO’s ability to roll up, summarize, and report historic information accurately. Each time a change occurs, historic documents and data must be remapped to the new structure. The project office must take this into consideration when designing the PMIS to allow agility in meeting these organization changes successfully.
Event Calendars—The Event Calendar database provided a central point to capture special events (i.e., status report due dates, departmental meetings, project team meetings, observed holidays, etc.). In this database, users could find discrete information about a particular meeting (i.e., time, place, conference call number, etc.). It also assisted users in determining viability for meeting dates and potential conflicts with attendees.
Contact Management—This database provided typical contact information for project team members (i.e., phone numbers, fax numbers, mail codes, pager numbers, cell phone numbers, home phone numbers, etc.).
Documentation Libraries—Having a central location for project documentation is an asset to all project team members. The PMIS and its library applications served the team very well as an electronic project control book. The General Library housed administrative documentation (i.e., processes and procedures). The Project Documentation Library (PDL) housed individual project team’s proof of due diligence (e.g., project plans, design specifications, test plans, test results, etc.).
Documentation was categorized by reporting group and type of documents for easy retrieval.
Largely documentation was available electronically and therefore attached to PDL records. However, some information was only available on paper (i.e., test results). A numbering system generated a documentation number for each paper document saved. The actual document was put into binders adorning the documentation number and placed in file drawers for future reference.
Exhibit 2. The project war room or “Think Tank” proved itself as an effective means to communicate critical project metrics and enable management to make decisions.
Training and Education
Training and education were critical to the success of the MPO and the entire Year 2000 Program team. The MPO held project management and PMIS training classes for the entire team on a just-in-time/needed basis. After the high priority/risk project teams were cycled through the PM/PMIS course, brown bag lunch sessions were set up for the remainder of the Year 2000 Program team. This reinforced the PMIS, its use, and how best to apply its features to manage a project.
Key Lesson -> The value of training team members on a just-in-time/as-needed basis was very effective and efficient. Each team was given the training needed, as they needed it, to reach the next level of their project team’s work effort.
Project close is all too often a neglected phase of a project. For a Year 2000 effort, project close is critical to ensure all deliverables and project documentation is retained as proof of due diligence in repairing the Y2k bug. The Project Close database was used by the MPO to make sure all deliverables were completed and closed by each reporting group (i.e., milestones at 100%, issues/incidents closed, final project close status report complete, PDL documentation complete, etc.). It also served as a checklist as resources rolled off the project to track individual activities (e.g., PCs/laptops returned, pagers, cell phone, calling cards, corporate credit cards, etc.). This checklist system served the MPO extremely well in ensuring all loose ends were completely wrapped up.
Managing the colossal project is a challenge for even the most seasoned veteran project manager. However, with the proper leadership, executive support, and staff of qualified project managers in combination with the use of enterprise team collaboration software (i.e., Lotus Notes) and effective Project Management Information System (PMIS) tool kit, even the impossible can become possible. In designing and implementing your next project office and project management information system, keep in mind these key points.
•Start early in implementing your project office and keep it simple. You can always add later.
•Dedicating professional project management talent to the design and implementation early on increases your chances for success.
•Identification of program stakeholders and their information needs is critical. Focus the project office to meet this need first.
•Remain sensitive to the organizational culture and project management maturity level of the company. Design for just above it.
•Conduct a pilot in a supportive unit before rolling out the project office standards and procedures to the entire organization.
•Issue management and being proactive is against human nature. Reinforcement and perseverance by the project office is essential.
•Effective training will increase organizational culture acceptance by the non-PM crowd.
Best wishes on your next colossal project and successful project office implementation.
Miller, Jean. (1998). Project Office—One of the Fastest Growing Segments in Information Systems. Proceedings of the Annual Seminar/Symposium.
Project Management Institute Standards Committee. (1996). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Upper Darby, PA: Project Management Institute.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA