The evolution of project management has resulted in the development of many concepts, procedures and tools that have made project management more of a science and less of an art. But even with all of these advancements there are still several areas of project management that remain undeveloped and rely on the savvy of individual project managers to ensure that adequate attention is placed on every facet of a project.
This article is based on an effort to drastically improve the way project management was approached for the IBM RISC Systern/6000 Division. The result was a project management planning tool that has become known within IBM as RSPLAN. Most of the work that was done focused on managing the effort expended in the planning phase of a project. An equally important focus was to ensure that the entire project could be managed in a seamless environment that recognizes and addresses the interdependencies of scope, time, cost and quality through all the phases of a project. The RSPLAN also emphasizes the need to effectively manage communication and human resources.
The primary motivating factor behind developing RSPLAN was that, at the time, no commercial applications addressed the planning aspects of project management and provided a link to schedule management tools. The need for these links is illustrated in Figure 1, which shows where the effort of a typical project is expended. The graph is subdivided into the four PMBOK life cycle phases to show the relative effort expended in each one [1]. Seventy-five percent of the total effort for a project is applied during the implementation and termination phases. It is not surprising that this is also the time frame for which most project management processes and tools are developed.
Also shown in Figure 1 is the relative effort of scope, time, cost and quality as a function of time. Note that in the concept and planning phases the primary emphasis is on scope and cost, whereas in the implementation and termination phases, the primary emphasis shifts to time and quality. Since most project management processes and tools focus on the later phases, they are best suited to managing time in the form of scheduling.
This creates a perplexing problem for the project manager. Planning and implementation efforts are split and the interrelationships between scope, time, cost and quality cannot be managed effectively. This problem is multiplied in a large complex business where hundreds or thousands of projects are vying for a finite set of resources.
To address this problem, five primary objectives were identified for RSPLAN:
1. Centralize all project-related information and provide easy access to it.
2.Provide a control system that automates and enforces the project management process.
3. Provide an effective communication mechanism.
4. Effectively manage changes that occur in any phase of a project.
5. Provide a system that links all the tools that control project information, schedules, finances and quality.
Centralizing Project Information
The information defining the scope of a project comes from many different sources, often dispersed with no one point of control
Centralizing it and providing a common user interface greatly improves this situation. It is important to recognize that any system that tries to effectively manage scope needs to provide a flexibility for a diverse set of individuals to access and modify it.
An obvious way to address this is to store all the information in a single database. But that only satisfies part of the requirement. So for RSPLAN a user interface had to be provided that allowed the appropriate people to access the project information in a way that did not require extensive project management or database skills. The result was a graphical user interface that insulated users from the complicated details of a client/server distributed database. The diversity of the users also required that access be provided for mainframes, workstations and personal computers. This resulted in client applications being developed for MVS, AIX and OS/2 operating systems.
With this in place, the RISC System/6000 Division now had a tool that consolidated all the information for the projects of the entire organization. This provided the basis for an effective scope management system but it was by no means a complete system. What was needed was a way to control the overall project management process.
Process Flow Control System
Project management principles provide a good model for managing projects, but even if an entire organization vows to accept the model, it cannot guarantee that everyone in the organization will have the same interpretation of how the model should be implemented. For this reason it is important to have at least a repeatable process that identifies the steps that need to be followed and assigns responsibility at each step. However, even well-defined processes cannot ensure that they are followed, due to unfamiliarity or shortcutting to avoid process steps. Prior to the development of RSPLAN, there existed a formal process for introducing and approving new projects, but there was little control and in many cases the process was completely ignored.
Views of the project sizing function of RSPLAN. In the foreground is the screen for inputting the resource requirements, by month, for a project. The amounts entered can be either labor units or costs. At upper left is a query tool that totals labor resource allocations. This screen is used in conjunction with the sizing screen to perform resource leveling. Both screens were started from the screen at the bottom.
Figure 1. Project Management Elements as They Relate to Project Effort
This figure is a representation of the conceptual relationship between Scope, Cost, Time, and Quality. Because they are so interrelated, it would be very difficult to isolate the effort expended on each one, This is an attempt to show the transition in emphasis as a project moves from phase to phase.
In the Concept and Planning phases the emphasis is on Scope and Cost. During the Implementation phase the emphasis shifts to Time and Quality and remains that way through the Termination phase. Even though the emphasis changes, all four of these basic elements are variables throughout the project life cycle. It is important for these transitions to be managed effectively.
Figure 2. RSPLAN State Flow Model
The solution was to create a control system that managed the entry of project-related information and automated the approval process. This ensured that each step was followed for every project without being encumbering. Within RS-PLAN each step of the process is referred to as a “state.” When a project receives approval, the state is changed to reflect the next step in the process.
The RSPLAN state flow model is shown in Figure 2, along with its relationship to the four phases of the project life cycle. Note that there is not a one-to-one mapping of states to life cycle phases, but that the states and approvals reflect the activities that need to occur in each phase. Rather than basing the states within RSPLAN on project management names [2], the names of the states were influenced primarily by the terminology used within the RISC System/6000 Division for existing process models. This was a conscious decision to make the tool more acceptable when it was introduced. The sections below outline the functions of each state and describe the activities of the project life cycle that are performed.
Open. The open state defines the scope, objectives, areas of impact and time frame in enough detail that the project can be assessed to determine if it meets business needs. This state ensures that this information is documented for every project and forms the foundation on which to build the rest of the project.
Collecting this information consistently for every project can be a big challenge. Within RSPLAN the project initiator was required to complete a form that was specific to the type of project. In the case of software projects, it was necessary to identify items such as the intended test group, whether messages needed to be translated for shipment to other countries, the group responsible for service/support, and so on. This information was needed to clearly define the project's scope.
Most existing project management tools do not have the capability to collect and relate this much detailed information to a project. This causes the scope element to be split from time, cost and quality, which breaks the interrelationship of the variables that a project manager can adjust. The result is projects that are poorly communicated throughout the organization and unlikely to meet the objectives.
Approval is granted by a product area representative, based on how well the project meets overall product objectives. This is the transition from the concept phase to the planning phase in the project life cycle.
Candidate. This state determines which projects should receive funding and how much. The amount of available funding within an organization is generally limited and budgets are usually set to control spending.
Two pieces of information are required to make the funding decision. A cost estimate must to be performed to determine the amount of funding and the project must be prioritized relative to the other projects contending for the same budget. The cost estimate is expected to be a total estimate, completed with minimal effort by the organization. Taking this approach decreases the confidence factor in the estimate but the funding can be buffered with a contingency. The savings in effort at this time outweighs the need for exactness. As a guideline, the effort expended to determine funding should be a small percentage of the total.
Approval for projects in the candidate state is determined by the analysis of three factors:
• The schedule objectives must be con sidered and an initial risk assessment should be performed to determine if the objectives are realistic.
• The cost estimate (with contingency) should be compared with the funding available in the budget. The budget amount will be less any funding that has been applied to other projects.
• The project's relative priority should be used to make tradeoffs with previously funded items. If the budget has already been consumed and the project has a lower relative priority than other projects vying for the same budget, then it cannot be funded. If, on the other hand, the relative priority is higher than previously approved projects, then the remaining funding can be shifted to the new project. This means that a project already in implementation will have to be canceled. The expended effort on the canceled project is then wasted.
Once this approval is given, the organization is financially committed to the project. What remains to be determined is whether resources exist to do the work.
Working. The working state is primarily concerned with identifying and committing the resources required to implement a project. Departments within an organization that have a potential impact on a project must estimate their impact and determine if they have the resources and skills to take the project through implementation. This effort within the IBM AIX software organization is referred to as “sizing.”
Resources are not just human resources. They include anything that directly affects the cost of completing the project. Typical resources are:
• Labor (regular, supplemental employ ees and subcontractors)
• Cost (travel expenses or any other discrete dollar amounts)
• Material (equipment).
Once an impact is identified by a department and resources are committed, implementation can begin. In some cases this may occur prior to the project being formally approved to the next state. This flexibility allows departments with an immediate schedule deadline to start work while unresolved issues are addressed for other departments. This is the transition from the planning phase to the implementation phase in the project life cycle.
Approval from the working state to the commit state is determined by two factors:
• How well the total of all the depart ments' sizings fit into the amount that was funded in the candidate state. If funding is inadequate, tradeoffs are made. If the tradeoffs are significant enough, it may be necessary to move the project back to the candidate state.
• All impacted departments must be able to commit resources to the project or the responsibility of the work must be transferred to a department that can commit the resources.
Commit. This state denotes projects that are committed for implementation. At this point, a financial and schedule baseline can be set based on the sizing information gathered in the working state. The sizings can easily be represented in a work breakdown structure, which provides a smooth transition into a commercially available schedule management tool. This transition is the point at which the emphasis of a project shifts from scope and cost to schedule and cost.
A project finishes the commit state when the implementation is complete. RSPLAN does not require a formal approval to complete this state. It is typically associated with the delivery of the completed product to the customer.
Figure 3. The RS PLAN Suite of PM Tools
Access to the RSPLAN Internal Facilities is provided directly through the GUI. The external link to CMVC is maintained by placing the RSPLAN project ID in the reference field of appropriate CMVC features. These features can then be queried directly from the RSPLAN GUI. The external link to AutoPLAN II is established by first batch loading all of the sizing information from RSPLAN into AutoPLAN Il. AutoPLAN II can then be started directly from the RSPLAN GUI.
The external interfaces provide the capability for users to create additional project management tools that utilize the data stored in RSPLAN.
*AutoPLAN II is a registered trademark of Digital Tools, Inc?
Shipped. At this point the project transitions from implementation to maintenance and support. Typically a skills transfer would be done from the project team to a product support group and the resources assigned to the project would be reassigned to a new project. The shipped state correlates closely with the termination phase of the project life cycle.
The shipped state ends with an analysis of a project's overall performance. This is done by comparing the baseline values for scope, cost, time and quality with the measured values.
Communication Management
As organizations get larger and projects become more complex, the problems with maintaining effective communication channels between all project team members becomes increasingly difficult. The number of communication channels that exist on a project can be calculated based on the number of, team members. As a team expands, multiple communications channels are created, which decreases the overall efficiency of the team.
This problem was recognized and addressed with RSPLAN. There are several forms of communication that occur day-to-day on a project: meetings, telephone calls, electronic mail, and so forth. Some of the communication is necessary to solve problems. However, a percentage is simply communication of status or notification of a particular event. This communication is necessary but very inefficient if it requires manual intervention. Since RS-PLAN controls the process events, an event notification facility was incorporated into the project flow control model. This allowed for real-time communication and action when an event, such as an approval or state change, occurred on a project. It reduced the time that elapsed before an action was taken and it eliminated the need for “status” meetings.
Managing Change
Customer demand, funding availability and competition are an ever-present influence on a project and change the scope, cost, time and quality. The degree to which these changes affect the project team must be assessed. An effective project manager or project management system needs to be able to control how these changes are incorporated into the project without being encumbering.
The RSPLAN project was designed with a change control model in mind. This model has three tiers of control. The first tier is associated with projects in the open state. The originator of the project defines the basic project scope and time frame and has full control of all changes with no approval necessary.
When projects move to the candidate and working states, usually several other people in addition to the originator are making decisions based on the information associated with the project. During these states, a change in scope or time frame could affect these decisions. Any change needs to be assessed and approved by the person responsible for the next approval of the project. The approval of the change is very informal and requires the approver to make an assessment of the impact and to notify all affected users.
Once a project has moved to the commit state, the potential impact of a change is very broad. RSPLAN requires a formal change request to be submitted and approved through the same process that the original project was approved. In this way all concerned parties have the opportunity to assess the change themselves and voice any concerns. Only when the change request is committed will the changes be applied to the project.
There is actually a fourth tier that addresses changes to projects that are in the shipped state. These changes are, in effect, new projects rather than changes, since the original project is completed. These changes are opened and submitted as new projects in RSPLAN.
Links to Other Parts of the Project Management System
Once put into a production environment, RSPLAN became another among the multitude of project management tools available to the project manager. All of these tools are intended to help, but since very few of them can exchange information, the tools and the data contained within them are isolated.
The challenge addressed by RSPLAN was to form a seamless user interface that includes the most useful project management tools. The users of RSPLAN identified a suite of tools that enabled them to manage all of the aspects of their projects. In addition to the scope management capabilities of RSPLAN, this included financial analysis tools, a scheduling tool, and a quality management tool. The RSPLAN graphical user interface was customized to incorporate direct access to these tools. Information was communicated between the tools either through real-time data exchange or through a daily batch refresh. The choice of method depended on the capabilities of the tool. A tool that provided an API (application programming interface) was ideal; however, a simple import/export facility was sufficient.
It became apparent during the development of RSPLAN that no tool is the end all. For that reason RSPLAN has both a command line API for data retrieval and a C programming function library for input of “sizing” data. Since it is built on top of a DB2/6000 database, it also has the standard import/export capabilities for all data stored in database tables. This allows other tools to be built on top of RSPLAN.
Figure 3 illustrates how all the pieces of RSPLAN come together to form a robust suite of project management tools through a single user interface.
Conclusion
Project management tools, often marketed as “complete” PM systems, typically specialize at managing time and cost during the project implementation phase. To set a sound framework for a project, these tools should be complemented with a tool specializing in scope and cost management early in the project life cycle.
The RSPLAN tool was specifically designed to manage all elements of a project during the concept and planning phases. It initiates and controls the project's scope definition, then generates a three-level Work Breakdown Structure from early cost and time frame estimates. The framework created by RSPLAN provides a smooth transition into commercially available schedule management tools.
The RSPLAN tool has been praised within the IBM RISC Systern/6000 Division as a vehicle to organize and assess potential projects prior to expending significant effort. This has saved both time and money and has allowed resources to focus on the projects that are key to the division's success. ■
