The Pm Simplicity Method A Simple And Effective Approach To

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. Projects 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 fuelefficient 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 establish 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 requirements. 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. the opposite.

We’ve all seen

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. people want to sabotage the efforts of their team.

Nor do

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? similar?

Not

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 organizationthat 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