The PM Simplicity

Method
A simple and effective approach to
managing projects

© 2010 Sean H. Henriques MBA PMP

pmsimplicity.com
 Introduction

Less is more...
The Project Management Body of Knowledge (c) published by
Project Management International (PMI) is the standard reference
for project managers all over the globe.

At 350 pages, the PMBOK is an in-depth manual that covers every

possible topic that can be managed in any type of project. It’s an
integral reference that must be part of a Project Management
Professional (PMP) certification seeker’s library.

Maybe you already have your PMP credential? Maybe you’re

hoping to acquire it. Either way, there is too much in the PMBOK
to be used on the majority of projects. How do you know which
parts to use? Trial and error? Who wants to use a project as a
guinea pig? The risks are too high.

Maybe you’re thinking ’What are the key deliverables of every

project? What can I deliver as a Project Manager that will be
useful to the majority of stake-holders? How can I avoid creating
useless paperwork?’

Read on…

What does it all mean?

If you’re a project manager [or hope to be] there are essential
things you must think about and do that will ensure your project
management efforts are effective.
 Deliver only what is essential to your projects.

Get to the heart of the matter.

In over a decade of project management work, I’ve distilled the
practice of Project Management to it’s essence. With this guide
you’ll find a roadmap that will enable you to effectively manage
your projects with maximum impact and a minimum of wasted
effort.

This guide is organized from start to finish to parallel the 5

process groups of projects.

The 5 process groups are:

-Initiation - getting approval for the project

-Planning - clarifying objectives

-Execution - managing resources to carry out the plan

-Controlling - monitoring performance against the plan

and applying corrective actions as necessary

-Closeout - handing off the project to the designated

resources, getting sign-off, and preparing final documentation

This guide is not meant to be a substitute for the PMBOK nor will
it cover all of the subjects that the PMBOK does. Rather this
guide is meant to explain why some key activities are important
to projects and how you can focus your efforts as the project
manager on those activities that will make the largest impact on
the success of your projects.

If we think about the 80/20 rule [see the Pareto principle], we can
estimate that 80 percent of your effort is usually superfluous and
unimportant to the end result. This guide is going to focus your
attention on the 20 percent of activities that will ensure that
project sponsors and other team members have confidence in
your grasp of the projects and ultimately their success.

Finally, If you gained benefit from using this free project

management book then why not consider tipping the author?
Simply visit pmsimplicity.com and pay what you feel this guide is
worth to you.

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
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
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.
 Initiation
How do projects get started in your world? Are you involved
during the formative stages or do you only get called after the
concept has been hatched? The answer to these questions will
help you grasp what you do and do not know about the initiation
of projects.
The initiation of projects can run the gamut from highly
formalized and fully documented business cases that identify
opportunities and lay out the argument for why the project is
necessary- all the way to totally informal elevator chats that
occur between key executives that result in a 3 minute
justification and request for the project.
Typically your projects will be initiated by a process that lies
somewhere between those two extremes.
If you’re involved at all during the project initiation then it is
really your obligation to bring the project as much as possible up
to the appropriate level of formality. Why you ask? The sooner
the players in the project get used to increased process and
consideration the better equipped they’ll be to provide input and
consider the ramifications of the project and any downstream
changes that may occur.

5.1 INITIATION
Initiation is 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 initiation links 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 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 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.

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

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 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 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 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
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
outcomes.
So to recap, in a textbook 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 application
areas, customer and user are 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-
nization that 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 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 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 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.
 What is Change Management?
A good definition is:
Adopting a proactive strategy that looks at content, process,
and people to ensure that the change achieves the desired result.
Content: understanding what must change in the
organization.
Process: deciding how the organization will change and the
sequence of activities that will produce the change.
People: the human dynamics that either influence the change
or are the products of it.
 Planning the approach to change management would mean
looking at these parts of the project [content, process, and
people] and assessing what will need to be managed to ensure
success.
For example, if there is an old bookkeeping system and the
project is to replace that system with one that will cut the time to
process invoices in half, a sample change management plan
would include:
-Projecting the workload impact and making plans for
transfers of unnecessary workers to other departments
-Training for the remaining staff on the new system
-Training for the organization on how to provide input to the
bookkeeping department now that they have a new system
-Keeping a double set of books in the Accounting department
when a new accounting system is put into place to provide a
method of backing out in case the new system doesn’t meet
quality criteria.
A key input into a change management plan is the
stakeholder analysis. The stakeholder analysis, by identifying all
those impacted people and processes, provides the input for
change management efforts. By having a comprehensive
understanding of all of the impacted groups and processes, you
can properly plan how to implement the project ny ensuring that
all of the necessary organizational adjustments happen at the
right time and in the right sequence.
Change management efforts include updating impacted
processes, training, reorganizations, re-allocation of resources,
and any other types of organizational change that needs to reflect
the new project when it’s implemented.
 The key here again, is to avoid surprises. When your project
is completed, there will be impacts. The goal here is to put most
of those impacts in the expected column and as few as possible
into the unexpected column. Plan now to avoid pain later.
Planning

Planning is of major importance to a project because the project

involves doing
something that has not been done before. As a result, there are
relatively more
processes in this section. However, the number of processes does
not mean that
project management is primarily planning—the amount of
planning performed
should be commensurate with the scope of the project and the
usefulness of the
information developed. Planning is an ongoing effort throughout
the life of the
project.

Scope planning is one of the things that can make or break a

project. This is the time when you as the project manager need
to communicate and negotiate with stakeholders. What you are
trying to do is elicit a clear explanation of the project’s goals.
Simultaneously with this you are negotiating the nice-to-haves
that all too often fall from people’s lips disguised as requirements.
The nice-to-haves are superfluous and more importantly can
very quickly drain the project resources making it less likely to
deliver the project on-time, on-budget, and with high quality.
By focusing on these two threads - detailing project scope and
negotiating away nice-to-haves, you are establishing credibility
and authority over the project and showing the stakeholders that
you want to deliver a high-quality project that meets the specific
needs of the project.
During this process, you are demonstrating that you are
capable of negotiation and flexibility and that there needs to be
give and take from all concerned to deliver a high quality project.

The above is a sample scope diagram that is one of the ways

to communicate the output of these discussions. This scope
diagram shows exactly what will be delivered and when. This
diagram shows that the PM was able to negotiate multiple
milestones or phases to ensure a manageable schedule.
 Having the right team members is important to the success of
the project. By seeking the right resources you have proven that
you have a clear understanding of two crucial things:
-What the project is supposed to deliver
-Who and what is needed to deliver the project successfully
Part of the negotiations that should go into a project initiation
is that the necessary resources will be made available to the
project. All too often there is a notion that simply by saying ‘Make
it so!’, project sponsors will make projects happen. While it may
be an unpleasant reality for some to face, this is simply not true.
Projects have costs in both dollars and resources. No one
would think it acceptable to go into a department store and help
yourself to the items on the racks and similarly, just making a
demand that a project should happen without accounting for
resource requirements means that resources will be in effect,
stolen from other projects and processes. There are no magic
beans, everyone must pay the piper.
Once the scope statement has been negotiated and signed off
on by the key sponsors, it is time to do a detailed analysis of what
will be required to make the project a reality. Much like a detailed
parts list for a new home, the detailed activity list will reveal what
types of skills are needed and for how long. This translates into
costs if consultants or other specialists need to be brought in to
supply knowledge that is not currently available from internal
resources.
The detailed activity list will also give estimates of time
requirements for resources that are readily available but spoken
for on other projects. In other words, just because the necessary
skills and knowledge are readily available to you in your
organization doesn’t mean that you can grab people at will.
There needs to be some coordination and negotiation with other
managers to ensure that you’ll have access to the required
personnel when you need them.
This point is all too often overlooked on internal projects done
by organizations. For example, on a software development
project, all too often project managers will just jot down that
they’ll need a database administrator to perform certain activities
without ensuring that their timelines are acceptable to the
database administrator and his/her supervisor. This leads to last
minute requests for activities that might seem insignificant to the
project manager but are undoable to the database administrator
because they’re already allocated completely.
Above is a sample communication plan. This is a simple table that lists
who will be communicated to[audience], how they’ll be communicated
to [vehicle], how often it will happen [frequency], and the method of
delivery[medium].

By articulating this information and more importanly being

consistent in meeting the commitments established by this document,
you’ll be establishing a level of confidence among the project
stakeholders that someone is watching the ball and they can focus on
what your needs are as PM rather than trying to get information on
project status
 The Triple Constraints

“Do you want it good, fast, or cheap?”

This is the old aphorism that mainframe computer
programmers used to share. This refers to the truism that for a
given set of requirements, there will be a sweet spot, at which the
intersection of quality, delivery date, and money spent will be
found.
In other words, the more money you have the higher quality
one can expect for a given output. Another example of this
interplay between the triple constraints is that with more time one
can reasonably expect a better outcome because there has been
adequate analysis and testing before delivering your solution.
The triple constraints applies to just about any project and is
greatly impacted by the three corners of the triangle above.
In other words:
 -Scope - if your project only delivers 10 new widgets, the
chances of having satisfied customers [quality] is greater than if
one attempts to deliver 100 new widgets
-Cost - if your budget is 100X then the chances of delivering
a high-quality solution is greater than if your budget is just 1X.
-Time - if you have 3 months to do said project, the chances
of having a solution that is successful [quality] are greater than if
you have just 3 weeks.
This simple concept has huge implications for the
project manager. If a project manager is able to keep an eye on
requested features and negotiate an ample schedule that allows
time for testing, this puts the project on a much stronger
foundation. If the project manager finds that s/he is often just
adding features without any real analysis and also finds
him/herself agreeing to tighter and tighter timeframes, then the
project will be an unpleasant struggle for all concerned.
 Steering a ship is a slow and methodical process.

The larger a project team you’ve got, the more like a cruise
ship captain your directions will take. An agile project team of
just a handful of folks will be more responsive and require less
planning when interjecting corrective actions. A larger project
team will necessitate much more careful and methodical
adjustments because with a larger project team, comes larger
responses that are much more difficult to reverse. Think of a
cruise ship. When a captain makes an adjustment of just a few
degrees from course, the outcome of the action is slower to
materialize but results in a much larger course change than with a
smaller ship.

The executing processes include core processes and facilitating processes. Figure
3-6illustrates how the following core and facilitating processes interact:
■ Project Plan Execution(4.2)—carrying out the project plan by performing the
activities included therein.
■ Quality Assurance(8.2)—evaluating overall project performance on a regular
basis to provide confidence that the project will satisfy the relevant quality
standards.
■ Team Development(9.3)—developing individual and group skills/competen-
cies to enhance project performance.
■ Information Distribution(10.2)—making needed information available to
project stakeholders in a timely manner.
■ Solicitation(12.3)—obtaining quotations, bids, offers, or proposals as appro-
priate.
■ Source Selection(12.4)—choosing from among potential sellers.
■ Contract Administration(12.5)—managing the relationship with the seller.

The project schedule is the document that lays out who will
do what when. It is a schedule of activities that should take into
account dependencies and sequencing of activities such that the
desired conclusion can occur at the desired time.
The project schedule is NOT the project plan as discussed in
the foreword. This is a common mistake and one you must avoid.
If people are asking for a project plan and you are only prepared
with a project schedule, you’d better be hopeful that they don’t
understand the difference.
Many people think of Microsoft Project as the tool for project
management. This further reinforces the fallacy that Microsoft
Project creates project plans and that by using it you are a project
manager.
To reiterate, Microsoft Project is a project scheduling tool. It is
commonly used to create detailed project schedules that take into
account resources, costs, dependencies, and work schedules. By
using a tool like Microsoft Project, you’ll be able to create PROJECT
SCHEDULES which will give a timetable of activities and who does
them. The output can be viewed in whatever format that is
required. Typical output formats would be calendars, gantt
charts, work break down structures, or network diagrams. All of
these formats communicate the same basic information.
The project schedule is an integral part of the project plan but
it is by no means the actual project plan.

Does anyone else see the pink elephant in the room?

The process of mitigating risk is relatively simple. It entails

identifying the risk - what could happen? The identifying factors -
how does one know that it is happening? The corrective action -
what should be done when the risk is identified?
 This is the first part and the easier part as it can be done in an
office without input from others. Although more effective risk
identification would involve more members of the project team, it
can be done solo.
The execution step to risk mitigation requires more courage.
That is getting everyone to agree that the risks indeed are
possible. Some people approach project work with the sense of
overwhelming positivity that anything is possible if we only work
hard enough. While a positive attitude is certainly conducive to
positive outcomes, it will in no way make up for basic
shortcomings like inadequate resources or an ill defined project
scope.
The all too easy approach that often results in project failure
is burying one’s head in the sand in the hopes that the risk will
resolve itself. This is something that can be tempting to even the
most seasoned project managers. Not everyone is feeling at 100
percent effectiveness everyday but it’s important for this not to
get in the way of speaking out when there are risks facing the
project.
This speaking out is made a lot easier if the pre-work of risk
identification is done. By preparing a risk management plan and
spending the time with the team to identify as many possible
risks to the project and what should be done to correct will ensure
that everyone is prepared to do the hard work of speaking out
when a possible risk becomes an actual outcome.
 Above is a sample risk management plan. The columns are
capturing the following information:

Column Data
ID ID number for risk
Description of Risk A narrative of the risk
How possible is it that
Likelihood
the risk will occur?
If it were to occur, how
Seriousness
serious is the risk?
The score of the risk as
Grade per the table above the risk
register
- denotes a new risk

Change up or down arrow

indicates change from last
reprt.
 The soft skills, also known as ‘people skills’, of a project
manager often make or break the chances of his/her success. Is
this an individual that is successful in getting everyone to work
towards the same goal and provide assistance and guidance in
getting there or is this individual more of an autocrat who feels
that he/she knows the best way and everyone should simply
follow.

While the autocratic type often gets hired by the display of

sheer will or bravado, the chances of success typically depend on
the type of project he/she is put in charge of. A theory called the
Least Preferred Coworker discusses this.

When asked, a project team will identify the person they least
preferred working with. If the project is going smoothly with little
risk or stress among the team, the Least Preferred Coworker is
usually not the Project Manager but someone on the project team.
This is because the Project Manager needs to be relationship
oriented to ensure the continued contributions of resources and
the eventual success of the project.

Conversely, when the project is not going well and the project
team is under a great deal of stress, the Least Preferred Coworker
should be the Project Manager because if the project is going to
be successful, the Project Manager needs to be task-oriented and
focus on getting the work done regardless of the feelings of the
team.
 Which type of project manager would you say you are? If you
can easily identify yourself as relationship oriented or task
oriented, then the challenge for you to be a well-rounded pm is to
focus on building the skills to be the other type. This is because
the approach needs to be tailored to the type of project one is
working with.

The art of confidence and why it’s important.

As a project manager, people will be looking to you for
guidance and direction. In a typical organization you have
leaders and followers. Not everyone is a good leader nor is
everyone a good follower. There is a lot of research on the
concept of leadership and would you believe there is also a
considerable, but not as well known, body of research on the
concept of follower-ship.
All this to say that self-awareness is important. Are you a
good leader or a better follower. There is a place for both
attributes in an effective project manager. While a project
manager is a leader to those on the project team, sh/e also needs
to be a good follower in that the project manager needs to answer
to someone, be it a CEO, CIO, or other direct supervisor.
One of the benefits of self-awareness if confidence.
Confidence is crucial in establishing credibility in an organization.
People respond to confidence with a more open ear and a more
willing attitude. A project manager who lacks confidence had
better work on getting it as trying to be an effective project
manager while lacking confidence is like driving a car with three
wheels. You may or may not get to the destination and you’ll
surely find it frustrating as you are on your route.
If you think you need to develop confidence then do explore
the below resources or find something that works for you. The
simple act of challenging yourself and consistently getting out of
your comfort zone is what leads to growth as an individual and
greater self confidence.
There is no substitute for confidence.
Toastmasters
Toastmasters International is a global organization devoted to
the art of public speaking. The organization is comprised of clubs
located all over the world run by members. For a very small fee,
membership in Toastmasters gives you the opportunity to network
with fellow members as well as participate in a very clearly
mapped out curriculum that focuses on two tracks. The two
tracks that Toastmasters focuses on are Public Speaking and
Leadership.
Participation consists of showing up to the meetings and
giving speeches that focus on designated topics. Each speech
gets you closer to completion of different levels of Toastmaster
status. The first speech is usually the hardest for people to give.
This speech is called the Icebreaker and very simply you are told
to speak about yourself. This is to introduce you to the club as
well as let you speak on a topic you’re intimately aware of,
yourself.
As project managers, we are called upon to communicate
though our words. To be an effective project manager, the way
you speak and the confidence with which you communicate will
greatly impact your ability to gain support and deliver solutions.
Toastmasters is a fantastic resource that has been around
since 1924. If you’ve not explored it yet, what are you waiting
for? Give it a try. If the first club you attend doesn’t seem to fit
with your needs, try another club. The beauty of this organization
is that the clubs tend to take on the personalities of those
involved in running it. This gives the clubs some diversity in style
and you’ll be sure to find a good fit with a club in your area after
visiting a club or two.
Dale Carnegie
Dale Carnegie is a writer who is responsible for one of the
best selling books of all time. His book, How to Win Friends and
Influence People has been translated into numerous languages
and has sold over 15 million copies.
Mr. Carnegie’s clearly written prescription for how to
effectively communicate others is as relevant today as it was 75
years ago when it was written. The lessons can be distilled into
the following:
-Be positive
-People like to talk about themselves
-Give praise not criticism
By understanding these basic human relations principles,
you’ll find that you’ll more quickly establish meaningful
relationships with those around you and that your credibility will
increase as people will be more interested in hearing what you’ve
got to say. Obviously, as a project manager, this is a essential
position to be in.
Getting Things Done (GTD)

GTD is a very popular productivity practice popularized by Dave

Allen ( http://davidco.com )

In a nutshell, it’s a practice that gives you the roadmap to get

away from being overwhelmed with all of the many things you must do
and not forget. The first step of this roadmap is called “the mind
sweep”.
 The mind sweep is a weekly routine that consists of getting the
many things one must remember out of one’s head and into the
“inbox” for later processing. From there you can “file” these items into
projects for organization and contexts for location based action. It’s
well worth exploring if you’ve not heard of GTD as it becomes more
useful as our environment becomes more saturated with noise.

These are just a few tools that you can use to boost your
confidence in communication and execution as a Project Manager.
 Controlling
The ability to plan [forecast], monitor [observe], and control
[course correction] are crucial to the project manager. These are
not innate gifts that only some people possess. Rather these are
practices that are built up over time through experience.
Once you understand that no plan is executed faithfully
without some deviation and that corrective actions can be pre-
packaged along with the cues that will signify their necessity,
you’ll begin to understand the primary role of a project manager.
In the many situations that someone has been designated to
be the project manager there are as many expectations of what
the project manager is expected to do. The fundamental
activities of a project manager regardless of the setting are the
same though. The project manager is expected to keep the
“project on track”. The way this is done is with the Controlling
activities.

Project performance must be monitored and measured regularly to identify vari-

ances from the plan. Variances are fed into the control processes in the various
knowledge areas. To the extent that significant variances are observed (i.e., those
that jeopardize the project objectives), adjustments to the plan are made by
repeating the appropriate project planning processes. For example, a missed
activity finish date may require adjustments to the current staffing plan, reliance
on overtime, or tradeoffs between budget and schedule objectives. Controlling
also includes taking preventive action in anticipation of possible problems.

In real terms, change control is simply pre-establishing how

change requests will be processed. By communicating the
change control process up front, you can help to avoid the all too
common reactive approach to requests for modifications that will
inevitably come up.
The reactive approach is to make change requests an
automatic high priority if they come from someone high up the
organization. The thinking with this is that the senior person
requesting the change has some specialized insight and of course
status that should make his/her request a given. The problems
with this ‘free-pass’ are many. The senior person may or may not
have the insight that the full project team has to offer. By not
vetting the request as thoroughly as any others you are
introducing risk.
The best way to avoid this problem is by pre-defining the
change control process at the beginning of the project.
How this works is that, again at the front end, you clarify who
will be authorized to enter change requests that will impact the
project. You’ll also define how the changes will be vetted and
approved. You will also ensure that everyone is very clear that all
changes will need to be analyzed thoroughly to clearly
understand the impact to the project in terms of time and cost.
Nothing is free. Remember that.
 Closing
Project closeout is managing the draw of the final curtain on
the project. Unfortunately, project closeout like project initiation
tends to be neglected or even eliminated from projects. Reasons
for doing this include moving onto the next project or not seeing
the importance of a properly closed out project.
What are some of the key benefits you should be getting out
of a properly closed out project?
-Closure from the entire team. Putting a period to the end of
the sentence gets everyone to the same place and ensures that
everyone is clear that the project is over and any
support/operations effort is now to be handled by the designated
processes.
What’s that you say? You haven’t considered ongoing support
for your project? You should consider the following about closing
our your projects:
-Lessons learned documentation - A project closeout meeting
is the perfect time to get all of the players in a room and ask for
their observations of what worked and what didn’t. Ensure the
tone of the meeting is not a bitch session but rather a productive
session to ensure that things that worked get reproduced and
things that don’t get tabled.
The lessons learned document is a summary document
highlighting these observations and should be distributed widely
to the organization and even better, put into a document
repository of some kind. Whenever a similar project is being
considered, the lessons learned for all similar projects should be
reviewed to ensure mistakes are not repeated and successful
practices are put into place.
-Celebration - The simple act of celebrating the end of the
project whether it is successful or not is important because it
cements the bonds and working relationships that have been
forged. It also recognizes that everyone plays a part in the
outcome of the project, that it’s not just the project manager that
gets the recognition but everyone who contributes whether it be
in labor, knowledge, or other resources. A simple lunch or after
work gathering is all it takes to give people the opportunity to
connect in celebration and to feel appreciated for their
contributions.

As part of project closure, the project manager should call a

lessons learned meeting. This meeting will be to bring people
together to discuss what worked and what didn’t Every project
offers lessons that can be incorporated by people and the
organization at large. The challenge in this meeting will be to
keep everyone positive and focused on sharing opinions without
being too negative.
The output of this meeting should be organized into a Lessons
Learned document. The goal of the document is to neatly
summarize all of the things that were learned during the project
that may be of benefit to others embarking on similar efforts. The
document should be cataloged and referenced whenever a similar
project is being considered. A sample lessons learned document
is below.
In this example document, the observations are organized by
project phase. One of the benefits of organizing the lessons this
way is that it makes it easy for readers to follow the path of the
project over time.

Now that you’ve read about all of the process groups and
parts of what makes a successful project, it’s useful to consider
the following fact. If you think of a bell curve then think of the
tails of the curve being initiation and closing respectively.
As a project manager you’ll be called in to manage the project
most typically [say 80 percent] of the time in the main hump of
the curve. That means you’ll be called in during the planning
phase and it follows that you’ll be handed a project specification
and some rough estimates that are thought of as final. That’s
often the first challenge of the project manager when s/he is
brought onto the project. They need to work doubly hard to
understand and rationalize the assumptions that went into this
rough framework that they’ve been handed.
This task needs to be given sufficient attention and short
changing this will only mean increased risk later in the project. All
assumptions and estimates [e.g. Delivery dates] need to be
checked as thoroughly as possible before proceeding.
A corollary to this challenge is the tail end of the project. All
too often, project managers are pulled off projects when they are
winding down and this is typically before a full close-out of the
project has been completed. It’s onto the next big thing for the
PM and the pressure to move on can be great. The downside to
this less than thorough closeout is that the ancillary benefits to
the project are not made real. The lessons learned document and
other project closeout activities that increase team cohesion and
increase organizational effectiveness are all too often not
completed.

Well that wraps up the PM Simplicity approach. I certainly

hope you’ve found this document informative. While it’s geared
to new Project Managers, my hope is that anyone regardless of
experience level gains some benefit.
This e-book was made available for free. If you’ve gained any
benefit then show your appreciation by clicking the “Tip the
Author” link on http://pmsimplicity.com
All the best.

Sean