Posted on

Project Manager Credibility- Sell Yourself and the Project

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

If you want credibilty and support from users and executives you must “sell” yourself and your project.  If you ignore selling or you try to impress them with technical jargon they will see you as irrelevant to their issues.  Let’s look at a PM’s fantasy of how they are perceived by the user and then see the harsh reality.

PM’s Dream Credibility…(That Never Happens)

An expectant buzz of conversation fills the meeting room as the assembled “suits,” await the project manager.  Each executive knows that he or she will leave the project presentation enriched with new knowledge and a PURPOSE. Suddenly there is silence.  Then they hear a faint swishing noise as the PM’s belt-mounted cell phones, three pagers and two Palm PCs jostle against one another. The crowd parts and the project manager swoops into the room with a stack of Gantt charts in one hand and a pile of PERTS charts in the other.  The PM glides to the head chair, nods to the hushed throng and says, Selling projects“Here is the Project Scope:. The AFR443 project will have a gooey interface and 354 nano-gigabytes of ROM, RAM, TAM and PAM. We will not impact the bandwidth on advertisements for customers and will not inflict trauma on the techno-workers who morph customer service.”

The executives shriek their approval of the project plan.

One executive slams a hand on the oak table and shouts, “If anyone fails to cooperate instantly, you may flog them.”

Another flaps a sheet of paper at the PM and yells, “Here’s the title to my BMW.  If I ever suggest a change in the scope you have so clearly enunciated, you may have the car.”

A third screams, “You can take as long as you want and spend as much money as you need.”

Additionally, the support continued that same way for the life of the project.  People who said, “You have my full support,” actually meant it. There weren’t new #1 priorities daily that changed the scope.  Team members treated project assignments as if they really mattered and not as work for times when there was nothing more important to do.  No one vanished into the underbrush just when their critical path task was about to start.

Selling Projects – PM’s Real World

You can count on this fantasy or recognize the need to sell your projects.  This need is most clear before project approval. But it is required through the entire project and the lesions learned at the end. The twin concepts of selling the project and having people “buy” it are most obvious when you do a project for a client. But the are also necessary when the “buyer” is your boss or a user department.

So what are you selling? How do you sell it? And what are they buying? Do you sell a lot of technical lingo, a 40-page scope narrative and an endlessly long Gantt chart? Too often that’s all you have to sell.  It’s no wonder that few people “buy” it and whatever support exists on “approval day” fades quickly. With it go the odds of your project success.

Some PMs try to make up for the lack of value in what they are selling with a “silver tongued-devil” approach, like a used car salesman.  They may not wear a plaid outfit or mousse their hair but they say things like “I’m your strategic partner”, “we’re user-oriented”, and “I’m here for you.”  However, no sales tactic can make up for the fact that you have not created project value in the user’s, client’s or boss’s mind. So while you may be charismatic and cute, support based on “golden words,” strong personal relationships or charisma doesn’t give your projects the kind of support they need. This becomes painfully clear when you need more resources, need to cope with a problem team member or must exercise scope control.

Selling Projects – Project Positioning & Hidden Performance Pressures

In selling projects, you need to present your projects so the boss, user or client “buys” the value of the project’s business result.  The business result has value when it relieves a performance pressure that your decision-maker feels. What are performance pressures? They are the operating shortfall that the decision maker’s boss made a big point of at the last quarterly review.  They can also be what the newspapers wrote about last week that made all the executives frown.  The problem is that most of the time decision makers tell us what to do; not what performance pressure they want to resolve. And, whether or not they have told us about their performance pressures, they will judge the project’s success based on whether it relieves those performance pressures.

This sounds simple but there are a couple of problems when you are selling projects.  First, you must identify the decision-makers who have a stake in the project.  Often times, performance pressures ripple through an organization and the person who assigns the project may not know where the performance pressure came from.  Second, with the decision makers identified, you need to quantify the performance pressures they want the project to relieve. As projects get larger, your “map” of decision makers and performance pressures can become complex.  But keeping this mapping updated is a great tool for account management and positioning.

Let’s say you get a project assignment to change a billing system report by adding several data elements and altering others.  The billing supervisor who described the project may have no idea where the changes came from or what the higher up wanted to achieve.  As you probe for the performance pressures, you find out that things started with the CFO wanting to identify the biggest customers.  A marketing director complained about how hard it was to track the sales that resulted from special promotions to these big customers. When you convert these performance pressures into measured achievements (See AdPM™ Achievement-driven Project Methodology) you have value to sell these decision makers. That leads to higher odds of project success.

This sounds simple but there are some barriers to unearthing the decision makers and then quantifying their performance pressures.

Selling Projects  -“Buying Perception” Barriers

Why don’t many clients/users/bosses share this information?  First, sometimes it reflects badly on them and there are many who won’t talk about their problems or pressures.  Second, they may not know what upper-level performance pressures rolled down-hill to them.  But the dominant reason decision makers don’t tell you about their performance pressures is their buying perception of project managers.  That means what they think they are buying ,or can “buy,” from a project manager.  The worst project buying perception is when the user/client/boss sees you, the PM, as an order-taker.  With that perception, they share the same amount of information with you as with the person at the drive-through window at McDonald’s®. Here’s an example of a PM selling projects and probing for performance pressures with a decision maker who has an order-taker buying perception of the PM:

Decision maker says,”Here are the changes I want in the report layouts.”

PM says, “Great! Exactly why do you need these changes? What are you trying to achieve?”

Decision maker answers, “I need the changes by next week.”

PM says, “If I understand your business purpose then I can do a better job of …”

Decision maker says, “That’s not your concern. Just make the changes in these report layouts by next week!”

PM says, “You’re making me fly blind here.  If I don’t understand what you…”

Decision maker says, “Make the changes in these report layouts, you little geek.”

This PM made a strong effort to unearth the performance pressures that triggered the project request. But they pressed so hard that they angered the decision maker.  The PM failed to unearth the performance pressure(s) or the cast of decision makers involved. They don’t have much to sell and the decision maker doesn’t have much value to buy.  They PM only knows the decision maker wants them to start quickly and hit the due date.  This brick wall the PM hit was low-level buying perceptions.  It reflects poor positioning with the decision maker.  It might result from the decision-maker’s previous experience with PMs who operated in the order-taker mode and never even asked about the performance pressures.

But if you focus on selling projects, you know there are performance pressures behind the decision maker’s request.  You can just start work on the assignment and hope that the decision maker has correctly aimed the project so it relieves their “hidden” performance pressures.  This hoping happens too often. Hoping perpetuates the order-taker buying perception. And puts you in a position where you’ll need luck to have the project be a success.

Selling Projects – Building Bad Perceptions with Techno-babble

You can start to change poor buying perceptions when you work with the user/client or the boss by selling projects. However, what often happens when you get a chance to meet with a decision maker to discuss the project?  Out of nervousness, inability to discuss anything else or a desire to impress the decision-maker with your expertise, you drag the conversation into the project and technical details. You never focus on their performance pressures.  Is the decision maker impressed?  No, they’re thinking, “This person is really scary. They have absolutely no perspective on what we want to achieve for the business.” That’s another example of a PM’s bad efforts selling projects.

To get at a decision-maker’s performance pressures, you have to stop talking about the delicious technical details of the project and start selling projects. You must probe and listen for their performance pressures.  Even better, you will meet with the decision maker after you have gathered information about their likely performance pressures. You use these sessions to find out what they want to buy as an end result. That is very different from what they want us to do.

Selling projects is a process of positioning.  You work to elevate the user/client/boss’s perceptions of what they can “buy” from you.  Then you use those improved perceptions to position our project(s) to relieve their performance pressures.  Each time a project relieves a performance pressure, their buying perception of you improves, making it easier to get and hold support for this project. Additionally, it will be easier to sell the next one.

At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management
Posted on

Small Project Planning Techniques

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Here is how to use a few Small Project Planning Techniques for success on your projects. New project managers often make the mistake of trying to apply every technique in their project management textbooks. So they wind up burying small projects under too many meetings and too much paperwork. They should ignore the  fancy processes, techniques and reports in the academic textbooks and stick to the basics.

We’ll define small projects as those done within your “home” department with your boss as the project sponsor. Here are some general guidelines for using the Small Project Planning Techniques. Your project plan should be one page or one and a half pages at the most. There is no need to bury the boss in a large document filled with boilerplate crap. Instead, your one-page project plan will focus on the key deliverables and decisions that will drive the project to success. You should also limit the number and length of planning meetings. A 15 to 20 minute meeting with the boss to define the scope and major deliverables should be enough. You just need to ask the right questions to get the boss to define what the boss wants the project to deliver.  Then you break it down into tasks and create a work breakdown structure (WBS). Next, you specify the resources required and estimate the amount of work for each task. Then you develop a schedule. Let’s talk more about each of these five techniques.

Small Project Planning Technique #1: Define the Scope

You must meet with the project sponsor, the boss, to define the scope of the small project planning techniquesproject. The scope is not a list of everything you’re going to do. It is the end result(s) the project should produce.  You get that definition and the acceptance criteria by asking your boss the right questions.

As an example, the boss tells you he/she wants the file room cleaned up. The scope is not a list of activities like: picking up files off the floor, alphabetizing files, inserting updates into files, etc. Those are activities that you may do to reach the scope, but they are not the scope – the end result. You need to ask the right questions to find out what the boss wants at the end of the project. What you need are acceptance criteria. These are the metrics the boss will use to measure if the project was a success.  After asking the right questions, you may find that the boss wants more than just a cleaned up file room. The scope that the boss really wants is, “Employees find the file they need in less than 60 seconds.” It’s a project management best practice to find that out before you start work.

That “find the file in less than 60 seconds,” is a good definition of the project’s scope because it is objectively measurable. All good scope statements have a metric that mathematically defines exactly what the project sponsor wants the project to deliver. You have to ask the sponsor the right questions about the end result of the project so you get an objectively measurable definition of the project’s scope.

Why is this objectively measurable scope so important? Because it is impossible to deliver the result the sponsor wants if you don’t know what it is. If you settle for a scope that is vague and subject to interpretation like, “Clean up the file room,” you will not have a clear target at which to aim. It’s likely your interpretation of what “clean up” means is very different from the boss’ definition. Sadly, you will find that out when they tell you the project was a failure because it didn’t achieve what they wanted.

So you must ask questions of the boss/sponsor to specifically define the end result in measurable terms. And you must try to avoid getting into a detailed discussion of what activities the sponsor wants you to do.

Small Project Planning Technique #2: Break Down the Scope for the Work Breakdown Structure (WBS)

You might do this step in the same meeting with the sponsor as Technique #1. You will break down the scope and get the sponsor’s agreement on the major deliverables the project has to produce. These deliverables will get you from where you are now to the end result, the project scope. You’ll start by breaking the scope down into 4 to 7 major deliverables. On some small projects, you may be able to work on all the major deliverables at the same time. On other projects, you will work on them one after another. Each of the major deliverables is a metric, just like the scope. You’ll again ask the sponsor questions to break down the scope of “Employees find the file they need in less than 60 seconds.” The following list of major deliverables will become the start of the work breakdown structure (WBS):

  • All files on the shelves in alphabetical order
  • Updates to files are current within 4 business hours
  • Employees return files to the file room within 24 hours
  • File room staff can retrieve files in less than 60 seconds.

You will then break down those major deliverables to the next level of detail. They become the individual assignments for each of your team members. You’ll also define each assignment with a metric that measures the team member’s success on their deliverable.

Small Project Planning Technique #3: Identify Resources and Estimate Work

For each assignment or task in the Work Breakdown Structure (WBS), you will identify the necessary skills and the right people to do the work that will produce the deliverable.

After ensuring that each team member is clear on what they have to produce, you work with them to develop estimates of the number of hours of work it will take them to produce the deliverable. It’s important to involve each team member in this estimating process so the team members feel some commitment to the estimates that you’ll use in your project schedule. You will present these resource requirements, the number of people and hours of work, to the project sponsor for their approval.

Small Project Planning Technique #4: Identify Major Risks for Deliverables

Working with the team member who is accountable for each deliverable in the work breakdown structure (WBS), you will discuss the major risks that, if they occur, would increase the amount of work it will take to produce the deliverable. You’ll identify these risks now so that you can develop strategies to avoid, or at least lessen, the impact of the risks on the project. Identified risks and their mitigation strategies are an important element in the final project plan. In our file room project, you might identify risks that threaten the scope like the following:

  • Risk A – employees do not return files within 24 hours.
  • Risk Response A – send managers a report of missing files checked out by their subordinates.
  • Risk B – high absenteeism in the file room causes the staff to fall behind on re-filing.
  • Risk Response B – arrange for a temporary staffing firm to provide replacement staff.

Small Project Planning Technique #5: Develop the Schedule

The last component in the project plan is the project schedule. You should build a schedule for even the smallest projects. And you should use project management software because it saves enormous amounts of time.

You’ll use the work breakdown structure (WBS), the resource assignments and the work estimates you created earlier. In the software you’ll link them with predecessor relationships. Predecessor relationships are very important because they determine the sequence of tasks, the order in which they are done.

You will enter all the tasks in the software, then set up the predecessor relationships. This is much simpler than it sounds. For example, you tell the software that task #5 can’t start until task #4 is finished. When you put predecessor relationships into the project schedule, the software can update the schedule every week when you enter the data on what has actually happened on each task.

See how these planning components come together in the project planning techniques template below.

Small Project Planning Techniques Template

  1. Define the project scope as a deliverable with measurable acceptance criteria
    Employees find the file they need in less than 60 seconds.
  2. Break down the scope into its major deliverables for the work breakdown structure (WBS)
    a. All files on the shelves in alphabetical order
    b. Updates to files are current within 4 business hours
    c. Employees return files to the file room within 24 hours
    d. File room staff can retrieve files in less than 60 seconds.
  3. Identify the major project risks and their responses
    a. Employees do not return file within 24 hours. Risk response – send managers a report of missing files checked out by their subordinates.
    b. High absenteeism in the file room causes the staff to fall behind on re-filing. Risk response – arrange for a temporary staffing firm to provide replacement staff.
  4. Identify the project team resource requirements with rough estimates of the time commitment
    Bill – full time 3 months
    Mary – half time 2 months
    Raj – full time 3 months
    Moussa – quarter time 4 months
    Henry – full time one week
  5. Build the schedule using project management software

You can learn how to use all these Small Project Planning Techniques in our online Project Management Basics courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the course in your specialty.

At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management

 

Posted on

Agile Project Management Methodology

What is Agile Project Management Methodology?

There is lots of talk about an emerging approach to project management called “Agile Project Management Methodology.”  Agile Project ManagementUnderstandably, some may confuse this with managing an AGILE software development effort as part of an organization’s  SDLC (Systems Development LifeCycle). All caps will be used to identify the software development methodology).  Recently,  PMI (Project Management Institute) began offering a “PMI-ACP Certification” (Agile Certified Practitioner). Project Methodology Main Page.

I talked with several practicing senior-level technology, business, and various industry project managers regarding their understanding of “Agile Project Management Methodology.”  Each of these experienced managers had a different interpretation of what this might mean but none had actually implemented this specific approach within their firms.  However, one organization was in the early stage of adopting an Agile Methodology Playbook.

The consensus was that Agile Project Management Methodology grew from the desire to produce results (deliverables) faster and reduce bureaucracy and burdensome “administrivia.”  The respondents also believed that if a project was primarily a business process reengineering effort (i.e., how do we eliminate duplicate work efforts within an operations team?), it probably would not be using Agile Project Management Methodology.  Time will tell if this proves to be correct.

A quick overview of AGILE software development is in order here. It is an iterative application development effort where requirements and solutions evolve through collaboration among developers, business owners, stakeholders, project sponsors, and end users (clients).  This methodology was developed almost fifteen years ago as an alternative to the heavyweight, document-driven software development processes such as waterfall (application development progress flows from one stage to another, incorporating feedback).  Within AGILE, a well-known software methodology is Scrum. It identifies “sprints” to produce smaller deliverables (deliver software “early and often”).  Changing requirements are expected and there is close, daily cooperation and communication between business people and developers.  Team members are co-located team members when it’s possible.

Most organizations have their own specific project methodology and if AGILE is part of their SDLC, it most likely has been customized to meet the needs of that organization.

While AGILE has been successful in many instances, it presents challenges for very large implementations and in large organizations where a centralized IT team supports multiple business enterprises.  Technology teams typically have a good understanding of what AGILE means. But business users, project sponsors, and stakeholders may not be as clear.  So detailed planning and excellent communication are key to ensure agreement as to exactly what functionality will be delivered “early and often”, as well as the quality of that deliverable (i.e., what bugs will be fixed when, and how will they be retested?)

Additional challenges arise when an AGILE development approach, which may fall under Agile Project Management Methodology, is supported at the corporate level. This is particularly true when you’re implementing a new vendor-based software solution. Individual enterprises may need to continue following a waterfall development approach when they have older legacy systems with multiple integration points. This situation creates frustrations, conflicts, and costly regression testing.

Any methodology should be viewed as the framework within which a project manager executes solid project management skills. They tailor the methodology to the specific organization and actively manage process interactions (i.e., scope change will affect cost and require trade-offs).  Managing in an “agile” way has always been a core competency of successful project managers.  Adopting an Agile Project Management Methodology should not be interpreted as a way to do an end-run around controls. Nor is it a license to take short-cuts through the critical processes of project management, (initiating, planning, executing, monitoring and controlling).  Instead, it should be viewed as an opportunity to consider a new and, hopefully, improved way of achieving success.

It is still not entirely clear if managing an AGILE software development effort automatically qualifies as adopting an “Agile Project Management Methodology” approach. Perhaps there is now a broader meaning to this project management approach which may or may not involve AGILE software development. It may just infer producing results faster.   Hopefully this will be made clearer over time. It will be interesting to track this Agile Project Management Methodology and to note how it is improving overall project management execution and delivery. It must be evaluated from the perspective of the project team, project sponsors, stakeholders, and end users.

Agile Project Management Lessons Learned

At the beginning of your 4pm course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management
Posted on

Project Plan Blunder #2 – Turf Wars

A project sponsor is meeting with the department managers who are her subordinates. She’s called them together to tell them their company is receiving terrible publicity. Their horrid customer service has made the front page of the local paper. She needs them to create a project plan to improve their customer service.

The sponsor explains that they need an integrated effort. Each of the four departments needs to cooperate with the others to bring about a significant improvement in the company’s customer service. When the project manager suggests that people in the various departments will work on tasks he assigns them, all hell breaks loose. The turf wars are intense. None of the managers accept the idea that people can work effectively on a cross-functional team. The project sponsor makes more speeches about the need for cooperation. The project manager tries to explain that isolated efforts in each department will not bring about the strategic improvement that the company needs.

Project Plans and Turf Wars

Project plan turf wars happen in many organizations.  When political battles exist between departments, the warring sides often suggest separate projects in each of the departments. They think that eliminates the need for cross-functional cooperation. But that never works. It also doesn’t work if there is a separate project manager in each department with the overall project manager coordinating all their efforts.  The idea of separate projects and project managers sounds good to people caught in inter-departmental conflicts. But successful project managers know that the way to succeed in cross-functional projects is not to subdivide them. That’s the easy step to take. It allows them to avoid solving the basic conflicts that exist.

Let’s look at the video and see how the project manager and sponsor do with their project plan. What would you do to end these turf wars and give the project some chance of succeeding?

Project Planning Blunders: Stakeholder Turf Wars

Posted on

Project Management Plans: Three Sizes

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

There is a great deal of science in Project Management Plans but there’s also a lot of art. The art comes in deciding which processes, tools and techniques are best for each new project. The easy answer is to use the same Project Management Plan steps on every project. That approach buries small projects with paperwork, meetings and processes that don’t contribute to the odds of its success. On the other hand, it often leaves large strategic initiatives with insufficient project management and overly simplified techniques. You must use the right techniques and processes for your Project Management Plans to improve the project’s end results. In this article, I suggest the “right” steps for Project Management Plans on projects of various sizes. Project Plan Template Main Page

Your first step in Project Management Plans is always to define the project scope. That is the basis for the scope statement, the work breakdown structure (WBS) and the estimates of cost and duration. The amount of project planning you do relates to the size, risk and complexity of the project.  But all project management plans should include a scope statement and a work breakdown structure (WBS). On smaller projects, your project management plan can skip the risk and quality management pieces.

Let’s look at specific Project Management Plans recommendations for projects of different sizes.

Project Management Plans for Different Sized Projects

  • Tier #1 Small Projects: Done within one department for the manager who is your boss. The team members also report to that boss.
  • Tier #2 Medium Projects: Affect multiple departments and each department contributes deliverables. The final product benefits customers/clients or an internal user.
  • Tier #3 Strategic Projects: Organization-wide projects or initiatives. They affect a larger number of stakeholders and have long-term effects.

Project Plan Step #1: Identify Stakeholders

Tier #1 Small Projects: This step is not necessary on an in-department project where the manager is the primary stakeholder.
Tier #2 Medium Projects: Process to identify stakeholders across the organization. Prevents surprises when you must add late arriving requirements. These cost more at that point than if they were identified during initial planning.
Tier #3 Strategic Projects: Process of surveys and interviews to identify internal and external stakeholders affected by the project. You must consider their requirements. Project Management Plan

Project Plan Step #2: Project Business Case

Tier #1 Small Projects: This step is not necessary because you don’t need formal project approval.
Tier #2 Medium Projects: Organizations with sound project management processes require a business case. This justifies a project’s priority versus other projects in the portfolio.
Tier #3 Strategic Projects: The amount of financial and human resources requires detailed justification. That is based on the strategic impact and benefit of the project. Project Planning Turf Wars Video

Project Plan Step # 3: Project Charter

Tier #1 Small Projects: A 1-page broad brush plan is enough. Small Project Planning Techniques
Tier #2 Medium Projects: The project charter addresses the project business justification,  acceptance criteria, and rough estimates of the human and financial resource requirements.
Tier #3 Strategic Projects: The size of the investment in these projects usually requires extensive documentation. It includes the risks, benefits and impacts on other strategic initiatives and the entire organization.

Project Plan Step #4: Gather Project RequirementsProject Management Plans

Tier #1 Small Projects: Usually limited to a meeting with the boss where you define the project’s Measure of Success (MOS).
Tier #2 Medium Projects: You survey stakeholders for their requirements. After considering each requirement, it is either included or explicitly excluded from the project.
Tier #3 Strategic Projects: An extensive process of identifying and analyzing requirements gathered from the stakeholders. You also assess stakeholders in terms of their interests in the project and their ability to influence the project’s success (positively or negatively).

Project Plan Step #5: Project Scope Statement

Tier #1 Small Projects: A short statement of the project’s result and acceptance criteria.
Tier #2 Medium Projects: A more detailed scope statement that covers the major deliverables, assumptions and limits.
Tier #3 Strategic Projects: A full scope baseline developed. It includes explorations of different ways of delivering the project scope. Project Plan Approval

Project Plan Step #6: Stakeholder Management & Communications Plan

Tier #1 Small Projects: Not necessary with the limited stakeholder group.
Tier #2 Medium Projects: Communications plan developed. It takes includes the information requirements of the stakeholders.
Tier #3 Strategic Projects: Plan developed for meeting stakeholders’ communication needs. It requires actively managing and resolving all the stakeholders’ issues. Fast Track Project Planning

Project Plan Step #7: Project Change Control

Tier #1 Small Projects: Project sponsor approval is the only requirement.
Tier #2 Medium Projects: Use existing organizational process for change control (if it exists). Alternatively, develop a project-specific change control  procedure. It must include analysis and documentation standards and identification of specific individuals authorized to approve changes of a specific size.
Tier #3 Strategic Projects: Change control and configuration management are often combined for handling changes to project baselines as well as changes to the specifications of the deliverables.

Project Plan Step #8: Project Schedule

Tier #1 Small Projects: Schedule based on work estimates made by the team members.
Tier #2 Medium Projects: Schedule based on work estimates plus work packages for each assignment.
Tier #3 Strategic Projects: Work-based schedules, work packages with estimates and a work breakdown structure (WBS) dictionary.

Project Plan Step #9: Project Procurement

Tier #1 Small Projects: Usually handled by the purchasing department.
Tier #2 Medium Projects: Request for Quotations (RFQs) on smaller purchases. Competitive bids on larger purchases.
Tier #3 Strategic Projects: Full competitive bid process. Large Project Planning Techniques

Project Plan Step #10: Project Quality Management

Tier #1 Small Projects: Not necessary.
Tier #2 Medium Projects: Quality control effort to measure deliverables against their quality metrics and specifications.
Tier #3 Strategic Projects: Quality control plus active quality assurance. The latter is a continuous improvement effort for the processes that produce deliverables.

Project Plan Step #11: Human Resource Management

Tier #1 Small Projects: Not necessary.
Tier #2 Medium Projects: Simple resource acquisition plan with limited training provided to team members.
Tier #3 Strategic Projects: Human resource staffing, acquisition and team development plans are fully detailed. They are tied to gaps in a “requirements versus capabilities” analysis.

Project Plan Step #12: Risk Analysis

Tier #1 Small Projects: 1-2 hours total.
Tier #2 Medium Projects: Qualitative risk analysis with a risk response plan for 5 – 10 key risks.
Tier #3 Strategic Projects: Qualitative and quantitative risk analysis with a risk response plan for several dozen risks.

Consider our online project management courses to learn how to use all the tools and techniques for project management plans. You’ll work privately with an expert project manager as your instructor and coach. You begin when you wish and control the pace and schedule. You can have as many phone calls and live video conferences with your instructor as you wish. Take a look at the courses in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-management/it-project-manager-certification-111-113/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/business-project-management/business-project-manager-certification-101-103/” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-management/construction-project-certification/” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-manager-certification-131-133/” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-certification-141-143/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Posted on

Project Templates

Project Templates vs. Re-inventing the Wheel

Project templates can be a big time saver as long as they fit your project and your organization. The best way to secure templates that you can use on all of your projects is for you and perhaps a couple of other project managers to develop them yourselves.  It really doesn’t take a great deal of time and often project managers can pool and compare the formats and templates they use for the project scope, charter, stakeholder identification and so on.  Designing a common template obviously requires a little bit of compromise but it will save time for the project managers and the sponsors and stakeholders who will use these documents.  However, you should avoid at all costs the Excel template called “Factories” that sells hundreds of templates that supposedly “fit all projects.” They do not.

Project Managers are creative people and that’s a good thing. Without creativity, we would not be able to structure a project or react quickly to project templatesunforeseen challenges. However, it is also human nature to try to customize and alter things until they totally look the way we want them to or at least bear our undeniable mark. Unfortunately, this practice is not efficient and it might actually hinder your project success.  That’s why you reaching consensus on project templates with your PM colleagues is the best course.

Project Templates Save Time

We all hate those forms that we have to fill out to get a project approved and we don’t like the client’s format for project status reports. After all, we are experienced project managers. So why can’t the client use our artfully created project templates for the scope, charter, WBS, and status presentation? Of course we develop a new form for each project. If you work in an organization that always develops everything from scratch, please take a minute to read through the list below of the benefits of standardization. On the other hand, if you work in an organization with lots of standardization, these points might help you appreciate all the forms you have available. Obviously, over-standardization is an issue. But for the most part, having a standardized way of organizing, managing, and documenting projects has at least the following benefits:

Shorter Start-Up Time

If everyone uses the same project templates, everyone knows what to expect. Let’s call it the McDonalds Principle: No matter where in the world you buy a cheeseburger from McDonalds, its always the same: Two buns, one hamburger patty, a slice of cheese, a slice of pickle, mustard and ketchup. Customers know exactly what they’ll get when they order a McDonalds cheeseburger.

The same holds true for standardized forms and processes. Everyone knows what is expected and things can be compared, matched, and so on. All the decision makers in the organization know where to find the information they are looking for so they can make a decision more easily. Moreover, if you need to train a new PM, it is easier to show him/her a set of similar-looking project charters and plans than it is to analyze a set of completely different-looking documents. Last but not least, using tools that already exist and that have been tested by previous PMs will make it easier for you to start the actual project work. You need not wast time designing something that already exists.

Easier Lessons Learned 

Each project or project phase should end with a lessons learned session. Standardized requirements documentation, status reports, and plans make it easier to point out flaws and actually learn from our mistakes.

Easier Estimation Next Time

If all the projects in an organization use the same standards, it will be easier for PMs to use historical analysis for their next project’s estimations because they can accurately compare the current project with a previous one. The point I’m making here is this: Standardization has its place. Obviously, there is an extreme to that, but I hope you get my point. When starting with a new client, why don’t you ask your client if they have a standard for PM documentation?

Until next time.

Posted on

Project Disasters – Comedy Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Project DisastersIt takes a lot of work to make a project disaster as bad as this one. Our 4PM.com cast members show you how in a Project disasters comedy video about how to screw up a project.

The PMs and team members are preparing their failed project for a big project status meeting. You’ll see micro-managing PMs frantically hiding problems and berating team members for finishing early. Other team members point fingers at each other while sleazy executives maneuver for their political advantage.  Whacked-out IT staff members use a million phony excuses about why the system is late.  While the Human Resources people back-stab the Sales people to avoid blame for a  pointless employee survey. You’ll see all the things NOT to do on a project.

You’ll also see how the PM deals with the inept executive sponsor of the project, Mr. Lonegan. He starts more projects than the organization can possibly finish. His projects never have a clearly defined scope so the project managers and team members have to guess about what they think Mr. Morgan wants the project to deliver.  Because the project managers are not sure what Mr. Lonegan wants, they make very vague assignments to their team members. That way they can’t be blamed but the team member can.

The final icing on Mr. Lonegans’s disastrous cake is the red hot anger he directs toward any project manager or team member who admits to being late. Mr. Lonigan probably convinces himself that he is a dynamic leader with very high standards. In truth, Mr. Lonegan is a complete failure as a project sponsor. And he drags down and rest of the organization with him.

These characters may remind you of some of the people on your projects and the interpersonal challenges they give you. If you remember characters or situations from your experience, share them with others in the blog.

If you have outrageous examples of how to screw up a project, send them to us in a comment and we’ll try to work them into the next episode of 537 Ways to Screw Up a Project.

How to Screw Up Project: Status Reports

 

Posted on

Project Management Plan – Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Knowing how to create a Project Management Plan is tricky. The size of the project is not important. People mistakenly think that longer project plans are better than shorter ones. They think the plan’s word count reflects the amount of thinking that’s gone into the document. The opposite is usually true. In our 25+ years of managing projects, we’ve found that the more words in the project plan the less thinking has gone into it.

Here we’ll discuss what a good Project Management Plan should have in it and we’ll provide you with the tools to create one. If you have project managers reporting to you, we’ll give you information to let the PMs know what you want from their Project Management Plans. All the plans should follow the same general structure. Each project manager can make adjustments to their plan based on the scale and scope of their project(s). Project Planning Main Page

Here is a video that shows you how NOT to start a Project Management Plan.

Project Planning Blunders: Stakeholder Turf Wars

Project 

Project Management Plan: Size

The Project Management Plan doesn’t have to be a long document but it must cover some very important elements. The vital elements are the deliverables the project will produce and how they will be measured.  The first step is the hard part. Easier elements of the project plan are the schedule, budget, risk analysis, quality control, resource requirements and product metrics and specifications.

Project Management Plan: Elements

The sections of the Project Management Plan must detail how much project management the PM is going to do in each of the major areas. In the first section, the project manager must detail how he/she is going to manage the scope definition and scope change processes. The project manager lays out the process of defining the scope. That includes who will be involved, what techniques they will use and how long the process should take. They also define the procedure for making changes to the scope. This is one or two sentences about who will have the authority to approve changes and what documentation is required.

The project manager should also have plans for the project schedule, budget, risks, quality control, rsources and procurement management. In each of those areas, he/she should identify who is going to do these activities and what techniques they will use. The Project Management Plan may specify that the PM is not going to do any quality control or risk management because of the unique requirements or limitations of this particular project. That’s okay. There’s no sense in overburdening small projects with too many project management processes. A key element of the Project Management Plan is deciding what you’re not going to do.

The project sponsor should review these elements of the Project Management Plan to ensure that adequate controls are in place. They should include information on the frequency and level of detail in project status reports. They may decide that different groups of stakeholders need different kinds of information about the project. The sponsor may also want weekly data rather than monthly and the Project Management Plan will list all of these decisions.

Project Management Plan: Project Sponsor and Project Manager Time Investment

Project management planning begins during the initiation process. This is where the project plan is developed and approved. In general, the project management planning effort should consume 90% of the time the project sponsor invests in the project.

Project management planning should also consume about 60% of the time the project manager is going to invest in the project. That way, they can invest sufficient thought about the entire project, anticipate problems, and think through alternative ways of doing the project. Project Management Plan best practices call for a very detailed planning effort followed by execution. The project execution process should require a small amount of adjustment and adaptation. A thorough project planning process allows the PM to efficiently produce the project deliverables.

The Project Management Plan document itself can be as brief as one side of one piece of paper for a small project as long as it identifies the major deliverables, the most significant risks and provides rough estimates of the required resources’ cost and hours. In larger projects, the plan could be quite large. The most common mistake in project management planning comes when the project sponsor sees the plan as a waste of time and wants to start work as quickly as possible. The sponsor brushes off objections from the project manager with the novel idea of “planning as we go.” Starting project work without a plan is not the way to produce the needed project deliverables as quickly as possible. This approach causes a great deal of wasted time and effort. People produce the wrong deliverables and waste considerable amounts of time. They’re trying to figure out what they should be doing and how all the pieces should come together. Even in emergencies, starting work without a plan is a dumb thing to do. You will always finish earlier and produce better results with a thoroughly thought out Project Management Plan.

Project Management Plan: Stepsproject management plan

Follow these six steps to project management success:

  1. Project manager and sponsor define the project scope. It is a clear, objectively measurable deliverable.
  2. Project manager and sponsor decompose (break down) the scope into 4 to 7 major deliverables that are required to deliver the scope.
  3. Project manager and stakeholders further subdivide the major deliverables down to the level of individual assignments for team members. Each of these is also a deliverable, not an activity. The lowest level of deliverables is the work breakdown structure (WBS). The WBS is the basis for scheduling and other project management activities.
  4. Project manager and team members estimate the amount of work and duration that each task in the WBS will require. The team members should participate in these estimates so they have some “skin in the game” and commitment to their assignments.
  5. Project manager tracks actual results versus the plan. He/she reports variances and corrective action options to the project sponsor.
  6. As the project team produces each deliverable, the sponsor and stakeholders formally accept it. The project is over when the sponsor accepts the team’s last deliverable.

Learn how to create a Project Management Plan in our online Project Management Basics courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the course in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-management/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/business-project-management/project-management-basics/” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-management/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-management-2/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-management/client-project-basics-online-141/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Posted on

New Product Launch

You settled  down at a table in the company cafeteria with status reports on three of the projects in the program you were managing. You decided to start with the most problematic of your projects and opened that folder, managing to remove the staple with a knife without stabbing yourself. At a neighboring table, people from sales, marketing, production, engineering and accounting were having an intense, heated discussion. You knew all the managers involved and you’d had each of them as a stakeholder on more than one of your projects. You had at least a productive working relationships with new product launchall of them and two were your close friends.

Join a New Product Launch Meeting

One of the friends spotted you and waved at you to join them. As you took a seat you said, “From the gaiety, I would say you’re planning the holiday parties. Am I right?”
Your friend said, “I don’t make jokes at your project planning meetings. Our new product launch session is every bit as divisive.” Your friend looked around the group, held up his hands to all of them, and said, “I’m not trying to score debating points. I’m just trying to summarize everybody’s position on the new product launch.”
The rest of the group nodded but watched your friend warily.
“Okay,” he said, “my friends from accounting think this new product will lose money. They don’t think we can cover the fixed costs in the first two years. My colleagues from sales and marketing take issue with that. They say this new product could be a home run for the organization. The production managers think the new product is too complex to manufacture with a low defect rate. They are concerned that a high defect rate will cause this product to fail. Warehousing and shipping managers think the transportation costs are going to go through the roof because the salespeople want to promise 24 hour delivery.
You listened carefully and nodded at each of the managers as their position was stated.
Your friend turned to you and said, “Pretend this is a project. How would you address this? What do you call it, stakeholder conflict?”  Project Planning Main Page

New Product Launch as a Project

You laughed and said, “What you have here is a project; I don’t need to pretend it’s one. But it’s a project without a defined scope. The scope is what the product will deliver to the organization; its goal. You’re arguing about various deliverables without any framework to define them. Can I ask a couple of questions?”
All the people at the table looked around a bit uncomfortably and then nodded.
“Okay. Am I correct that the goal of this new project is to generate a positive cash flow for the organization?”
Everyone nodded and a few made faces at the obvious statement.
You continued, “How much cash flow do you need to generate in each of the first five years for this project to be a success?”
A manager from sales said, “That depends on how many units we sell.”
You smiled and asked, “How many units are you committed to selling in each of the next five years.”
He replied, “That depends on the price and the features we can offer our customers. That’s the way sales works.”
“Humor me,” you said. “Tell me how many units you can sell if the product contains a specific set of features and a specific production cost.”
The sales manager shook his head angrily, “You’re asking me to go way out on a limb here.”
You smiled and said, “Well eventually you have to commit to how many units you can sell. That allows everybody else to plan on how many units they have to produce and ship.”
The irritated sales manager looked at you and said, “That’s not how marketing & sales works. We sell as many as we can and everybody else has to adapt.”
There were loud groans from production, engineering, accounting, shipping and warehousing.
“It seems to me,” you said, “that there is some disagreement with that approach. I can see how the volume of your sales is going to have a drastic impact on these other parts of the organization. So it’s reasonable that they want to know what sales level to prepare for.”
The sales manager said, “You don’t understand. This is not project management. We can’t specify in advance how many units we’re going to sell because the market is far too turbulent. And we can’t anticipate all the actions of our competitors.”
“You make your point eloquently,” I replied, “but I’d be surprised if good product development procedures let the marketing and sales people off the hook on hitting a sales target.  Having that data and your commitment to it is the only way to start this new product launch. You don’t have to consider it a project but you must follow certain procedures. Like any business person, you come up with an idea for a new product that you think makes sense for the market. That’s what we call a business case. In that document, you justify this product by making commitments to the following:
  • the number of units you can sell
  • the profits
  • the investment
  • the people resources it requires.

That’s what the executives look at decide whether to approve or disapprove this new product. They’ve got to know it makes sense financially, operationally, and in terns of capacity and human resources. I’d imagine, just like in project management, there are other new product ideas or other investments that the executives have to weigh versus your new product.”

The accountants started clapping first, then the operations manager said, “You mean we’d be able to plan production levels based on a sales forecast?”

You nodded at all of them and said, “Right. This is the project management world. New project launches aren’t begun without first being justified. Most importantly, the people who want the project need to make commitments to the benefits the project will produce. They have “skin in the game.” That’s what makes the business case process so worthwhile. Once you get agreement on the scope of the new product (the project), I’d be happy to help you break it down into the production costs, delivery costs, personnel costs and so on. All of them will be part of your network of product deliverables.”

You looked around the table at their approving faces.

Posted on

Strategic Vision vs. Project Myopia

Too often project managers get lost in the minutia and don’t have strategic vision for the project. They don’t see the big picture of how the project deliverables will affect the organization as a whole. In our work with over 300 organizations, this is one of the biggest concerns that client executives have about project managers. That is particularly true of project managers with an engineering or software orientation. The executives’ concern is that the project manager does not see the customer or the product or the larger organization. Instead they dive headfirst into the barrel of technical details.

It’s important to understand your project’s role in the organization’s top level strategy for reaching its goals. Strategic visionThis is true whether you’re assuming ownership of a project that’s underway or starting one from scratch,  Without that strategic vision, your project runs the risk of satisfying its own ends but disappointing the organization and/or the sponsors that supported it.  And that’s not a good thing.

Sources of Strategic Vision

So how do you apply strategic vision at the project level and see the big picture?  As a project manager, you need to have a good grasp of your organization’s long-term goals.  Your project charter should provide that linkage and you may want to clarify that in the project plan by directly describing how the project’s desired outcome supports the strategic goal(s).  If this connection is not made or isn’t clear, you may be only a few well-intended—but unfortunate—decisions away from providing results that don’t meet the project sponsor’s intent.

Questions to Gain Strategic Vision

You should ask yourself the following simple questions and keep them in mind as you execute your project. They will help you maintain that strategic vision and keep your project on track.

1.  Exactly how does my project support the organization’s strategic goals?  How do the project’s requirements and deliverables relate to the strategic goals?  Consider how much flexibility the deliverables can bear before they no longer support the goal(s).  You may even establish a threshold beyond which the project should be reassessed and/or revised.

2.  How will my project’s success be determined?  Success criteria should be spelled out in your scope statement.  If set correctly, success criteria directly support the desired business outcome of your project. By extension, they support the sponsor’s strategic goals.  If you must adjust success criteria due to approved requirements changes, make sure this linkage to success criteria, desired business outcome, and strategic goals remains intact.

3.  Where does my project fit in the organization’s strategic activities?  View your project from the outside. From a broad, strategic perspective, how does your project align with other projects addressing the same or related goals?  There are both benefits to be gained and pitfalls to be avoided from this exercise.  For example, you may discover the potential for synergy with another project, or at least opportunities for mutual support of a strategic goal.  But you may also discover redundancy or interdependencies that must be acknowledged and dealt with.  At a minimum, you will gain valuable insight into the tactical role your project plays in supporting the overall strategic goals of the organization.

4.   What is the long-view of my project?  As project managers, we often become mired in the here-and-now issues that demand our immediate attention.  Without meaning to, we may lose the ability to see our project in the long-term and not recognize when we have strayed from our core purpose.  It is important, maybe even critical, to allow yourself time now and again to look far downrange and make sure that the course you are on isn’t leading to the wrong destination.

5.  Do I truly understand my project’s cause and effect relationships?  By dwelling too much on low level management of daily project operations, it’s easy to miss or underappreciate cause and effect relationships that stretch beyond that myopic perspective.  Problems you’re dealing with today may have roots far in the past, maybe even preceding your appearance in the project.  As a project manager with “strategic vision,” you’ll have the ability to step back and understand the full scope of that relationship. That will allow you to address it appropriately.