Determining When You Need a Project Support Office
,However you slice it, the PSO is established for the sole purpose of improving the processes and practices of project management for the group of projects and project managers over whom it has a stewardship responsibility. The PSO is an investment, and its ROI is measured in terms of cost avoidance. That cost avoidance is a direct result of a significant reduction in project failures for which the PSO is held directly responsible and accountable.
The Standish Group Report
The reasons for project failure have been investigated and reported in detail for several years. One of the most thorough research efforts into the reasons for project failure is the work of the Standish Group. Beginning in 1994 and repeating every two years, they have conducted interviews of 300+ C-level IT executives. The objective of these surveys is to discover and prioritize the reasons why IT projects fail. CHAOS 2010 is their most recent report. According to this study, the top ten reasons why IT projects fail were the following:
- Lack of user input
- Incomplete requirements and specification
- Changing requirements and specification
- Lack of executive support
- Technology incompetence
- Lack of resources
- Unrealistic expectations
- Unclear objectives
- Unrealistic time frames
- New technology
After reviewing the major functions that the PSO provides, you can see that a PSO is uniquely positioned to mitigate each of these 10 reasons for project failure. In fact, it is the only organizational entity that is so positioned. I want to examine each of these reasons and see exactly what the PSO could do to mitigate it.
Lack of User Input
I would have phrased this as “meaningful client involvement.” You have already learned how the importance of meaningful client involvement changes as the project type moves from Linear to Incremental to Iterative to Adaptive to Extreme. The PSO can do the following three things to assure that this involvement is present in every project:
- Provide a client document that describes how their involvement changes over the project landscape and over time for a specific PMLC model.
- For each of the five PMLC models, offer a project manager workshop on how to attain and sustain client involvement over the project landscape.
- Offer client workshops that focus on the client's role and responsibility in projects over the project landscape.
I hope that you are beginning to see the complexity of delivering effective project management. It's interesting that the industry says projects are unique, and that the same project can never occur again under the same set of circumstances. I would argue that the management of each project is also unique. Without some guidance as to how to choose the best-fit management approach, the situation becomes chaotic. If every project is managed differently, there wouldn't be any lessons to learn. But that is not the case. I have given you the rules of the engagement based on a logical and intuitive definition of the project landscape so that you can choose a best-fit PMLC model. In that sense, the process is repeatable because it is based on a set of rules. You are learning to be a chef rather than just a cook. Your pantry is stocked with all of the tools, templates, and processes you need to be an effective project manager. Everything in your pantry will have been vetted by and is supported by the PSO.
Despite the complexity of choosing best-fit models, the project landscape I have defined is very simple. There are four quadrants (TPM, APM, xPM, and MPx), and there are five PMLC model types (Linear, Incremental, Iterative, Adaptive, and Extreme) that span these four quadrants. They form an ordered set with respect to solution clarity, and within each model type, any number of specific PMLC models might be used for a specific project (for example, Standard Waterfall, Rapid Development Waterfall, Dynamic Systems Development Method (DSDM), Scrum, Adaptive Project Framework (APF), and several others).
Incomplete Requirements and Specification
All of the simple projects have been done. What is left are projects that must be done in the face of complexity and uncertainty and that means requirements that can no longer be completely defined and documented at the beginning of the project. Some of those requirements simply cannot be known at the beginning of the project. The PSO cannot do much to change the reality; all it can be asked to do is mitigate some of the operational problems associated with gathering requirements.
First, the PSO can build an arsenal of requirements gathering tools and train people to utilize them effectively. Even though it is assumed the requirements will be incomplete, the gathering effort needs to be as comprehensive as possible so that the requirements will be as complete as possible. Second, the PSO can review and improve all of the project management approaches to be best prepared to deal with incomplete requirements. That means to refine the processes of learning and discovery in the agile and extreme project management landscape.
Changing Requirements and Specification
As the PSO designs and implements the project management processes, attention needs to be paid to the fact that change is a way of life in the complex project world. The project management processes should be built to respond to what is known to be part of the solution and to be flexible in accommodating change without the attendant loss of integrity of the plan. That means avoiding wasting time on what might be part of the solution and spending the planning effort on what is known to be part of the solution. Building a project management methodology based on the future is not a good expenditure of project resources.
Lack of Executive Support
Executive support is always a necessity if the project is to be successful. The PSO needs to represent the project in a favorable light up into the organization and let project managers focus their efforts on the project.
Technology Incompetence
The PSO will need to have a good sense of the inventory of skills and competencies among all potential team members. That will enable them to advise and suggest technical approaches to the project. Maybe the latest and greatest technology may not be the best business approach, and the PSO would be in the best position to make that assessment.
Lack of Resources
The PSO should be the keeper of the skills and competencies inventory and should play an integral role in assigning staff to projects. By having management responsibility for the career and professional development plans of project managers and other project support staff, the PSO will be able to make recommendations in line with staff development needs.
Here is where the PSO can shine either indirectly through training or directly through coaching and mentoring project managers and their team members. Training can be offered at the PMLC model level, Knowledge Area level, or process level. Introductory, intermediate, and advanced courses are commonplace. Delivery systems range from books to instructor-led education to computer-based education, as well as in a variety of blended models.
Unrealistic Expectations
The world of complex projects has brought on a great deal of uncertainty. We are dealing with projects where the deliverables may not produce the expected business value that justified doing the project in the first place. The cause and effect relationships are clouded or nonexistent. The PSO needs to nurture a project culture that says we are going to do the very best we can within the time, cost, and resource constraints to deliver the most business value possible.
Unclear Objectives
The agile processes designed and implemented by the PSO should have built-in protections against this situation arising. If an objective is unclear, remove it from the project plan until the process of learning and discovery in agile iterations clarifies the objective. At that point put it back in the project plan.
Unrealistic Time Frames
The PSO is a respected and impartial player in the project life cycle. When the occasion calls for it, the PSO needs to be a support of the project manager and the project plan. If unrealistic time frames are being pushed on the project manager, the PSO needs to speak up in defense of the project manager.
New Technology
The PSO should take the position that all new technologies need to be vetted and the personnel prepared to fully utilize the technology before the technologies are incorporated into projects. The downside is that project risk increases. It is the PSO that needs to put a program in place to accept new technologies and to make senior management aware of the risks.
Spotting Symptoms That You Need a PSO
The following symptoms provide you with clues that you might need a PSO:
Project failure rates are too high — This symptom is all too familiar to me. Reports show project failure rates of 65 to 70 percent and higher, regardless of how failure is defined. That is simply unacceptable. Many of the reasons for these high numbers are probably found in the list of the top-10 reasons for project failure from the Standish Group Chaos 2010 report. Reasons that relate to the project management approach that was used — namely, user involvement, clear business objectives, minimized scope, standard infrastructure, and formal methodology — can be addressed by choosing the correct approach (TPM, APF, xPM, or MPx). It is my contention that by choosing the appropriate approach, the organization can make a serious impact on failure rates.
Training is not producing results — I am not aware of any systematic study of the root causes of training ineffectiveness. Possible causes are inappropriate materials, inappropriate delivery, no follow-through on behavioral changes after training, or no testing of skill acquisition. Training needs to be taken seriously by those who attend the training. Attendees must be held accountable for applying what they have learned, and there must be ways to measure that application. I am amazed at how many training professionals and curriculum designers are not familiar with Kirkpatrick's model. The interested reader can consult Donald L. Kirkpatrick's Evaluating Training Programs, Second Edition (Berrett-Koehler, 1998). In my experience, project reviews that are held at various milestones in the life of the project are excellent points at which to validate the application of training. If clear evidence isn't shown that training has been applied, some corrective action is certainly called for.
HR project staff planning isn't effective — Organizations need to do a better job of defining the inventory of project staff skills and the demand for those skills by projects. A concerted effort is needed to match the supply to the demand and to make better staffing assignments to projects. The PSO is the best place for this responsibility to be carried out. Without question, the Graham-Englund Selection Model should be used (see Chapter 14).
Best practices are not leveraged — The PSO is the best place to collect and distribute best practices. Project status meetings and project reviews are the places to identify best practices. The PSO, through some form of bulletin board service or direct distribution to the project managers, is the best place to distribute that information. In the absence of that service, the collection and distribution of best practices isn't going to happen.
There is little or no control over the project portfolio — Many senior managers don't know the number of projects that are active, nor do they fully understand the resource availability. Unknowingly, they overcommit. They haven't made any effort to find out about or be selective of those projects that are active. That behavior has to change if there is any hope of managing the project work in the organization. The PSO is the clear choice for stewardship of that portfolio. At the least, it can be the unit that assembles project performance data and distributes it to the decision makers for their review and action.
No consistency in project reporting — Without a centralized unit responsible for the reporting process, consistent and useful reporting isn't going to happen. Again, the PSO is the clear choice to establish the reporting structure and assist in its use.
There are too many resource scheduling conflicts — Most organizations operate with some form of matrix structure. Project resources are assigned from their functional unit at the discretion of that unit's manager. In such situations, resource conflicts are unavoidable. The individuals who are assigned to projects are torn between doing work for their functional unit and doing work for the project to which they have been assigned. If you're a seasoned project manager, most likely none of this is news to you. One solution to resource scheduling conflicts is to use the PSO as the filter through which project staffing requests and staffing decisions are made. The major benefit of this approach is that it takes the project manager off the hot seat and puts the responsibility in the PSO, where it can be more equitably discharged.
There is a gap between process and practice — This is a major problem area for many organizations. They may have a well-documented process in place, but unless they have an oversight-and-compliance process in place as well, they are at the mercy of the project manager to use or not use the process. The PSO is the only unit that can close this gap. The PSO puts the process in place with the help of those who will be held accountable for its use. The PSO, through project performance reviews, can determine the extent of the gap and put remedial steps in place to close it.
Figure 13-2 shows a self-assessment that you can use to help determine if you need a PSO.
Figure 13-2: PSO readiness assessment
