The PM Simplicity Method

A simple and effective approach to managing projects

DRAFT DOCUMENT NOT FOR DISTRIBUTION

 pmsimplicity.COM

Let’s start at the beginning.

The definition of a project, taken straight out of the PMBOK

is:

Project. A temporary endeavor undertaken to create a unique

product, service, or result.

Let’s think about that for a minute. Many organizations

create projects but they miss the ‘temporary’ part. Depending on

the type of project, you may wind up with some “thing” be it a

computer program, a class, or an offering of some type. Once this

‘thing’ is produced, the project is completed. The ongoing thing

or deliverable is now an operations activity. That means that all

of the resources associated with the project may need to be

redeployed and the operations activity support requirements [who

answers the phone, who creates the documents, who provides the

offering] needs to be reevaluated to ensure the right fit for

ongoing operations.

Now that we’ve got a clear understanding of what a project is,

let’s talk a bit about the project plan.

The definition of a project management plan, again from the

DRAFT DOCUMENT NOT FOR DISTRIBUTION

PMBOK is:

Project Management Plan [Output/Input]. A formal, approved

document that defines how the projected is executed, monitored and

controlled. It may be summary or detailed and

may be composed of one or more subsidiary management plans and

other planning documents.

The project plan is the sum of all documents related to the

project. This includes the project schedule, change management

plan, communication plan and any other deliverables that you as

the project manager should be considering. Basically, the project

management plan is the folder that contains all of the

documentation related to the project.

Unfortunately, you will often find people incorrectly

referring to the project plan when they really mean to say the

project schedule. As long as you’re clear on what goes into the

project plan, you’ll always have the project schedule as it is one

of the more common deliverables that go into a project plan.

Let’s take a minute to talk about project management itself.

The definition of project management is:

1.3 PROJECT MANAGEMENT

DRAFT DOCUMENT NOT FOR DISTRIBUTION

 Project management is the application of knowledge, skills,

tools, and techniques to project activities to meet project

requirements. Project management is accomplished through the use

of the processes such as: initiating, planning, executing,

controlling, and closing. The project team manages the work of the

projects, and the work typically involves: ■ Competing demands

for: scope, time, cost, risk, and quality. ■ Stakeholders with

differing needs and expectations.

Reading the above definition should make it clear that the

primary activity of a project manager is communication. All too

often project managers think their job is to produce stacks of

documents showing that thought and consideration has gone into a

project. Unfortunately, they work in a vacuum and only solicit

input when necessary to complete the document.

The correct way to think about this is that the paper is proof

that the face to face communication and negotiations have occurred

to stakeholders’ satisfaction. In other words, the documentation

is the output of the activities and not the activity itself.

DRAFT DOCUMENT NOT FOR DISTRIBUTION

 5.1 INITIATION

Initiationis the process of formally authorizing a new project

or that an existing

project should continue into its next phase(see Section 2.1

for a more detailed

discussion of project phases). This formal initiationlinks the

project to the

ongoing work of the performing organization. In some

organizations, a project is

not formally initiated until after completion of a needs

assessment, a feasibility

study, a preliminary plan, or some other equivalent form of

analysis that was itself

separately initiated. Some types of projects, especially

internal service projects and

new product development projects, are initiated informally,

and some limited

amount of work is done to secure the approvals needed for

formal initiation. Proj-

ects are typically authorized as a result of one or more of

DRAFT DOCUMENT NOT FOR DISTRIBUTION

the following:

■ A market demand (e.g., a car company authorizes a project to

build more fuel-

efficient cars in response to gasoline shortages).

■ A business need (e.g., a training company authorizes a

project to create a new

course to increase its revenues).

■ A customer request (e.g., an electric utility authorizes a

project to build a new

substation to serve a new industrial park).

■ A technological advance (e.g., an electronics firm

authorizes a new project to

develop a video game player after advances in computer

memory).

■ A legal requirement (e.g., a paint manufacturer authorizes a

project to estab-

lish guidelines for the handling of toxic materials).

■ A social need (e.g., a nongovernmental organization in a

developing country

authorizes a project to provide potable water systems,

latrines, and sanitation

education to low-income communities suffering from high rates

DRAFT DOCUMENT NOT FOR DISTRIBUTION

of cholera).

These stimuli may also be called problems, opportunities, or

business require-

ments. The central theme of all these terms is that management

generally must

make a decision about how to respond.

.1

.2

.3

.4

Product description

Strategic plan

Project selection criteria

Historical information

.1

.2Project selection methodsExpert judgment .1.2

.3

.4

Project charter

Project manager

identified/assigned

Constraints

Assumptions

DRAFT DOCUMENT NOT FOR DISTRIBUTION

 Inputs Tools & Techniques Outputs

The project charter is an important document which represents

the first step in making a concept into a reality. This document

describes the business drivers that are creating a need for the

project. It describes the current state [things as they are] and

the ideal state [things as they are desired] of the organization

and it’s processes after the project has been delivered. It

should also capture the financial benefits and/or justification

for the project [ROI]

The charter, once written and signed off, can be the primary

method by which the project gets its funding. What’s that you

say? “Funding….? This project has no funding?

Unless all of your resources have no other commitments, then a

lack of funding is sure to present significant obstacles to

delivering successfully. Without funding, the necessary resources

will have to be negotiated and re-negotiated away from other

commitments and conflicting priorities. This is not to say that

it cannot be done but the criticality of the project should be

clarified and any necessary resources should reflect the agreed

DRAFT DOCUMENT NOT FOR DISTRIBUTION

upon importance of the project.

An important note to consider is that at the initiation phase,

the project is very loosely being defined and very often at this

point in the project, a project manager has not been identified.

The natural evolution of the project is that someone, often a

business analyst documents the projects basic parameters and after

this has been agreed upon, a project manager is named to make the

project into a reality.

DRAFT DOCUMENT NOT FOR DISTRIBUTION

 Crafting the vision

Once given authority over the project, the project manager

needs to ensure that all voices related to the vision are heard

and accounted for. This inclusive approach of seeking of input is

important to ensure that any downstream decision making is done

with the best information available. This also means that

everyone who has a stake in the project, everyone who will be

impacted by the project gets heard. Perhaps you’re wondering “Do

DRAFT DOCUMENT NOT FOR DISTRIBUTION

I really need to interview the gals in the typing pool about my

project? They’re just going to do what they’re told anyway…”

Consider it a shrewd investment in a number of ways. First

you’ll get their perspective and they are often closer to the data

than you or the executive stakeholders. Another benefit is that

by taking their input into consideration, you’ll increase the

likelihood that they will support the solution. We’ve all seen

the opposite. The projects that get rolled out to an organization

where employees are grumbling about what a failure the project is

and how ridiculous the solution is. By seeking input from all

who are impacted, you’ll help to avoid this unnecessary friction.

Note that while all the voices are heard, no commitments

should be made at this stage. You are simply trying to understand

the problem and ensure that any and all subject matter experts and

stakeholders are identified sooner rather than later. There are

few things worse than being well into the project and discovering

a group of people who absolutely need to be involved with the

project but have not been engaged at all. You’ll have to work

overtime to regain their trust and confidence in the project and

your ability to lead it.

Establish the parameters

During project initiation, there will be a lot of talk of the

DRAFT DOCUMENT NOT FOR DISTRIBUTION

possible. It is all good to have people lending their insights

and visions of the what could be. It is crucial that as project

manager you show that while there are many possibilities there are

only a small set of suitable approaches that will be successful.

In other words, while there may be a buffet line of possibilities,

the reality of overeating should prevent unnecessary requests from

being included in the project scope.

Contrary to the fantasy that all PMs are omnipotent and

omniscient, the reality is that very often the initiation phase of

a project is often completed without a project managers.

In a textbook scenario, the key stakeholder [usually the one

with some money to spend] with the assistance of a business

analyst is able to put forth a business case that articulates the

need for the project.

The business analyst is able to ensure that there is no

duplication of effort [similar projects already occurring or

alternative ways of satisfying the requirement without the

project] and craft a cogent argument including a cost/benefit

DRAFT DOCUMENT NOT FOR DISTRIBUTION

analysis that will be used to justify the cost of the project in

anticipation of the expected benefits.

This is the ideal case. Another possible and more likely

scenario is that a key stakeholder in a management meeting says….

‘We need X!, make it so!’ without much thought or analysis in

terms of impact to staffing or impacted groups or departments.

If every action has a reaction, then a project will have

intended and unintended side effects. Without the time spent

doing a project charter and or business case, you will find

yourself in a serpentine trap that occurs so often in software

development that a maxim has sprung up to describe it:

“The less time you spend designing, the more time you spend

coding.” Or in carpenter’s parlance, “measure twice, cut once.”

These are all maxims that try to describe a situation where if

you short change the front-end [now] you will pay more dearly in

the back-end [later].

All this to say if there is no project charter/business case,

do whatever you can to prepare one (regardless of how rudimentary)

and get sign-off. This will force people to accept that though it

takes little effort to request or state the need for a project, it

will take the effort of many [including them!] to move the project

to completion. If folks are unwilling to sign off on your project

charter of business case, how likely are they to spend the time

DRAFT DOCUMENT NOT FOR DISTRIBUTION

working with you in getting the project defined to the sufficient

level of detail to be successful?

The charter need not be a magnum opus. It just needs to

accomplish the following in order to be effective:

-What the problem domain is.

-What the proposed solution entails.

-What alternatives were considered.

-Why it’s cost beneficial to the organization [both short-term

AND long-term] to do the project.

Without this due diligence, you may find yourself managing a

project that:

-Has already been attempted (successfully or not)

-Is currently being done by another department

-Is moot due to impending organizational or legal changes

-Will leave the organization in a less desirable state at

project completion

Obviously, no one wants to create unnecessary work. Nor do

people want to sabotage the efforts of their team. Nonetheless,

the fact remains that without a thorough review of the

implications and alternatives of a project, you put the

organization and your resources at risk for these undesirable

DRAFT DOCUMENT NOT FOR DISTRIBUTION

outcomes.

So to recap, in a texbook example, a business case is prepared

by a business analyst with the input of a key stakeholder or

executive. Once the need for a project is articulated and the

funding secured, the Project Manager is named and given a mandate.

How closely to your world does this description sound? Not

similar? That’s not surprising as the real world has a funny way

of unfolding in ways that are much more complex and interesting

than the textbook cases.

Stakeholder Identification

Key stakeholders on every project include:

■ Project manager--the individual responsible for managing the

project.

■ Customer--the individual or organization that will use the

project’s product.

There may be multiple layers of customers. For example, the

customers for a

new pharmaceutical product may include the doctors who

prescribe it, the

patients who take it, and the insurers who pay for it. In some

DRAFT DOCUMENT NOT FOR DISTRIBUTION

application

areas, customerand userare synonymous, while in others

customer refers to

the entity purchasing the project’s results and users are

those who will directly

use the project’s product.

■ Performing organization--the enterprise whose employees are

most directly

involved in doing the work of the project.

■ Project team members--the group that is performing the work

of the project.

■ Sponsor--the individual or group within or external to the

performing orga-

nizationthat provides the financial resources, in cash or in

kind, for the

project.

-- From the PMBOK

In plain English, a stakeholder is anyone who will be affected

in one way or another [positively or negatively] by the project.

Proper stakeholder identification is essential to a cleanly

executed project. Having a clear grasp of everyone who is directly

DRAFT DOCUMENT NOT FOR DISTRIBUTION

or indirectly impacted by the project will ensure that any

adjustments or accommodations have been accounted for. For

example, if the project goal is to deliver a new process that will

improve productivity and decrease head count, the staff that are

likely to be shifted to other positions or let go should be

included in the stakeholder identification. While these people

will not be performing the new process, they are being impacted

and will need to be accommodated somehow. These accommodations

might include cross-training in their new areas or outplacement

assistance.

Not having a comprehensive grasp of the stakeholders impacted

by a project is an invitation for major surprises later on.

Surprises are never good for a project manager because it’s

harder to spare the time and resources to account for these new

complications when the project is in full swing. Surprises also

indicate that you, as the project manager, have been blind sided

and will only decrease others’ confidence in your control of the

project.

While we’re speaking of surprises and how they are undesired

one practice that is effective in keeping key stakeholders &

executives on your side is the ‘pre-wire.’ This is simply a

DRAFT DOCUMENT NOT FOR DISTRIBUTION

properly timed conversation that gives the executive a briefing of

what to expect at an upcoming meeting or other event. Rather than

have the key executives be surprised by your news, you can ensure

they are on your side as they have been pre-wired as to what to

expect. A little effort here goes a long way to making our

efforts count!

Know your audience

Once your stakeholder identification is complete, you are able

to begin the stakeholder analysis. The stakeholder analysis is an

assessment of all groups that will be impacted by the goals of the

project. While the primary stake holder is probably well known

(ie. The one who is barking the loudest or the one with the $$$),

it is important to prepare a stakeholder analysis so that you can

ensure that there will be a sufficient representation of people

and processes during the project.

One of the things that is uncovered by a thorough stakeholder

analysis will be the identification of how stakeholders will

likely be impacted by the project both within and outside of the

DRAFT DOCUMENT NOT FOR DISTRIBUTION

organization. With this information, groups can be prioritized in

terms of importance to the success of the project. Subject matter

experts within groups can be identified and brought on board at

the appropriate time to assist in design, testing, and delivery of

the solution.

In addition to assessing the likely impacts to the different

groups, this is a good time to project whether the likely response

from each group is to be positive or negative. While it is human

nature to resist change, there are some impacts that will be

welcomed more than others. Being realistic in understanding what

the likely response will be can aid in planning how to influence

the response as much as possible.

Know your outcome

Another benefit of the stakeholder analysis is to force all

involved to take a step back before project is in full throttle

and ensure that the full impact to all groups is understood. Not

doing this assessment can lead to a common error in that a project

that is delivered without full grasp of its consequences and

impact to people and processes.

DRAFT DOCUMENT NOT FOR DISTRIBUTION

DRAFT DOCUMENT NOT FOR DISTRIBUTION