Establishing a PSO

When you are planning for a PSO, four critical questions must be answered. One of them deals with defining a desired future for your organization's PSO — the goal, so to speak. To reach that goal, however, you have to assess where you currently are with respect to it. The answer to that question identifies a gap between the current state and the future state. That gap is removed through the implementation plan for your PSO. This is the definition of a standard gap analysis. The four major questions, then, arranged chronologically, are as follows:

• Where are you?
• Where are you going?
• How will you get there?
• How well did you do?

Before you attempt to answer these questions, you need a foundation for answering them. The Software Engineering Institute (SEI) at Carnegie Mellon University provides just the foundation you need. Its five-level model, described in the next section, also gives you a foundation on which you can plan for the further growth and maturation of your PSO.

PSO Stages of Maturity Growth

Over the past 20+ years, SEI has developed and maintained a maturity model for software engineering. It has gained wide support and become the de facto standard of the software development community. The model was originally called the Capability Maturity Model (CMM) and more recently the Capability Maturity Model Integrated (CMMI). It has recently been adapted to project management in the form of a Project Management Maturity Model (PMMM). I will use the five maturity levels of the PMMM to answer two of the questions: Where are you and where are you going?

Figure 13-3 offers a graphic depiction and brief description of each of the maturity levels of the PMMM.

Figure 13-3: Project management maturity levels

Level 1: Initial

At Level 1, everyone basically does as he or she pleases. There may be some processes and tools for project management, which some people may be using on an informal basis. Project management training is nonexistent, and help may be available on an informal basis at best. There doesn't appear to be any signs of organization under project management.

Level 2: Repeatable

Level 2 is distinguished from Level 1 in that a documented project management process is available. It is used at the discretion of the project manager, and some training is available for those who are interested. Initially, the only sign of a PSO is through some part-time support person who will help a project team on an as-requested basis. In time, senior management will commission a PSO and give it very basic monitoring and control responsibilities.

Level 3: Defined

The transition from Level 2 to Level 3 is dramatic. The project management processes are fully documented, and project management has been recognized as critical to business success by senior management. A formal PSO is established, staffed, and given the responsibility of ensuring enterprise-wide usage of the methodology. Enforcement is taken seriously, and a solid training curriculum is available. There is some sign that project management is being integrated into other business processes.

Level 4: Managed

At this level, successful project management is viewed as a critical success factor by the organization. A complete training program and professional development program for project managers is in place. The PSO is looked upon as a business, and project portfolio management is of growing importance. The project portfolio is an integral part of all business planning activities. The PSO director has a seat at the business strategy table and may have the title of VP PSO.

Level 5: Optimized

At Level 5, the PSO is the critical component of a continuous quality-improvement program for project management. Progress in the successful use of project management is visible, measured, and acted upon.

Planning a PSO

You can now put the pieces of a plan together. Based on what I have discussed so far, your plan to establish a PSO might look something like what is shown in Figure 13-4. Before you can begin the activities shown in Figure 13-4, however, you have to write the Project Overview Statement (POS) for the PSO.

Figure 13-4: A plan to establish a PSO

The POS

Shown in Figure 13-5 is an example POS for a PSO implementation project submitted by Sal Vation.

The following sections take a quick look at what Sal submitted.

Problem/Opportunity

Note that the statement describes a business condition that needs no defense or further clarification. Anyone, especially the executive committee, who reads it will understand it and agree with it. The importance of this statement will determine whether or not the reader continues to the goal statement. In this case, the situation is grave enough that continued reading is a foregone conclusion.

Goal

The statement is clean and crisp. It states what will be done and by when. Note that it is phrased so that the project is expected to deliver results before the expected completion date. Sal recognizes the importance of early results to the executive committee and doesn't want the stated time line to shock them and perhaps jeopardize the project's approval.

Figure 13-5: An example POS for a PSO implementation project

Objectives

The objective statements expand and clarify the goal statement and suggest interim milestones and deliverables.

Success Criteria

Sal has expressed the success criteria in specific and measurable quantitative terms. This is very important. In this case, the criteria will help the executive committee understand the business value of the project. It is the single most important criteria Sal can present to them at this time to help them decide whether the project is worth doing.

Assumptions, Risks, Obstacles

Sal has called to the attention of the executive committee anything that he feels can potentially compromise the success of the project. These statements serve the following two purposes:

• They highlight for senior managers some of the potential problems that they might be able to mitigate for the project team.
• They provide some risk data for the financial analysts to estimate the expected return on the investment in a PSO.

The executive committee will consider the success criteria versus risk to determine the expected business value that can result from this project. In cases where other projects are vying for the same resources, the analysts would have a comparable statistic to use to decide where to spend their resources.

This is just a high-level risk identification. During project planning, you will document a detailed risk management plan.

Planning Steps

Sal will eventually get approval to move into the details of project planning in anticipation of getting executive committee approval of the plan so that he and his team can get to work. Sal might expect a few iterations of the POS before he gets that approval to proceed with planning. In my experience, senior managers often question success criteria, especially with reference to its validity.

Forming the PSO Task Force

The PSO task force forms the strategy group for this project. They are to be considered members of the project team. Their membership should include managers of business units that will be affected by the PSO. The size of the enterprise determines how many members there will be. A task force of five or seven members should work quite well, whereas a task force of 15 would be counterproductive. If voting will be used to make decisions, having an odd number of members will avoid tie votes. If an even number is used, the chairperson should have the tie-breaking vote. Without the support and commitment of each task force member, the PSO is unlikely to succeed. Because many of the task force members' operations are likely to be affected by the PSO, they must be a part of its mission and have an opportunity to be heard as decisions are made on the mission, functions, and services the PSO will provide.

Measuring Where You Are

Several metrics have been developed to quantitatively measure the maturity level of your project management processes. I have developed one such metric that consists of more than 800 yes or no questions. (The interested reader should consult me at [email protected] for details on this proprietary product.) These questions cover all five maturity levels for all project management processes identified by PMI in their Project Management Body of Knowledge (PMBOK). Figure 13-6 shows the results of a recent assessment for one of my clients. The data on each of the processes have been aggregated to the Knowledge Area level.

Figure 13-6: Maturity-level data for nine Knowledge Areas of PMBOK

This one graphic conveys a lot of information about this organization's project management maturity levels. First of all, the dashed line shows the maturity level of each knowledge area as documented in the organization's project management methodology. The box-and-whisker plots are maturity-level data reflecting how project management was practiced in several projects that were reviewed in the same quarter. A box-and-whisker plot is a summarized view of the data points for each project on a single Knowledge Area. Each box displays the middle 50 percent of the data. The endpoints of the whiskers denote the extreme data points. The color coding denotes the status of the Knowledge Area. A gray box indicates a process whose practice is significantly below the maturity level of the baseline process. In fact, 75 percent of the data points fall below the process maturity level. A white box indicates a process whose practice is significantly above the maturity level of the baseline process — 75 percent of the data points fall above the process maturity level. For example, take a look at the Scope Management Knowledge Area. The projects that were reviewed demonstrate a maturity-level range from a low of 1.2 to a high of 4.1. The middle half of the data points range from 1.8 to 2.9. The Scope Management Knowledge Area was assessed at a maturity level of 3.5.

Any maturity level below target or above target indicates an area that needs further investigation. The investigation should look for solutions to the less-than-nominal maturity and take the necessary corrective steps to raise the level of maturity of that Knowledge Area. In cases where the Knowledge Area is found to be performing above a nominal level, the investigation should try to reveal the reasons for that exemplary performance and for ways to share their findings (a.k.a. best practices) with other project teams.

In determining where the organization is with respect to project management, there are two threads of investigation. They are as follows:

• The first is the organizational environment in which the PSO will function. This involves assessing the opinions of the managers whose business units will be impacted. Oftentimes this can be done with face-to-face interviews of key managers.
• The second is an attempt to assess the current relationship between project managers and the clients they serve. In this case, the clients will be internal business units and external customers who buy their products.

An assessment tool I developed at Enterprise Information Insights, Inc., has been quite successful in practice: the Project Manager Competency Assessment (PMCA). It is an assessment of a project manager's project management competencies. (Contact me at [email protected] for information about how to acquire the tool.) Figure 13-7 shows an example of a PMCA report.

This PMCA reports findings in four major areas (business competency, personal competency, interpersonal competency, and management competency) as they relate to the individual's project management behaviors. A total of 18 competencies are spread across these four areas. Each one uses a box-and-whisker plot to summarize the opinions of the assessors. In this case, there were eight assessors. The endpoints of the box-and-whisker plots denote the extreme data points. The hollow rectangle is the middle half of the data. The small filled rectangle is the average of all assessors. The bolded vertical line is the individual's self-assessment. In Figure 13-7, the individual has a higher self-assessment of herself than do the managers who provided the competency data. This is especially evident in business awareness, business partnership, initiative, conceptual thinking, resourceful use of influence, and motivating others. This person should be advised to take a close look at how she sees herself relative to how others see her. This self-inflated phenomenon is not unusual. I have seen it time and time again in many of these assessments. People are simply not aware of how they affect others. As a group, this project manager's interpersonal competencies are held in high regard by her fellow workers. However, her personal competencies — particularly in the areas of initiative, conceptual thinking, and self-confidence — may be problematic.

Figure 13-7: An example project manager competency assessment

If either of these two assessments — the maturity level of your project management processes or the project manager competency assessment — uncovers problems, an intervention may be needed prior to any further PSO planning. For the purposes of this exercise, the assessments have shown that the organization is ready to move forward and strongly supports the creation of a full-service PSO.

The next step is to take a look at the existing methodology. There are two areas of investigation, as described here:

• The first is to assess the maturity level of the project management processes that are in place. This can be done by using commercially available tools, such as the Project Management Maturity Assessment (PMMA).
• The second area of investigation is to assess how project teams are using that methodology. Again, there are commercially available tools for this assessment, such as the Project Management Competency Assessment (PMCA).

For this example, assume the assessments show that the organization is at Level 1 maturity both in terms of project management processes and the practice of those processes.

Establishing Where You Want to Go

The future of the organization in the example seems to rest on its ability to restore market share. As expressed in the POS, Sal has as a long-term goal the achievement of Level 5 maturity in the PSO. His strategy will be to achieve that in phases, with each phase providing business value to the organization. The PSO is expected to be a full-service PSO. Its mission, functions, and organization are given in Table 13-1.

Table 13-1: Example PSO Mission, Functions, and Organization

The long-term goal of the PSO is to ensure project success. It should be obvious that goal means the attainment of at least Level 3 maturity. Without a documented process in place and in use by all teams, it is unlikely that there will be any measurable increase in the rate of project success.

However, casually stating that Level 4 maturity is the goal of the PSO is not appropriate. That is clearly a business decision. Attaining Level 4 maturity is a big step. It is very costly in terms of the extent of change in the organization. I would liken that change to the evolution of the enterprise to a projectized organizational structure. To move from Level 4 to Level 5 is a matter of implementing a continuous quality-improvement process within the PSO. Efforts to reach maturity Levels 4 and 5 can often be done in parallel. That is far less traumatic and usually involves not much more than establishing a solid project review process and making a concerted effort to capture and implement best practices from the organization's projects, as well as projects external to the organization.

Refer back for a moment to the data in Figure 13-6 and you'll see that, because the middle half of the data points all fall below the average of 3.5, Scope Management needs some improvement. Such an area is where a continuous quality-improvement effort would focus. The results of a continuous quality improvement effort in Scope Management might look something like the hypothetical data displayed in Figure 13-8. Note that not only has the process baseline maturity level improved from 3.5 to 4.1 during the period from 3/2008 to 12/2008, but the mid-range of the maturity level of the practice has moved from (1.8–2.9) to (3.9–4.3). The maturity level of the practice of Scope Management has increased significantly, and its range has decreased. This is a marked improvement! If this organization had set as its goal to increase the Scope Management maturity level of its process and its practice to 4.0, it would have achieved that goal.

Figure 13-8: Continuous quality improvement of Scope Management

Establishing How You Will Get There

It goes without saying that the lower your current project management maturity level is, the more challenging it will be to move to Level 3 or higher. Level 3 is where the PSO can really begin to make an impact on the practice of project management. It is at this level that the organization has fully bought into project management. Teams must use it, and the PSO is monitoring that usage. Best practices are identified through project reviews and folded back into the methodology. All signs are positive. Figure 13-9 gives a brief description of what actions should be taken to move from one level to the next.

Figure 13-9: How to move to the next maturity level

Sal's plan consists of four milestone events. Each milestone event signifies the attainment of the next level of maturity. The first milestone event is complete when the organization has reached Maturity Level 2 in the PSO. Milestone events Two, Three, and Four are similarly defined. Within each phase are a number of deliverables that add business value. These deliverables have been prioritized to add business value as soon as possible. Figure 13-10 describes the high-level plan through all four phases.

Figure 13-10: PSO plan overview