PMI chapter meeting (v4)

Thank you for inviting me to your Chapter meeting tonight. I'm speaking tomorrow at the Symposium on two topics – Establishing the Performance Measurement Baseline and the Immutable Principles of Project Management.

Both of these topics are critical to increasing the probability of success for your project.

Both these topics are founded on a set of principles that have emerged over the past decade in the aerospace and defense business and are now moving into commercial project management processes.

PMI Fort Worth, Chapter Meeting, 15 July, 2010

Copyright ® 2010, Lewis & Fowler, All Rights Reserved

1/18

There are four outcomes for this talk.

1. I’m going to suggest there are gaps in the understanding of the elements of a project management process.

Not that our current PMBOK® based processes are in error, but the units of measure of progress, DONE, effectiveness and performance are missing.

1. That connecting the dots between cost, schedule, and Technical Performance Measures are needed to improve the probability of success.

2. Making these connections lives in the discipline of Systems Engineering.

3. Once these connections have been made, we need to realize that all the programmatic elements are random variables, and we need to act accordingly.



2/18

We’re all project managers or have some relation to project management.

What’s the core problems we’ve seen in the past and will likely see in the future around project management.

Here’s a popular list I’ve encountered over the years.

You’re list many have some of these or even better ones.

No matter what the list is, any project management framework must address them head on if you’re going to have a chance to end successfully.

I’m going to show you five principles of project management that have served us well over the years.

I’m going to suggest these principles are immutable. That is they are the same for every project management domain and context in that domain.

From mega projects in construction and defense to small agile software development projects with the customer in the same room.

Immutable = not subject or susceptible to change or variation in form or quality or nature.



3/18

So how can we put these principles in practice?

The anchor to the practices that are guided by the principles is to focus on the Deliverables.

All other elements of the project are secondary or possibly unimportant to the deliverables.

This paradigm may appear different than the process groups and knowledge areas of PMBOK®.

These PMBOK® elements are certainly in support of this deliverables view, but it may not be explicitly stated in a way we can “connect the dots.”

When we leave tonight I’m going to suggest you’ll have a different paradigm when you look at PMBOK®

One focused on “what does DONE look like.”

How to measure DONE in units meaningful to the buyer.



4/18

With this notion in mind, we can define what DONE looks like.

It is defined when we answer these five (5) questions.

These questions are core to every project. They the are source of processes that define the immutable principles.

They must be answered for success.

When they are not asked or not answered the probability of success is lowered, many times lowered to the point that the project goes off track and possibly fails.

We’ll see in the coming slides how these questions and their answers can be your means to increasing the probability of success.



5/18

The five irreducible principles of project management that answer the previous questions are:

1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future, days or weeks from now.

2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.

3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.

4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.

5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.



6/18

The question “where are we going” must be answered in ways meaningful to the buyer.

The answer can be in the form of a needed capability.

This answers the question, “What capabilities to we need to posses to call the project DONE?”

Or what are the requirements that need to be fulfilled to call the project DONE?

The answer to this question is a PLAN.

The PLAN says where we are going. It does not say how we’re going to get there, just where.

One critical missing element for many troubled projects is the answer to the question WHY. WHY are we doing this project?

The PLAN comes after we answer the question WHY. This answer comes from the business strategy or mission strategy of the project and is outside the context of the five (5) immutable processes.



7/18

HOW to get there is described in the Schedule.

Let’s walk through an example.

Let’s pretend we want to go on a hike. A nice hike to the saddle just to the right of the peak above this lake. That saddle is Pawnee Pass. I

t’s just west of Boulder Colorado, and a bit south of Rocky Mountain National Park.

We’d like to go to Pawnee Pass in a single day – there and back. Not get too wet if it rains. Not be too hungry. And have a good time along the way with our hiking group.

The PLAN is to summit in a day and return safely. The SCHEDULE is the steps needed to actually reach the summit and return.

This SCHEDULE includes all the work effort needed to summit, the order in which we’d perform these work element, the dependencies between the elements, any resources we’ll need for success, and both schedule and cost margins.


8/18PMI Fort Worth, Chapter Meeting, 15 July, 2010

With the destination in mind and schedule of all the activities needed to reach our destination, do we know if we have everything we need to get there?

This answer includes all the resources, technology, processes, and other items that will enable success.

These dependencies must be identified in the Master Schedule.

For example in NASA programs –Government Furnished Equipment is common.

Same for external dependencies in Enterprise IT projects.

These dependencies have their own schedules and the credibility of those schedules must be assessed in the same way we are going to do in the next steps.

This “all in” System of Systems approach is needed to collect “all” the elements of the project PLAN and SCHEDULE.



9/18

There are always impediments to progress.

It’s just part of a project. It’s actually part of everything we do as project managers.

But do we know them? Can we name them and what their impact might be on the project?

Do we have some way of “handling” these impediments – the risks to the project.

There are of course the named ways:

1.Risk avoidance eliminates the sources of high risk and replaces them with a lower-risk solution.

2.Risk transfer is the reallocation of risk from one part of the system to another.

3.Risk control manages the risk in a manner that reduces the probability / likelihood of its occurrence and / or minimizes the risk's effect on the program.

4.Risk assumption is the acknowledgment of the existence of a particular risk situation and a conscious decision to accept the associated level of risk without engaging in any special efforts to control it.



10/18

Here’s where many projects start their path toward the ditch.

Progress can only measured in the assessment of Physical Percent Complete. The percent of the Planned progress.

How far along should we be at this point in the project?

Where are we actually along the path to complete?

What was our planned progress at this point in the project?

The unit of measure for Physical Percent Complete starts with tangible evidentiary Materials brought to the table and shown to project participants.

The passage of time and consumption of resource is never a measure of progress to plan.

This last approach is common in projects that have gone off the rails.

When we are planning and scheduling the project we need to define upfront what these measures of percent complete are. Predefining them.

Agreeing we measure progress with them.

There can be no retroactive assessment of progress to plan. Once defined the measures of physical percent complete are placed “on baseline,” and represent the only assessment of progress.



11/18

If we look back to the beginning of tonight's talk to the 4+1 major activities of Deliverables Based Planning® and connect them with the five (5) immutable principles of managing any project, we have to look for the evidence that we’re following the processes using the principles.

You may have other evidence.

No matter what you have, there has to be artifacts showing that you’ve done the work to answer the 4+1 questions and satisfied the five (5) immutable principles.

One critical concept in any successful project management method is “evidence based” assessment of progress.

Personal opinion, verbal discussion, management statements are not acceptable.

Only tangible evidence of progress to plan is acceptable.



12/18

Each of these pieces of evidence must provide some level of credibility.

One method of measuring this credibility and its tangible value is through a systems engineering paradigm.

This by the way is one of the difficulties agile processes run into.

They mention “value” but don’t have units of measure for that value.

Independent of that, here’s how we do it in the systems engineering world.

MoE’s are defined by the customer.

They are the measures of the capabilities needed to fulfill some mission.

MoP’s are defined by the supplier.

They describe the behaviors needed to fulfill the mission.

The KPP’s are the numbers we’ll assign to the MoP’s.

The Technical Performance Measures (TPM) are the collection of these individual elements.



13/18

All this effort, definitions, processes ,and information has only one goal.

The goal is to describe in a tangibly measureable way what DONE looks like.

This is the only reason for all these processes.

This is the role of the Project Managerand the Project Controls staff.

To define what DONE looks like, manage all the resources toward that description, handle all the risks and impediments to progress.

All of this starts – and ends – with what the customer needs in terms of “capabilities.”



14/18

If we fail to provide credible answers to the five (5) immutable project management processes, then we’re headed in the wrong direction.

We will not be able to measure our progress to plan.

We will have not defined what business or mission capabilities are needed for success.

We won’t know what the requirements are to fulfill these needed capabilities.

We'll have failed to identify and handle the impediments to our progress to plan.

Our only source of success will be HOPE.

Hope that we’ll discover these as we go.

Hope, that the potential impediments to progress won’t come true.

Hope that our customer can articulate what DONE looks like for us along the way.

When Hope is are strategy, we’ve started on the road to failure.



15/18

In closing here’s the next level down for Deliverables Based Planning®.

Each of the four (4) processes shown here – plus the continuous risk management has major sub-processes, which also have sub-sub-processes .

There are 74 processes in all.

I have handouts that cover all these processes, you’re welcome to.



16/18

So with that brief overview of Deliverables Based Planning® and its application to projects in general, are there any questions I can answer in the short time we have left?

My colleague and I will be here for more questions and answers.

Tomorrow the Symposium Work Shops will delve into these topics in greater detail, I look forward to seeing you there.



17/18

Here’s my contact information if you’re unable to attend tomorrow’s work shop or would like more information about these processes.



18/18

Date post:	07-Dec-2014
Category:	Technology
Upload:	glen-alleman
View:	3,509 times
Download:	1 times

PMI chapter meeting (v4)

Technology