POTI: A Model for Programme Blueprints

The OGC’s Managing Successful Programmes (MSP) framework uses a categorisation process to identify areas of scope that should be considered by the programme Blueprint.

A Blueprint is a detailed vision for the organisation, covering what the organisation will look like when all the projects are completed, the programme is wound up, and the business transformation is done.  Typically, you would only write a Blueprint at programme level, so project managers will ‘inherit’ a Blueprint from their programme manager.  If you are leading a project as part of a bigger initiative being managed as a programme, ask to see the Blueprint if you haven’t already.  It will help set your project in the wider context of what the business is trying to achieve.

In particular, Blueprints use the POTI model as a way to define the scope of what is going to change once all the projects in the programme are complete.  POTI sets out the scope of the programme at a high level.

POTI stands for Processes, Organisation, Technology and Information.  These four areas make up a comprehensive view of all the elements that form the programme scope.

Read more »

5 steps to a project manager competency framework (part 1)

Two weeks ago I attended a webinar hosted by ESI on the role of competency frameworks in developing project managers and how you can build your own competency model for your company.  You can read my post about what competencies are and why having a framework is a good idea here.  In this post I am going to explain J. LeRoy Ward’s five steps to setting up a competency framework in your organisation, based on my notes from that webinar.

He presented a five-step approach:

1. Define the categories of projects that the organisation is working on.
2. Identify competencies for project managers.
3. Assess your project managers against these competencies.
4. Identify what you need to do to get people to where they need to be.
5. Execute well, monitor how it is going and measure the results.

Let’s take each of those in turn.  Today I’ll be looking at the first two of those steps, and next week I’ll cover the final three.  That should give you time to get started on implementing these first steps!
Read more »

Risk Management Planning

I’ve offered – and provided already to many requestors – my template for a Risk Management Plan. It’s not groundbreaking or even earth-shattering, but there are just some key concepts to include and critical areas to ensure are covered. It’s not absolutely necessary to even have a formalized plan, unless you’re working on a critical government project and it’s required or you’re working with a project staff or customer that is missing the point of managing risk…then it may be necessary to formalize it for them.

I recently ran across another outline for a risk management plan and I am sharing it below. If you want my copy/template as well, just send me a note and I’ll email it to you – mine comes as a prepared document and you can just insert your info.

Risk Management Plan

Purpose

The risk management plan lays down the groundwork for how risk management will be carried out in a project. It serves as guidance for the risk process, its thresholds, and its formats, defining the roles and responsibilities of stakeholders in risk management. It is notable that the risk management plan is not a listing of specific risks and is not used to establish the particular strategies for risks, once they are identified.

Application

The risk management plan is shared with project stakeholders to clarify their roles and responsibilities in the risk management process and to identify when specific potential risks are truly of concern to the organization. It also outlines the risk budgeting process, detailing how and when risk contingency funds may be allocated and applied.

Content

The risk management plan consists of basic information about how risk management will be conducted during the project. It does not address specific behaviors associated with specific risks, but instead forms a framework for the rest of the risk management process.

1.0 Risk Process

Risk process may be as simple as two steps (e.g., assessment and response) or as complex as six or seven steps (e.g., planning, identification, qualification, quantification, response development, and response control). The process steps should include clarification on how each of the processes will be carried out and the level of depth of information to be provided for each.

2.0 Risk Responsibilities

Just as the buyer and seller in project environments have different responsibilities for deliverables, so do they have different responsibilities for risks. Those responsibilities should be outlined here. Responsibilities may include information on who will identify risks, as well as who should evaluate them and develop strategies for those that are of the greatest significance.

3.0 Risk Thresholds

Thresholds represent personal and organizational tolerance for risk. They are the definitions of tolerance in terms of budget, schedule, requirements, and other sensitive cultural issues (e.g., politics, media exposure). They are normally expressed as ceilings beyond which the project should not proceed, or as notification points for upper echelons of management.

4.0 Risk Finances

This element of the risk management plan may address both funds set aside for risks within the project (contingency reserve) and funds set aside within management control for risks outside the project’s purview (management reserve). In both cases, this component of the plan details how and when the project team may draw down funds from those reserve accounts. Risk finances may also provide detail on how the amounts for the reserve accounts will be established.

5.0 Risk Evaluation

Because evaluation protocols vary from project to project, the risk management plan should include some detail on how risks will be scored and termed. Particularly for risk qualification, there should be some definition of terms for both the probability of a risk’s occurrence and for the impact should it come to pass. Many projects employ the high–medium—low (H-M-L) scheme for both impact and probability. The risk management plan should define each of those terms.

6.0 Process Timing

High-risk projects may require frequent risk reevaluation. Projects with lower risk may not require such frequency. The risk management plan should include detail on the frequency of risk identification, assessment, and response development, as well as the appropriate application of any tracking processes or documentation.

Dealing with Changing Specifications

I’ve already written a lot about customer indecision, change orders, and the customer’s inability to truly know what it is they want. And I’m sure I’ll write considerably more on the topic as it is one of the most critical issues we deal with and our ability to manage these situations is often directly tied to customer satisfaction. It’s our job as project managers to drag that out of them and to anticipate what some of their unstated needs are along the way.

Even though I’ve shared many of my own thoughts on this topic, I still find that it’s interesting to present other view points and text giving different angles on the same popular topics. Most of the text from this article comes from the book “Integrated Project Management” by Earl Hall and Juliane Johnson. This is subsection of their chapter on project change and deals with the how to handle customer indecision and changing requirements. It’s a little dry, and I think it underestimates the amount of changes that PMs must deal with in the course of an implementation, but fundamentally it’s pretty sound.

Management of Customer Indecisions

A project manager must begin working on a project with the expectation that the customer will request change at least once, perhaps several times, regarding the project outcome(s). The project manager must be prepared for the possibility that a task leader or an external subject matter expert will discover and present a new or better way to perform tasks after the completion of the task list. If the proposed change occurs during the project planning period, it can be accommodated by backing up the planning process and replanning with the change(s) in mind. Before this is done, however, the project manager must create a new, revised specification statement and clear it with the customer, appropriate subject matter experts, and key team members. The project must always be working toward one clear goal, and all prior specifications must be destroyed.

Change requests that arise during the project’s planning process are not hard to deal with if they are few and infrequent. Changes do interrupt the planning process and cost time and money, but aside from that and the frustrations the team experiences, they can be handled effectively. When a customer is uncertain about exactly what he or she wants and frequently changes his or her mind this must be dealt with as a special case.

Customers often want a project to begin before they have decided on a precise outcome. They may not expect to be able to precisely define what they want for some time. However, integrated project management (IPM) is based on the premise that a precise outcome statement—specification—must be decided upon before planning can begin. Both experience and logic support this proposition. Nevertheless, when thinking is at the scope level, it is often reasonable for the customer to be uncertain of the precise outcomes. Can an integrated project be started under these conditions? The answer is yes. A preliminary specification can be created. A project manager begins the project by leading the creation of this specification.

As the project manager helps migrate the project from scope to specification, he or she aims for a precise specification that will capture the current best estimates of what the outcome should be. This specification will be used in the initial planning and execution of the project. At the same time, the project manager puts in place a project specification change procedure to deal efficiently with the outcome changes the customer may desire later on.

Experience has proven that this approach is more efficient than simply starting in a general direction, then adjusting, redirecting, and reorganizing as an outcome concept emerges. It must be understood that in IPM, replanning will be a major event and will not take place piecemeal. It will not occur often during the life of the project. Small and frequent modifications of the specification must be prevented because such practices kill projects.

The rationale for insisting on the creation of a specification before starting project planning derives from the processes that must take place when the change in a project is executed. Before a project can be changed, there must be something to change. The effort to get the customer to agree on what the “current” best estimate of what the outcome should be is defined within the statement of work. Sometimes, customers do not decide on exactly what they want until they see what is involved in providing them with what they think they want. Sometimes, the general dimensions of an outcome are identified, but the exact characteristics of the outcome must wait on “research in progress.” The customer and the project manager agree that a precise outcome definition within the general framework of the expected outcome will enable the project manager to begin the project planning. It also will provide for the startup of project execution. The initial plan is expected to be relevant when the revised outcome statement is decided upon.

Creation of the initial project plan gives the project team something useful to do now, and it creates a good plan for the team to examine and change when a specification revision is presented. This fits in with the fundamental process of project change. When a change is proposed, the original project plan—the Gantt chart and the resource table—is the necessary reference for the considerations of what can be done and what this will cost.

A Discussion on Project Success

How do we define project success? For me, the analysis is usually broken down into these four categories:

• Customer satisfaction
• End product usability
• Budget management
• Schedule management

Gary Heerkens’s brief case book entitled “Project Management” takes a cut at the definition of success. I’ve included a slightly modified version of this section below.

Defining Project Success

The definition of project success is obviously critical. After all, that’s how you’ll be judged as a project manager. Unfortunately, there are almost as many definitions of project success as there are project management professionals. To add to the confusion, every organization has its own view of what matters in project outcomes.

So, instead of trying to focus on one definition, I’d like to offer a framework of thought on success. I’ve found it valuable in the many discussions I’ve had over the years. If you consider the various ways that projects could be deemed successful, you come to realize that project success exists on four levels, each with a unique perspective and set of metrics. And despite the specific values used to quantify success or failure, the principle remains constant. Following are the four levels of success that I use:

Level I—Meeting Project Targets

Did the project meet the original targets of cost, schedule, quality, and functionality? Although it’s certainly admirable to beat these targets, my concept of success is tied to whether the project manager did what was expected. In other words, maximum success is zero variance between project targets and results. There are at least two reasons why I embrace this interpretation. First, it supports the organization’s need for certainty. Second, I believe that project managers who chronically beat targets are suspect, at best.

Level II—Project Efficiency

How well was the project managed? This is a metric for the process. If the project meets its targets, but the customer groups, project team, or others were adversely affected by the project experience, the project will probably not be perceived as successful. Project efficiency can be evaluated through the use of criteria such as the following:

• The degree of disruption to the client’s operation
• How effectively resources were applied
• The amount of growth and development of project team members
• How effectively conflict was managed
• The cost of the project management function

Level III—Customer or User Utility

To what extent did the project fulfill its mission of solving a problem, exploiting an opportunity, or otherwise satisfying a need? If the project did not satisfy the true need, the project may be perceived as a failure.

Here are some questions to help assess Level III success:

• Was the original problem actually solved?
• Was there a verifiable increase in sales, income, or profit?
• Did we save as much money as expected?
• Is the customer actually using the product as intended?

Level IV—Organizational Improvement

Did the organization learn from the project? Is that knowledge going to improve the chances that future projects will succeed at each of the three levels described above? High-performing organizations will learn from their failures—and their successes—and use that knowledge to improve their success rate in over time. This level assumes a long-term perspective and measures organizational learning and a resultant increase in project successes. The primary tools for organizational improvement are the maintenance of accurate historical records and the widespread use of lessons learned.

Feedback

What is your definition of project success? What is your organization’s definition…or your PMO’s definition? Some organizations focus on customer satisfaction. Others focus mainly on budget or schedule. I’d really like to hear your feedback and thoughts.