As we look for ways to improve our organizations, we often look to adopt industry standards, guidelines, directives, policies, or something like them. They are all designed to help us be more effective, more productive, and more compliant. They influence what work we do and the way we do it. So I choose to think of these standards, guidelines, etc. as "practices"; some are old, some new, some bureaucratic, some bad, some good, and some have emerged as "best practices."

Unless our organization is in complete chaos, it's helpful to begin charting a course toward improvement by mapping these practices to our current way of doing things. The mapping helps identify where we already meet the guideline or where we need to improve. As we begin adopting the new set of practices, the mapping helps us gauge how well we are progressing through our improvement activities and when we have achieved our goal.

One of the improvement efforts we often undertake is to begin using tools that automate our current practices as well as the industry practices we are trying to adopt. It helps to view the practice guidelines alongside the new tool feature-functionality set to evaluate its capabilities before purchasing it. We want to determine what we can automate, and ensure that the tool will indeed help us become compliant with the industry practices.

This article is about mapping industry project management practices to a tool. But there is more to it than just a mapping.

While mapping industry best practices to a tool of preference is important, mappings by themselves are insufficient in helping us determine how to effectively adopt the tools. Most process engineers, change agents, and managers have come to realize that industry standards, guidelines, directives, and policies are not about whether their company is compliant with them, but whether they can leverage these practices toward improving the way they work. Mappings get us halfway to our tool implementation goal, and they are a necessary exercise for ensuring that what we "improve" will actually benefit our organization. The other half of the task is to extend the mappings to include tool configuration and tool use-case scenarios to effectively apply them to our work environment and take full advantage of what they offer.

This is the first of two articles written to help you understand the relationship between project management practices and a tool, and how to leverage that relationship to improve the way teams work in the hope of adding value to your business, enterprise, or other organization. This first article introduces the Project Management Institute's Project Management Body of Knowledge (PMBOK) Third Edition, IBM Rational Portfolio Manager (RPM) tool version 6.1, and how this tool's feature-functionality maps to the PMI PMBOK practices. The second article will discuss how to configure and implement RPM to help you achieve the PMI PMBOK practices using example use-case scenarios.

Note: I will begin with an introduction to the PMI PMBOK practices, then move on to RPM key features and functions. If you already have a good understanding of these, you can jump directly to the section titled "How RPM feature-functionality and PMI practices relate to each other."

An introduction to the PMI PMBOK practices

PMI PMBOK is a basic reference for those interested in or already working in the project management profession. It contains a subset of the body of knowledge that exists in the minds of those working in project management roles and in academia. That subset is generally understood as the best practices in use. The PMI PMBOK is a set of guidelines with its own set of key elements and a defined framework.

Within the PMI PMBOK, the project manager (PM) role, project management processes, and related artifacts are grouped in the project management discipline as knowledge areas. The PM processes describe best-practice details for each knowledge area. The PMI PMBOK framework consists of process groups, knowledge areas, and project management processes (see Table 1: PM process matrix). The knowledge areas group the PM processes by project management content. That is, the content of the PM processes can be categorized into one of nine knowledge areas. The process groups (Initiating, Planning, Executing, Controlling, and Closing, etc.) organize the more detailed PM processes over time. Therefore, the process groups are states in which a project can be at various times from start to completion. These should NOT be considered phases of a project. Whatever the project provides will have a development-construction-service lifecycle of its own. It will dictate phases necessary for the build or service for whatever the project was designed to complete.

(Note: In Table 1, the knowledge areas are numbered starting from 4.0 because that is how they are numbered in the PMI PMBOK.)

What follows is a brief discussion of each knowledge area shown in Table 1 in order to give you IBM Rational's perspective on the PMI PMBOK with respect to the RPM tool.

The Project Integration Management knowledge area processes are, in a single word, designed to coordinate the activities of a project. These processes help us coordinate with all the stakeholders to 1) get our arms around the problem we are going to solve in the project, 2) direct them through the project, and 3) manage any changes they have to the project. Any of us who have been a project manager, even on just a few projects, know that planning and oversight takes a great deal of coordination. This first of two articles will show you the RPM feature-functionality that helps you coordinate your project. Part two of this article will provide you with information to effectively configure and use that feature-functionality.

The Project Scope Management knowledge area processes focus on managing what is included and what is not included in the project, including the planning, definition, verification, and control. In other words, managing change, as mentioned in the Project Integration Management knowledge area above, focuses on change to the project that doesn't broaden the scope of the project. It just helps describe what we originally intended or it corrects a misunderstanding of those intentions. A work breakdown structure (WBS) represents the in-scope work of our project. The requirements you have and the work that realizes those requirements in a set of project deliverables defines your scope. Managing scope means re-prioritizing what work we do in the project according to changes in the approved set of requirements.

While the PMI PMBOK differentiates managing change and managing scope, RPM acts upon them both in a similar fashion. Change, in or out of scope, can impact a project, add or remove work, and impact the cost and schedule. RPM can't make change or scope decisions for us. But in this article, I will discuss how RPM can help you organize and prioritize a project's current scope to be able to distinguish a change in scope from an in-scope change. Additionally, RPM can capture our process to deal with both change and out-of-scope work. In the second article, I will present scenarios that illustrate managing scope.

The Project Time Management knowledge area goes hand-in-hand with the Project Cost Management knowledge area. Project managers build a WBS of activities to be completed by assigned resources. The WBS represents the scope of our project. The time and cost associated with the resources completing that work in the WBS is considered time and cost management. RPM has all the WBS capabilities and financial functionality to build a complex or simple work schedule with all the estimating of expenses, capital expenditures, and benefits for complete return on investment calculations and payback profiles. Later, I will show how RPM provides features for every knowledge area practice, from planning the WBS activities, applying resources to them, as well as scheduling and leveling them to tracking the work, financials, resources, and project performance.

The Project Quality Management knowledge area is intended to guide the project through the necessary steps to ensure the results meet customer expectations. The PMI PMBOK provides guidelines for quality assurance and quality control. Later, we will see how RPM templates, workflows, and statistical measurements play a vital role in a project team and all stakeholders maintaining a consistent, controllable, measurable execution of the project WBS.

The Project Human Resource Management knowledge area guides the project manager in how to organize and manage the project team. Managing team dynamics is not an easy task, even if team members are used to working together. But if everyone 1) knows what their responsibilities are, 2) when their work is to start and be completed, 3) are assured they will be assigned work commensurate with their skills and competencies, and 4) know that they won't be over-allocated on the project, then life on a project can be rewarding, even fun. RPM does not replace the human dynamics of a team communicating and functioning well. But RPM does provide the functionality for describing roles and responsibilities, establishing milestones, skill-based assignments, and resource overload protection, as I will show later.

The Project Communication Management knowledge area provides insight into all the important communication and collaboration necessary for a successful project. An informed collaborative relationship with the team, stakeholders, and the customer solidifies the trust necessary for a successful project in both good and difficult times. Once again, the human factor is the most important aspect of good communication, but RPM provides the vehicles for good communication. I will describe how workflows, security rights, data permissions, and real-time analytics contribute to good team communications.

The Project Risk Management knowledge area in the PMI PMBOK covers all aspects of risk management, from identification and analysis to monitoring and resolution. Many project managers are very good at identifying risks. Too often it ends there. RPM helps a team do the easy things, like capturing a risk and assessing it. But it also offers automation for the hard things, too, such as scheduling risk items as work in your WBS and watching the progress of that work to ensure a timely response to the risk.

The Project Procurement Management knowledge area processes help you plan, execute, monitor, and control products, services, or results outside the project team needed to complete the project. In today's organizations, few projects get completed without purchasing something and/or engaging contract workers. RPM has features to manage all aspects of each.

Back to top

RPM key features and functions

Table 2 describes the RPM key features and functions that will be used in the mapping to the PMI PMBOK practices. RPM has capability beyond this list of features and the project management practices described in the PMI PMBOK. These additional capabilities are primarily associated with the automation of portfolio management methods, which is beyond the scope of practices described in the PMI PMBOK. However, many RPM capabilities for portfolio management activities must be performed on, by, or from every project in a portfolio such that all the portfolio management practices can be useful. As I describe the mapping in later sections, I will point out some of the key functionality beyond the project management practices. Use, therefore, Table 2 as a reference and glossary for features that are discussed in later sections.

Back to top

How RPM feature-functionality and PMI practices relate to each other

This section provides a mapping between the PMI PMBOK knowledge area processes and IBM Rational Portfolio Manager features and functionality. Following Table 3, I will discuss why the RPM feature-functionality will help you implement the PMI practices.

Back to top

RPM functionality and the PMI PMBOK

In the remaining pages, I will provide a detailed discussion of what functionality IBM Rational Portfolio Manager offers to help achieve the best practices in each of the PMI PMBOK process groups. This understanding is the primary benefit derived by mapping the PMI PMBOK practices and the RPM tool. In the second article, I will provide an in-depth discussion of how to configure and use that functionality effectively.

Initiating process group

The key concept of the Initiating process group is to establish the boundaries for your particular project. While developing a project charter and scope statement (see Table 4) are key elements to documenting those boundaries, there is really a significant amount of effort, decision making, and planning at a program, enterprise, or strategic level that is not addressed in the PMI PMBOK. Most of that work is called "program management" and "portfolio management." Rational Portfolio Manager supports all of an organization's governing activities, including projects, programs, and assets -- whatever may be in the organization's portfolio. More importantly, RPM treats projects and assets like they were investments. While knowing everything about one project is very important, there is a more strategic need to compare, prioritize, and adjust the organization's portfolio of projects and assets to meet the business need. RPM provides functionality to help make those decisions about the project itself, on its relationships to other projects, and in comparison with other projects having similar characteristics.

But let's turn our attention to the RPM feature-functionality that relates to the PMI PMBOK Initiating process group.

The Initiating process group only uses two Project Integration Management knowledge area processes. But there is plenty to do when initiating a project. The processes -- developing a project charter and an initial scope statement -- map to primarily six key features in Rational Portfolio Manager: Proposal, Templates, Attributes, Documents, Portlets, and Security Rights. Each will be described in the context of the Initiating process group.

RPM provides a proposal feature for each new initiative. This feature functions as an initial project framework. You can create the proposal from scratch or from a template. A proposal template can contain all the initial information that is common to all new initiatives and/or standard within an organization or enterprise. The proposal framework is based on a WBS and all its constructs, descriptive information about it (e.g., staffing, risk, requirements, changes, issues, calendar, analytics, etc.)

The PMI PMBOK indicates that the initiating activities are often outside the scope of a project. It goes on to list what some of those activities are, but the Initiating process group section focuses on capturing the results of those external activities that define the project boundaries in a project charter and scope statement. RPM has database forms and document management functionality allowing you to capture the charter and scope statements as documents in the database repository, link to them as external documents, or capture the information as data fields in predefined forms located in the database repository. These forms are called portlets. All the characteristics are captured in information portlets, including project objectives, attributes, financials, assumptions, constraints, resources, documentation (e.g., charter and scope documents), and many more. Using a template allows all of these portlets to be pre-loaded with proven, standard, or common information to provide consistency from project to project.

RPM has functionality to collect and configure the project boundaries as attributes of the project. Boundaries include things like environmental factors and organizational assets. Examples of attributes include business units sponsoring the project (e.g., finance, marketing, IT, etc.) or project type (e.g., e-commerce, regulatory, infrastructure, etc.). These attributes are used in all the process group processes to characterize and categorize the project within and external to the project. In the Monitoring and Controlling process group, we will discuss attributes in the context of analytics. In the second article, I will show you how to configure and use attributes to achieve practices in all the process groups.

After all this information is captured in the repository, it can be made accessible to anybody and everybody who needs to have access to that information. RPM provides functionality to specify security rights for an organization's resources -- from each individual's ability to see the proposal or project to viewing and editing permissions within the project.

Planning process group

As shown in Table 5, there are many knowledge area processes utilized from the PMI PMBOK's Planning process group. These are detailed planning activities. At this point in the project, we are beyond the charter and scope deliverables in the Initiating state. We are going to be refining those deliverables as we go through the planning activities, and we will be progressing toward creating a WBS, developing a schedule, and doing some ballpark estimating. We are also going to be looking at our quality plans, resource requirements, and determining how to communicate and collaborate on the project. We'll address risk plans as well as establish an initial risk list and related issues. We are going to deal with purchasing, acquiring, and contracting activities.

As in the Initiating process group, Rational Portfolio Manager goes beyond the planning of a single project described in the PMI PMBOK. RPM will help you structure your overall set of initiatives, programs, and projects into portfolios for your entire enterprise. RPM will automate your initial scheduling and leveling on your project and affect change to other projects that you can visualize during "what-if" scenarios. The results of those what-if scenarios can be adopted as your actual plan. An enterprise's resource capacity for all projects and assets in the enterprise can be part of planning activities based on needs from individual projects in RPM. Let's now focus on the RPM feature-functionality that relates to the PMI PMBOK Planning process group.

The Project Integration Management knowledge area focuses on various process flows, including managing change and configuration, staffing the project, document review and approval, risk and issue management, and many more based on the needs of the project and organization. RPM has a workflow engine that automates team communication and collaboration. The workflow engine can be used on the fly as a notification capability to notify stakeholders of some event. Workflows can be created in advance to represent and execute processes for activities, such as change management, staffing requests, architecture evaluations, and document sign-offs. All the documents associated with a project management plan can be contained in the repository as a document under version control or as a URL link to an external document management system.

The Project Scope Management knowledge area processes called Scope Planning, Scope Definition, and Create WBS are addressed in RPM by document templates, WBS structures, requirements, scorecards, and portlets. In putting together a Scope Management Plan, it helps tremendously to have a document template to ensure both a comprehensive and a concise plan. RPM provides the functionality to capture documents as templates that can include instructions and/or examples in the various sections. In fact, RPM will allow you to capture an existing completed or delivered document as a template. That template can be tailored as desired.

As part of Scope Definition, RPM has a requirements feature to capture stakeholder needs, as well as portlets (described in the Initiating phase) that allow you to describe, qualify, quantify, estimate, and track everything from the scope statement to the project acceptance criteria. RPM provides a scorecard feature that provides a graphical view of the subjective and objective project management information. It can be used to capture customer expectations and understand how well the project is meeting them. More importantly, the analysis of stakeholder needs can be captured using the requirements feature. These requirements cannot only be captured in the repository, but they can also be scheduled just as any WBS element might be.

Creating a WBS can be a daunting task. The RPM template feature provides access to WBS structures created as an organizational standard or just a typical structure from previous similar, successful projects. PMI PMBOK's Create WBS process area intends for you to decompose, manipulate, and tailor the WBS to whatever will work for that project. When using an RPM WBS template, you can use it in its entirety or use only the desired summary tasks, schedulable tasks, and milestones. RPM allows you to create, adjust, modify, change, delete, and add any WBS element. You can structure and restructure the WBS to whatever level is necessary and sufficient. Finally, the WBS dictionary can also be a document template that is modified as necessary for the current project.

The Project Time Management knowledge area processes used in planning include all but the Schedule Control process. In addition to the features described above, when creating an initial WBS, RPM provides all the portlet information about every aspect of a WBS element to describe it, resource it, schedule it, estimate it, establish dependencies, and capture constraints. Activities can be resourced in three steps: First, roles are identified with skills and competency requirements for all WBS elements. Second, resources are defined in the repository with their known skills and competencies. Third, RPM provides a robust search engine to match the role competencies and skills to the resource competencies and skills with the best fit for their availability. Workflows can be used to kick off and capture various types of resource or estimation activities using, for example, a Wideband Delphi estimation technique. Estimates for the effort required can be captured in the financials portlet for every WBS element. Activities can be sequenced and dependencies set for any WBS element in the same project or any other project. This can be accomplished in the Gantt chart display or in the WBS element portlet. Following schedule development activities in the PMI PMBOK, you calculate, level, and baseline the sequence of activities as resources as schedule constraints dictate. RPM has functionality to do all that, but with automation to modify plans and compare that new proposed plan to the current baseline.

The Project Cost Management knowledge area processes found in the Planning process group include Cost Estimating and Cost Budgeting. These process areas work hand-in-hand with the Project Time Management process areas. So, in addition to the workflow, portlet, WBS, and dependency features mentioned above, RPM provides a financials feature to capture those estimates, and spread them over time. From the financials portlet for any WBS element, you can capture expenses, capital costs, and benefits, then calculate return on investment. Additionally, cost centers, charge codes, and funding units can all be configured for an enterprise and then used as appropriate on each project. Finally, all the budgets, funding, costs, and expenses can be in one or more international currencies and exchange rates.

The Project Quality Management knowledge area processes in the Planning process group have you focus on planning what the team must do to ensure quality results. RPM provides workflows and templates to support quality planning. Defining which policies and standards are applicable can be captured in a document template to be used when the project is initiated and then tailored as necessary. More importantly, workflows can be created for quality activities, such as cost-benefit analysis or due diligence. Scorecards can be used for quality ratings on a project. In fact, an organizational-level scorecard with the benchmark ratings could be included with each project template. Both the benchmark rated scorecard and the scorecard in progress on the project can be activated for comparison purposes as the project executes.

The Project Human Resource Management knowledge area processes, addressed in the Planning process group, deal with establishing the project roles and responsibilities. The Human Resource Planning knowledge area requires you to establish the roles, skills, competencies, and their associated relationships on a project. RPM provides the functionality to capture all that information in the repository and allow people in a resource management role to associate each resource in the repository with all the applicable roles, skills, and competencies. When it comes time to resource a project, the search for people to be assigned to project roles will consider not only their availability, but also how well they match the skills and competencies listed. Additionally, RPM has features beyond what is specified in this knowledge area process. RPM offers portlets characterizing a resource's educational background, geographical location, industry experience, and more, all designed to help resource managers find the right people for the right project.

The Project Communication Management knowledge area processes in the Planning process group have you determine the information and communication needs of the project stakeholders. RPM provides a wealth of communications technology. First, workflows can be used to control and share information among stakeholders. A notification feature exists to send someone a communication connected to your email system. Alert functionality can be configured to automatically notify, warn, and inform stakeholders of events. A personal calendar can keep each individual abreast of his or her WBS responsibilities. More than fifty preconfigured reports can be used to design your own personalized reports. There are bubble charts, pivots tables, scorecard graphics, and a Web portal to view analytics from the RPM repository (e.g., WBS tasks not started, high-risk items, etc.), and you have access through that same Web portal to view other browser-based applications.

The Project Risk Management knowledge area processes addressed during the planning phase deal with everything regarding risk management except risk monitoring and control. Risk plans can be part of the documentation management function in RPM. RPM provides features to capture risk identification and documentation in information portlets for each and every risk. Qualitative risk analysis functionality can be configured and implemented in risk scorecards, and quantitative risk analysis is automated in a probability and impact matrix. More important, the risk response can be planned and scheduled into the WBS as any other WBS element. This means that after you get into the risk monitoring and control activities, you have all the feature-functionality for a risk that you have with any WBS element. Finally, all this information can be part of a project template, so every new starting project can have typical risks already addressed in the WBS with effort, resource, and cost estimates.

The Project Procurement Management knowledge area processes found in the Planning process group include Plan Purchase & Acquisitions and Plan Contracting. If there is any work that cannot be done internally, the PMI practices are designed to guide you through determination of what work falls in that category and how to plan it into your project. RPM provides functionality to create, identify, and quantify contracts for services to allow work to be charged against that contract in support of the project. Additionally, RPM provides invoicing expenditures against any predefined charge code.

Executing process group

The Execution process group embodies knowledge area processes that really concern communication and collaboration. It involves directing and managing the overall activities you had in your plan, coordinating that work, and making adjustments to the changes that come along, because they will inevitably change. Execution is about looking at quality assurance, not quality control, because we need to ensure that we are performing the right processes in our project to assure a quality product. We're not only going to acquire the best team to fit our plan, but we are also going to be developing that team, keeping track of what their skills are as the team members improve their strengths, and adjusting the resource assignments accordingly. Those skills need to be captured and made available to resource managers to ensure they get the right resource(s) with the right skills and competencies. One more thing: most of the processes discussed thus far have been the primary responsibility of the project manager, technical leads, resource managers, and functional management. In execution, the entire project team and most all stakeholders will be responsible for parts of the execution practices in the PMI PMBOK.

Just as in the first two process groups discussed this far, RPM provides automation for execution of portfolio management processes as well as project management processes explained in this article. In RPM, you can employ many of the feature-functions explained thus far to help you manage the execution of many projects. Directing the execution of many projects, developing resources across the enterprise, communication, and collaboration in one project has similarities to the same activities for many projects, whether they are organized into programs or portfolios. RPM can help you accomplish workflows at any level of the portfolio. RPM assures quality for one to many projects. More importantly, RPM's repository provides capabilities to inform not just one person or a project team of their current status, but to consistently and uniformly educate an entire enterprise regarding the health of their investments.

We will now discuss these capabilities from a project perspective.

The Project Integration Management knowledge area during execution has you focus on direction and management of the execution. Every project participant will be executing WBS tasks, initiating change, and identifying risk, issues, and action items. Project management will be managing the day-to-day activities and customer expectations. It is here in the execution state that RPM workflows will be executed to kick off, communicate, expedite, and control the implementation of work. RPM alerts will notify project team members and other stakeholders of important events; for example, there is an alert to indicate work not started on time. Collaboration will occur with the notification function. It consists of internal email with proprietary attachments to notify team members of changes to their assigned project elements in order to request start/finish re-negotiation or any other communication relevant to the element under discussion. Additionally, we must remember the execution of work itself. Team members can use their personal calendar to see what activities they have to do next. They can enter time and effort to show progress and invoiced expenses to show accrued costs. There are links in the URL portal (called "My Portal") and filtered queries to the repository that allow team members to see work due to start next. Each and every view has a set of bands and headers (columns of information) that can be configured in just about any order to meet monitoring needs. Filtered queries are available to see work tasks, document lists, scope elements, resources, and more.

The Project Quality Management knowledge area processes in the Execution process group guide you in applying the planned quality activities to ensure a quality result. RPM workflows can play an important role in executing planned quality activities. For example, team members can have a workflow for checkpoint reviews by stepping through the review of work products with voting applied for approvals. In this example, an independent QA group could review a completed workflow to check for improvement opportunities. QA teams can use scorecards to ask weighted questions about the execution of the process, policies, and standards. An auditor could review document version history to meet regulatory requirements because RPM has a version control capability. When project information about any RPM object (e.g., projects, tasks, resources, financials, etc.) is entered or modified, RPM requires the object to be checked out and then checked in when entry is complete.

The Project Human Resource Management knowledge area processes addressed during execution efforts include acquiring and developing a team. To acquire resources, the project manager may have to request resources from a resource manager. A built-in workflow in RPM allows a project manager to send a staffing request to multiple resource managers, as necessary. The workflow engine will send the resource request via email to them for staffing. The resource managers may suggest a list of resources to the project manager, or they make the assignment themselves. When team members develop new skills and competencies to help improve project performance, RPM provides the capability to capture those skills to help ensure they are considered during the next resource staffing activity. Finally, resource scorecards can be used to evaluate or rate a resource's timely acquisition of skills as well as overall performance to identify new skill needs.

The Project Communication Management knowledge area processes in the Execution process group focuses on distributing information. RPM provides an all-inclusive information repository on any aspect of a project's execution from the WBS, documentation, and reports to resources, change, and financials, just to mention a few. Everything in the repository is available for any stakeholder with the right security access and data permissions. RPM takes this process area and extends the distribution to real-time awareness. Workflows, notification emails, personal calendars, alerts, reports, URL portals, and more all contribute to the immediate awareness of project information. The Project Procurement Management knowledge area processes found in the Execution process group include requesting seller responses and selecting sellers. When a project team select a vendor for tools or consulting services in support of a project, RPM provides the document management functionality for the team's proposals. The proposal bids, costs, or estimates can be incorporated into the project financials as contract work. The contract information can be created, described, and quantified in a separate contracts view. Finally, scorecards can be used to evaluate the sellers with weighted criteria.

Monitoring and Controlling process group

The Monitoring and Controlling process group, as described, reveals a great deal of overlap between knowledge areas (see Table 7) for several good reasons. First, to control efficiently, you must monitor in a timely manner. That is, you cannot look at out-of-date data and make good decisions. Second, to control effectively, you must monitor accurately. In project terms, that means your monitoring must consider many variables to provide a true picture. The PMI PMBOK intent for this process group is that you observe and measure things on a regular basis, with current information, then do something about what you see. I call this the "see and do" phase.

As in other process areas, RPM automates more than what the PMI PMBOK covers. It doesn't matter if you have to track and control one change in one project or ten changes in ten projects. To govern these efforts effectively, you will need to establish a change process to address in-scope and out-of-scope change. RPM not only allows you to plan and schedule a change as work, but it has functionality to link those changes to all work that will be impacted. It is one thing to measure a project's health. It is quite another to be able to see the same kind of health status with multiple criteria feeding it for many projects. RPM provides that kind of insight for the enterprise. Let's look at how RPM helps you monitor and control one project.

The Project Integration Management knowledge area processes for Monitoring and Controlling focus on oversight, reaction to performance indicators, and addressing change. Project integration management in the Monitoring and Controlling process group is about coordinating what you see and what you do about what you see. RPM supports both. RPM responds to these practices with dashboards, analytics, workflows, and scope management. RPM provides a complete set of textural and graphical analytical features to monitor a project, program, and portfolio. First, RPM provides the project team with a typical Gantt chart for viewing schedules. RPM provides a portal into the repository with a complete set of project analytics, including -- but not limited to -- charts on late-to-start tasks, critical risks, and high-priority change requests for a project to trended data in pivot tables and their corresponding graphic representation. All charts and diagrams have a drill-down feature to take you directly to the current measured data. RPM provides both standard planned versus actual work measurements and earned value measurements. RPM lets you "see" what is going on in a project. Next, RPM provides not only monitoring capability, it provides functions to help you control the work and changes to the work and requirements. Pre-defined alerts are available to notify you of controlled events, such as estimated effort to complete (EETC) reduced by a team member, workflow not responded to, resource assignments, tasks late to start or finish, and much more. Workflows can be implemented to walk through the change control process. More importantly, risks, issues, changes, just about any exception, can be characterized, resourced, scheduled, and monitored just as any WBS task. RPM lets you capture exceptions and "do" something about them all in one repository for effective coordination.

The Project Scope Management knowledge area processes for monitoring and controlling focus on acceptance of what was delivered (the scope) and the process of changing the scope (decision and impact). One could argue that scope verification is not about monitoring or control and may fit better in execution. But, while there is much communication and collaboration involved with managing the scope, like in the Execution process group, managing scope is about recognizing a change in scope and doing something about it: again, "see and do." As we stated above in the section on Integration Management processes for monitoring and controlling, RPM helps you see and do something about changes. The same goes for those changes that affect the project scope. RPM can capture requirements and any characteristic or attribute about them, including rank, priority, acceptance criteria, and more. When it is time to verify the scope, you can link to test result documentation for the results of each requirement. A scorecard can be used to provide a weighted score on how well a requirement meets expectation as part of acceptance. Workflows can be used to organize inspections, audits, and reviews, the acceptance process, or verification that the requirement was completed. For controlling scope, a requirement can be scheduled as work, that work can be baselined (hence the requirements), and changes that affect scope can be characterized, viewed, and implemented in the WBS (changing the baseline), or they can be implemented as work outside the current scope (as a subproject not affecting the baseline).

The Project Time Management knowledge area process used in the Monitoring and Controlling process group is simply a matter of schedule control. The PMI's intent is to have projects practice good measurement technique to determine factors that might influence project schedule, then appropriately manage change. RPM provides Gantt charts to visualize the scheduled tasks and milestones and it can export/import Microsoft Project files. Tables, charts, and graphs can be created to show schedule variance in both traditional formulae and earned value. Each team member has a view of his or her own scheduled tasks, and project managers can see all the teams' tasks. RPM views provide filters to show work that is starting/finishing late, scope elements (e.g., issues, risks, changes, etc.) that may affect the schedule, plus drill-downs into both the work and the scope elements to find out what the details of the influencing factor might be. Alerts can be configured for each task for delayed start/finishes, estimate to complete changes, schedule variance changes, dependency changes, late timesheets, and more. After a team sees all the factors influencing the project, action can be taken. RPM provides what-if scenario functionality for one or more projects and planned vs. proposed Gantt schedule bars. This allows a project manager to recalculate a schedule based on some changed dates or resources, then view the new proposed schedule along with the current baseline.

The Project Cost Management knowledge area process used in the Monitoring and Controlling process group has to do with cost control. As in Project Schedule Management, PMI's intent is to have projects practice good measurement technique to determine factors that might influence the project costs, then appropriately manage change. RPM provides financials tables and charts for each task in pivot tables with graphic representations to slice and dice the data and visualize the issues with project financials. Tables, charts and graphs can be created to show cost and budget variances in both traditional formulae and earned value. Alerts can be configured for budget variances and more. Pivot tables can be used to review financials from costs-to-date, net present value, and gross profit/savings. Once a team sees all the factors influencing the project, action can be taken. For instance, resources and labor rates can be addressed; expenses and capital expenditures can be monitored and controlled by a limited group for integrity. Multiple cost centers and cross charging can be accomplished to adjust funding resource commitments. Funds can be established and adjusted over different time-phased periods.

The Project Quality Management knowledge area process in the Monitoring and Controlling process group requires focus on quality control. Earlier, during the Execution phase, we performed quality assurance activities and automated some of the reviews and audits with RPM workflows. Now, the PMI intends that we measure process and product results with statistical analysis. RPM provides statistical analysis for cost and schedule analysis, volume of change, and cost/payback analysis. Additionally, rudimentary statistical measures exist on multiple health indicators (cost, schedule, quality) with upper and lower control limits represented by color.

The Project Human Resource Management knowledge area process addressed during the Monitoring and Controlling phase deals with general management of the team from team dynamics to their performance appraisals. If there is anything RPM can help a team with, it is the establishment of clear objectives, plus emphasizing good communication and collaboration. WBS roles, task skills and competency requirements, and viewable assignments are all part of the RPM repository. That means a team member can insert issues, plus execute workflows to address them as a team. A team member can enter time, knowing that changes in the EETC will alert the project manager. A project manager can use scorecards that are built into a scorecard portlet in each resource's personal record for individual performance on a project.

The Project Communication Management knowledge area processes in the Monitoring and Controlling process group requires focus on collecting and distributing project performance information that people make decisions on, as well as dealing with the issues about that information. Since everything about a project is captured in the RPM repository, collection is a direct result of managing your project with the RPM tool. To see that performance information, RPM has a variety of textural and visual analytics. Scorecards can be used to evaluate project performance from a customer's perspective based on qualitative, quantitative, and weighted questions.

We have not talked much about investment maps, because they are primarily used for seeing information about many projects in a portfolio. But RPM's investment maps can be used for comparing a project's status to other projects, and they can be used as a window into the project's health. RPM investment maps allow you to hover over the project in the bubble chart, see the project characteristics, and choose from a number of other charts that drill down to more detailed performance information on that project -- from general health status to detailed pivot tables on a project's financials. There are over seventy preconfigured reports that can be re-designed to fit your organization or project. Time and cost recording and reporting is available from the time and expenses functionality. All of the information viewable via RPM is in real-time, as it currently exists in the repository. Managing the issues that stakeholders obtain with the performance results can be difficult, to say the least. While RPM cannot take the place of face-to-face customer communication -- sometimes involving sensitive discussions -- RPM can help you see the root cause pertaining to the performance under review through its many drill-down capabilities. These include pivot tables, and the MY Portal dashboard analytics mentioned in the Integration, Time, Cost, and Communications knowledge areas earlier. The RPM notification and workflow features can help, too. Any time stakeholders have an issue with what they see, they can start and continue a sequence of notifications using the Notify context menu feature available on most objects in RPM. An issue workflow can be enacted to help the stakeholders know you are addressing their issues.

The Project Risk Management knowledge area process addressed during the Monitoring and Controlling phase deals with responding to risks already identified and tracking them during their resolution. As mentioned in the Planning process group, after risk items are identified, they can be planned and scheduled as any other work element. Monitoring a risk can be handled with alerts and performance measures (e.g., variances, etc.) just like any other WBS item. Issues concerning risk resolution work can be raised with the same visibility as any work item. Workflows can be started for any review and/or approval needed to verify that a risk has been resolved.

The Project Procurement Management knowledge area process in the Monitoring and Controlling process group facilitates contract administration. This process is intended to manage the contract as well as the relationship with the contractor. Besides tracking contract information in documents in the RPM repository, resources can enter time or effort against a contract. Their time can be automatically billed against that contract based on how cost center cross charges are to be reconciled. When expenses are incurred against a WBS task, an invoice can be created with all the invoice and payment details. Then the content of each invoice can be itemized as separate expenses with the costs associated to predefined expense charge codes.

RPM goes beyond the project analytics for monitoring and control. Just about any analytic used on a project can be used in any organizational measurements. RPM provides investment maps, scorecards, pivot tables, and reports from the portfolio.

Closing process group

The PMI intent for the Closing process group is to close out all work and capture the heuristics, legacy, and lessons learned from a project to allow us to utilize the things that worked well in future projects.

The Project Integration Management and the Project Procurement Management knowledge areas for closing processes includes termination of all work against the project. To control the project closure activities, RPM workflows can be used to initiate closing out a project to get approval from all required stakeholders and contract vendors. The entire content of a project in the RPM repository can be archived or used as a template for future projects, lessons learned analysis, and audits.

Back to top

Summary

The PMI PMBOK covers a lot of ground in the project management domain. IBM Rational Portfolio Manager feature-functionality supports all the PMI PMBOK practices and more. What is important about the mapping presented in this article is that we can now configure these features in the tool with respect to the knowledge area processes in the PMI PMBOK.

The mapping demonstrates that workflows can be used to support many knowledge area processes. For example, during the execution of the Project Time Management and Project Cost Management knowledge area processes during the planning phase, workflows can be used to initiate and capture various types of resource or activity estimation activities using a Wideband Delphi estimation technique. What we can conclude from this mapping, therefore, is that we need to configure a workflow for Wideband Delphi estimation. We can also ascertain from the mapping that a proposal template needs to be built in RPM to contain all the initial information that is common to new initiatives as required by organization standards. The template should contain all typical characteristics of a new initiative (e.g., typical staffing, risk items, requirements, changes, issues, calendar, analytics, attributes, etc.).

To help you complete an adoption of PMI PMBOK practices using RPM, a second article in an upcoming issue of The Rational Edge will evolve the mappings presented here. That article will discuss what needs to be configured in the tool in order to take advantage of its features, and I will present several use-case scenarios to help you implement those features effectively.

Back to top

References

• A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition, ©2004 Project Management Institute, Four Campus Boulevard, Newton Square, PA 19073-3299 USA
• Rational Portfolio Manager, Version 6.1, Copyright 2004, IBM Rational Software

About the author

Bill Cottrell is a PMI Project Management Professional assigned as the Process and Portfolio Management (PPM) evangelist for IBM® Rational software solutions. Bill is an experienced practitioner in project, program, and portfolio management, software engineering, and software process improvement. As the PPM evangelist, he has the worldwide responsibility for successful realization of IBM Rational Process and Portfolio Management solutions. He has twenty-five years experience managing, developing, operating, and maintaining engineering and information systems in various industries, including: aerospace, financial, government, software, telecommunications, computer and electronic, transportation, and utilities.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• An introduction to the PMI PMBOK practices
• RPM key features and functions
• How RPM feature-functionality and PMI practices relate to each other
• RPM functionality and the PMI PMBOK
• Summary
• References
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Try Rational System Architect

See how this fully integrated collection of models and documents can help you better align your IT systems and infrastructure to simplify business processes

Special offers