Posted on

What is Project Leadership? – Video

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

What is project leadership? It consists of proven techniques that project managers use to:

  • set standards of behavior and performance
  • motivate the team members to high performance and
  • rally the team members when the project has problems to overcome.

These tasks are particularly challenging because most project managers are technically- oriented people with little experience or skill in motivating others. Another factor that makes project leadership difficult is that the project manager often has very little or no formal authority over the project team. The lack of formal organizational authority is the number one challenge to project leadership.

Project managers must tailor the interpersonal techniques they use to fit the personality of each team member and stakeholder with whom they work. That’s the only way project managers can make up for their lack of formal authority.  Once they have “typed” the person’s personality and selected the right techniques for dealing with them, they have won half the battle. Here is a video on Team Member Personality Types

Another technique of effective leadership is to apply the best practices in terms of how the project manager trains and treats their project team members. Watch this video of a PM dealing with a situation where a team member has been pulled off the project and assigned elsewhere. In the first video, you see the PM use a technique that does not fit the personality of the team member. The result is complete failure. Then watch an analysis and see the PM do it the right way, using the right technique for the team member. Leading Teams

Communicating with the team member who has a problem

You can learn all of these skills in our online project management basics course. We individually tailor this course for business, IT, construction, healthcare and consulting specialties.

[button link=”https://4pm.com/product/project-management-basics-101/” style=”info” color=”red” window=”yes”] Project Basics[/button]

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

[button link=”http://162.144.114.198/~jwkdwgmy/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-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/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Get free articles and videos like this every week

 

Posted on

What is Project Management and How To Do It

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

What is project management? It’s a process for producing a predefined result, called a deliverable, on time and within budget. A deliverable can be a highway, an office building, a computer software, a medical records system, a book, a full-length movie and many other things. A project has a specific start and finish date. It is not an on-going effort like managing the organization’s accounting department.

What is Project Management: It Involves Special Techniques

There are special techniques for managing projects and they start with creating a plan. The project plan is a document that details what the project is going to deliver (the scope). It is created by the person who wants the project done (the sponsor) and the person who will manage the effort (the project manager). It also defines what resources the project manager needs and how he/she will manage the people working on the project. The project manager meets with people affected by the project, called stakeholders, and learns what they require the project to produce. As the project manager breaks down the scope and requirements into smaller deliverables, they are developing a pyramid of clearly defined deliverables that lead from the smallest tasks up to the largest deliverables. At the top of the pyramid is the project scope. Good project managers focus on deliverables that are defined by metrics.  Here’s an example of a deliverable defined by a metric, “Design a payroll data entry screen with 25 data fields that allow payroll clerks to enter 65 payroll transaction per hour.”  A deliverable that is based on metrics has a number of very important benefits. First, when the project manager assigns deliverables to the project team members, they know exactly what is expected of them before they start work. They don’t have to guess or worry about failing on their assignment because the PM has defined what a good job is in measurable terms.  With that type of assignment, a team member can break it down more accurately and use their experience to plan their approach to their deliverable.

Second, using deliverables as the basis for the project lets the project manager and team members develop much more accurate estimates of the duration anWhat is a Project Managementd cost of each task. It also lets the PM determine how long the entire project will take and what it will cost. Another effective tool is the work package. The project manager should give each team member a work package which describes their deliverables and details the risks and other factors that will affect their assignment. Then PM and team member use that same work package to develop an estimate of the amount of work in their deliverable(s). This gives the team member something very much like a contract; it explains the expectations the team member must meet.

Third, managing a project that is built with deliverables gives the PM unambiguous checkpoints to measure how the project is doing versus the approved plan. Each deliverable has a crystal-clear and measurable definition of success so the project manager, sponsor and stakeholders don’t have to guess about the project’s progress. After the project plan is approved, the PM executes it by assigning work to the team members to ensure all the project deliverables get produced. As the team is working on their deliverables, the PM is monitoring their progress, controlling the project schedule, budget and scope and solving any problems. As part of this monitoring and controlling process, the project manager makes periodic status reports to the sponsor who initiated the project. During the executing phase, deliverables are reviewed and accepted as they are produced. The project stakeholders and sponsor examine what the team produced, compare it to the specifications and accept or reject the deliverables. The PM doesn’t wait until the end of the project for the stakeholders to review the deliverables. He/she does it as they are produced so they can identify and fix problems early.

Fourth, with measured deliverables as a basis for the project plan and schedule, the project manager can do a better job quantifying the impact of change requests. Using the example above, if the user wants to increase the number of fields on the payroll data entry screen from 25 to 30, the PM can use the metric along with project software and revised work estimates to quickly assess the impact of this change on the project budget and completion date.

After the last of the deliverables has been produced, the project manager closes the project by verifying with the sponsor that the project delivered what they wanted. The project manager will also archive all the data generated by the project so it can be used by other project managers in the future. That information will make it easier to plan similar projects.

What is Project Management: It’s Leading and Managing People

In addition to these planning and workflow management techniques, the project manager also has to lead, motivate and manage the project team. And they must build support from other executives in the organization for the project. Last but not least, the project manager has to “manage” the project sponsor who very often will outrank the project manager by several levels. Managing the sponsor requires a great deal of subtlety and tact if the project manager is to ensure that the sponsor plays their important role in defining the scope and controlling the project.

To learn more about how to use these tools and techniques, consider our online project management courses. You begin whenever you wish and work privately with Dick Billows, PMP, an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.

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

How To Deliver a Status Report

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

The way you deliver your status report determines your credibility with the sponsor and stakeholders. It impacts their level of comfort with the project itself and your ability to manage it. You need to clearly and succinctly answer the questions the sponsor and stakeholders have about the project.

Status Report: Common Questions

You should answer their questions in the first five minutes of your project status presentation or in the first paragraph of your written status report. The four questions are:

  • Will the project produce the deliverables promised in the scope statement?
  • Will it finish on time?
  • Will it cost more or less, than what was budgeted?
  • Do the team members and vendors working on the project know what you expect of them? How to Write a Weekly Status Report

Status Report: Answer Questions

You should immediately answer the four questions above and discuss the problems as well as what you can do about them. How do you answer those four questions? With language that a 10-year-old child could understand.  The answers should not assume any knowledge about the project or what people said at the last status meeting. Why does it have to be that simple and straightforward? Because project managers are often their own worst enemy when they deliver status reports. They incorrectly assume everyone in the audience is as familiar with the project as they are. Status Report Template

Status Report: State Problems and Solutions

If you delay in answering these questions at the beginning of the report, people will think you are hiding something. If there are problems and variances to the plan, you should disclose them at the beginning of your status report. You need to tell people what you will do about the problems and variances and what help you need to take corrective action. You must also quantify the trade-offs between the project scope, budget and duration to solve the problems. If you can’t fix the problems, you must tell them. The sponsor and stakeholders must have confidence that you will reveal the problems as soon as you know about them. What they hate the most are problems that surprise them late in the project. Most executives will think you hid the problems for weeks or months and revealed them only when you could no longer hide them.

Status Report: Be Brief

Project managers tend to provide too much data and they assume everyone understands it. They also tend to “deep dive” into the technology of the project itself, using acronyms and discussing technical issues until the audience is bored to death. Some project managers assume this detail is the way to build their credibility and the stakeholders’ confidence in them. The opposite is true. The stakeholders think the PM is a technical geek who has a very weak grasp on what’s happening in the real world.

When a project status report confuses people, they assume the worst. They assume the project is out of control, that no one is monitoring the work and that the team members are equally confused and lost. They also assume that they are hearing only the tip of the iceberg and that many other problems are being hidden. As a result, they have little confidence in the project manager’s analysis of problems and recommendations for corrective action.  Earned Value

Status Report: Use Visuals

You can avoid this situation by using simple visual communications with the sponsor and stakeholders. Don’t assume they are as interested in the technical details of project management and the project work as they are. None of these assumptions are ever true but project managers often make them. Effectively communicating with stakeholders and sponsors requires you to use easily understood visuals that communicate the project status. The worst thing to give your audience is the classic project variance report which has 12 or 15 columns and lists every task in the project. This chart compares the planned start date with the actual start date, the planned finish date with the forecasted finish date and so on. No one can get an accurate picture of what’s going on in the project from that kind of data. Project Variances

You need to have visual charts and graphs that people can look at and understand in a moment. The Tracking Gantt chart available in many commercial software packages is ideal forStatus report this purpose. It has a bar chart for every task in the project. It shows when the task should start and when it should finish, usually in gray. Each task also has a second bar, usually in blue, which shows when it will start and when it will finish. If these two bars are stacked on top of one another, the task is on schedule. The red bar is the critical path which is the longest chain of tasks. It depicts the project’s actual start date and the projected finish date. This visual display lets everyone quickly see where the problems and opportunities are. It also makes it easy to explain your options for corrective action. Project Tracking Software – Video

Status Report: Tailor It to Your Audience

In addition to visual aids that tell the story with pictures, you also need to tailor the status report presentation to your audience. If the attendees are all expert project managers, the status report can be concise and fact-filled without explanations. If the audience is composed of stakeholders who have had little exposure to projects or project management, you must explain the basics. You can’t assume everybody knows as much about the project itself or project management best practices as you do.

Another issue is designing the presentation to fit the personalities of the attendees. If the audience is composed of technical staff who are very detail oriented and value a chronological presentation with plenty of data, you will have one type of presentation. If the audience is composed of “big picture” thinkers, you need to present the end results first and then offer as much supporting detail as the audience wants. If you get into too much detail for these people, they’ll quickly leave the room.  Team Status Reports Video

You can learn all these status reporting skills in our online Project Management Basics courses. You work privately, one-to-one, with a expert project manager.

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

Project Plan Template

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

You can use this project plan template to define the project scope and identify major deliverables. You can also use it to manage the project risks and constraints as well as the resources it requires. On every new project, you need to decide what Project Plan Template elements to include, what to exclude and how to develop them on each particular project.   For 90% of the projects done in most organizations, your project plan should be 1–2 pages long. Managers are more likely to read a short, concise document.

Project Plan Template 1st Step – Define the Scope

You need to define the project scope as a deliverable with measurable acceptance criteria. To do that, you talk with the project sponsor, ask questions and then develop the scope statement. Next you define 4 to 7 high-level deliverables and their associated acceptance criteria. Those criteria tell everyone exactly what the project must deliver. They also help you control expectations by making it clear what the project will and won’t deliver. Fast Track Project Plans

When you ask the sponsor what he or she wants, they might say something like, “We really need to have this project cut costs for us.” You immediately try to get to quantified acceptance criteria by asking, “How much cost reduction would make this project a success?”

When the sponsor says, “$15,000 of cost reductions,” you have the scope definition with an acceptance criterion that tells you how much cost reduction the project has to deliver. This is the key to the project plan template. You can then drive the rest of the project from that number. (On larger projects consider the scope reach) How to evaluate a project plan

This is a simple example of top-down planning but most project managers don’t ask the right questions. They are satisfied with a To Do list of the first dozen things the project sponsor wants them to do. That is a terrible basis for your a project plan and it’s disastrous if you start work with no more information than a To Do list. To successfully plan a project and have high odds of project success, you need to know what the boss wants in measurable terms.  How to Plan Top Down

Project Plan Template 2nd Step – Define Major Deliverables

You then break down the measurable project scope into its major supporting deliverables.  There are several different ways to do this. The simplest is where the high-level deliverables literally add up to the scope and its acceptance criteria. Therefore, in a conversation with the sponsor, you might talk about how to break down the scope. The sponsor might say, “I want each department to develop their share of the overall savings.” During further discussion, you might identify the savings amount for each of those departments. You use them as your high-level deliverables with the acceptance criteria being the dollar amount of savings each department has to produce.

You see the major deliverables below and how they add up to the project scope of $15,000 of cost reductions.

  • Reduce order intake monthly operating expense by $4,000
  • Reduce production monthly operating expense by $2,000
  • Reduce order production monthly operating expense by $3,000
  • Reduce inventory monthly operating expense by $2,000
  • Reduce shipping monthly operating expense by $4,000  project plan template

Project Plan Template 3rd Step – Identify Major Risks

Depending on the size of the project, you may invest a great deal of time identifying the risks that threaten the project. You can do this in brainstorming sessions with the project team and stakeholders. But on a small project, you might develop your list of risks over coffee. In either case, you’ll include them in the project plan along with ideas for mitigating those risks. See example risks you would enter into the project plan template below:

  •  Layoffs may result in labor actions which disrupt operations
  •  Production may drop as much as 25% for 3 – 5 months.

Project Plan Template 4th Step – Identify Project Team Resource Requirements

Using the major deliverables, you now identify the number of hours of work and the skill sets required to create each deliverable. You would total those estimates up to the level of the entire project and make very rough estimates of the people and skills required. Below are examples that you would enter into the project plan template.

  •  Bill – full time 3 months
  •  Mary – half time 2 months
  •  Raj – full time 3 months
  •  Sharmaine – quarter time 4 months
  •  Henry – full time one week

Project Plan Template 5th Step – Break Down to Individual Tasks

The last of the five steps in creating the project plan is to decompose those major deliverables developed in the second step. You break them down into smaller deliverables until you reach the level of a deliverable that’s an appropriate assignment for one team member. That’s the level of your work breakdown structure (WBS). It completes the project planning process in the project plan template. Then you can move on to the scheduling process.

Project Plan Template in Practice

In many organizations, project planning is a combination of vague generalities about the objective of the project. But the one thing that is often rock solid is the completion date. That date is frequently the only measurable project result. Because project managers don’t know what the executives want them to deliver, they have no ability to exercise control over the scope of the project. As a result, the objectives change weekly. Project team member assignments are vague and ever-changing. That is why estimating is inaccurate and why 70% of projects fail when they are planned that way. Let’s look at the best practices for project planning and then look at a project plan template for projects of different size.

Project Plan Template “Best Practices” In the Real World

Very often, project managers face a difficult organizational environment. The organization lacks the processes to do project management right and the executives don’t know how to play their role correctly. In these situations, the PMs need best practices that allow them to do things effectively, even though the executives and the organization’s processes are obstacles and not assets. The project plan template will help. The purpose of this intense project planning process is to make all the decisions before starting work. The approach of making the project plan and then executing it is much more efficient than a “plan as you go” process. However, it is very difficult in many organizations.

For this approach to work, the organization, its executives and project managers must do things correctly. That is, the executives must specify exactly what they want the project to deliver. They cannot make the project assignment using vague generalities where the only thing that is specific is the due date. The organization must have processes for evaluating and prioritizing projects and giving them access to resources based on those priorities. Last, the project managers must know how to do top-down project planning. That means they are able to take the clear acceptance criteria, specified by the executive/sponsor, and decompose it down to the level of specific assignments for each team member. Most organizations fail to meet one or more of these criteria and that is why we rarely see an ideal project planning process. There are two major ways to go Large Project Planning Techniques or for less paperwork and meetings,  Small Project Planning Techniques.

Project Plan Templates by Scale of the Project

We utilize three tiers of project plans techniques in the project plan template. They depend on the scale and complexity of the project:

  • Tier 1: Small Project Plans – Done within a department with the boss as the sponsor.
  • Tier 2: Medium Project Plans – Affect multiple departments or done for customers/clients.
  • Tier 3: Strategic Project Plans – Organization-wide projects with long-term effects.shutterstock_96175697

Identify Stakeholders

  • Tier 1 – Identifying stakeholders is not necessary on an in-department project where the manager is the primary stakeholder.
  • Tier 2 – We must identify stakeholders across the organization and find out their requirements early. Requirements cost more late in the project than they would have at the beginning.
  • Tier three – Requires an elaborate process of surveys and interviews to identify internal and external stakeholders so we can consider their requirements.

Project Business Case

  • Tier 1 – We often skip this since we don’t need formal project approval on an in-department project.
  • Tier 2 – Organizations with sound project management processes require a business case to justify a project’s priority versus other projects in the portfolio.
  • Tier 3 – The scale of financial and human resources usually requires detailed justification and demonstration of the strategic impact of the project.

Project Charter

  • Tier 1 – A 1-page broadbrush plan with achievement network, risks, resources and PM authority.
  • Tier 2 – This project charter addresses the project acceptance criteria, business justification and rough estimates of the resource requirements (human and financial).
  • Tier 3 – The size of the investment in these strategic projects usually requires extensive documentation of risks, benefits and impacts on other strategic initiatives and the entire organization.

Gather Project Requirements

  • Tier 1 – Usually limited to a meeting with the boss where the PM defines the project’s scope and decomposes it into the major deliverables.
  • Tier 2 – We survey project stakeholders for their requirements. Each requirement is reviewed and either included or explicitly excluded from the project.
  • Tier 3 – We follow an extensive process of identifying and analyzing requirements gathered from the stakeholders. It includes assessing stakeholders in terms of their interests and their ability to influence the project’s success.

Project Scope Statement

  • Tier 1 – A short statement of the project’s desired result and the acceptance criteria.
  • Tier 2 – A more detailed scope statement that also covers assumptions, constraints and the major deliverables.
  • Tier 3 – A full scope baseline development with exploration of alternative means of delivering the project scope.

Work Breakdown Structure (WBS)

  • Tier 1 – Decompose high-level deliverables into the deliverable for each team member’s assignment.
  • Tier 2 – Decompose high-level deliverables and use WBS sections from previous projects that are similar.
  • Tier 3 – Usually developed in sections with the people responsible for that major deliverable doing the decomposition.

Project Plan Template Summary

This project plan template uses a five-step project planning process. You can modify the planning to fit projects of different sizes depending on their complexity. You can learn to use this template 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

Project Charter Template

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

Use this project charter template to create the charter at the end of the project initiation process. This is after you have the scope information, the statement of work (SOW) from the sponsor and before the detailed planning begins. It includes the following:

  • scope
  • major deliverables
  • assumptions
  • constraints
  • risks
  • required resources and
  • change control.

 Starting work is still a ways off and this is the best time to discuss potential risks and problems with the project sponsor. You should also discuss your authority to assign work to borrowed team members and the availability of those resources. You need to be sure the project team will show up to do the work when they’re scheduled.

Other issues you should address are the scope’s underlying risks and assumptions. You can use the project charter template to identify those assumptions and risks. Then talk with the sponsor and stakeholders about how you can avoid or mitigate the risks. You should do this before the detailed planning begins. It’s easier and cheaper to include responses to the risks now than it will be later on. The project charter template should also include a process for making changes to the project plan. Everyone needs to understand that there is a process that includes an evaluation and approval before the plan can be modified. Project Phases Main Page

Project Charter Template: Cross-functional Authority

The project charter template should also address cross-functional authority issues. But that issue often gets lost among the assumptions and “mission statement” narrative. Even when PMs generate a concise decision-making document, they are vague about the authority they need to successfully manage the project. They want to avoid conflict over this touchy subject. But if you are a savvy PM, you know this conflict is inevitable. It is better to have the debate on authority now than to wait until the project is late and over-budget. It looks like you’re shifting blame if you explain slippage by finger-pointing at cross-functional resources. You need to specify in the  project charter how you will assign work to people from across functional or organizational borders. You should design an achievement network that maps the lines of accountability and shows the sponsor and stakeholders where you need authority. You must make crystal-clear assignments to the team members that are measurable achievements.

You can’t expect to have dedicated resources you can manage as subordinates for all the project project charter templateassignments. So you have to make careful choices. You should ask for direct authority for assignments that are:

  • on the critical path
  • are high risk
  • have a long duration
  • require rare skills.

You can live with indirect authority and even settle for “in the hopper” authority on shorter, less critical assignments. This means your request for resources goes “in the hopper” with all other demands for resources. If you ask for too many dedicated resources, it will backfire. You’ll be stuck with “in the hopper” authority for every assignment on your project.

Project Charter Template: Project Sizes

The project charter template requires some information gathering.  You have choices about which elements to include.  You also have to decide how much detail to give on the elements. As we said earlier, everything flows from the Statement of Work (SOW) that the sponsor  issues to get the project started. Let’s look at initiating a project, the project charter template document, and how you’ll complete the pieces for projects of varying sizes:

Tier 1: Small Projects – Done within an organizational unit. Your manager or your boss is the sponsor

Tier 2: Medium Projects – Projects that affect multiple departments or are done for customers/clients

Tier 3: Strategic Projects – Organization-wide projects with long-term effects on all departments.

Project Charter Template: Identify Stakeholders

Tier 1: Small Projects: This step is not necessary on an in-department project where the department manager is the primary stakeholder.

Tier 2: Medium Projects: You must make an effort to identify the stakeholders in multiple departments. This avoids getting surprised by late arriving requirements that must be added.

Tier 3: Strategic Projects: This step is a process of surveys and interviews to identify internal and external stakeholders who may be affected by the project. Their requirements must be considered.

Project Charter Template: Business Case

Tier 1: Small Projects: This step is not necessary because formal project approval is not required.

Tier 2: Medium Projects: Organizations with sound project management processes require a business case to justify a project’s priority versus other projects in the portfolio.

Tier 3: Strategic Projects: The level of financial and human resources requires detailed documentation and justification of the strategic impact of the project.

Project Charter Template: Scope, Deliverables  and Risks

Tier 1: Small Projects: A 1-page overview of the plan that includes the scope, deliverables, risks, resources and PM authority.

Tier 2: Medium Projects: The project charter document addresses the project acceptance criteria, business justification and rough estimates of the resource requirements (human and financial).

Tier 3: Strategic Projects: The size of the investment in these projects usually requires extensive documentation of risks, benefits, impacts on other strategic initiatives and on the total organization.

Project Charter Template Summary

Depending on your environment, the project charter template can include many components. The charter usually has a statement about the scope or statement of work (SOW) and the principal risks and assumptions that underlie the project plan. It should also include the processes for identifying and approving changes to the project scope. In addition, the project charter template should specify what resources the project plan requires and the project manager’s authority to manage those resources. You can learn how to prepare and present your project charter in our Project Management Basics course. You’ll work privately with your instructor and have as many e-mails, phone calls and live video conferences as you need.

You learn all of those skills 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 courses 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

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

Requirements Gathering Blunders and Best Practices

Many project failures are caused by poor requirements gathering techniques. These blunders cause three separate problems for the project and each one can increase the project’s cost and duration and lower the users’ or clients’ satisfaction. Every week stakeholders submit requests for new or modified requirements because

  • The project deliverables are not meeting their needs
  • The project manager disagrees with stakeholders about whether certain features and functionality are included in the project’s scope of work.
Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Sometimes these problems are minor annoyances. Other times they’re expensive and hard to correct. Here are the classic errors you should not make when gathering stakeholders’ requirements. Requirements Main Page

Requirements Gathering Blunder #1: Secret Requirements Meetings

Some project managers think that the assembly of project requirements and specifications should be done in secret so there is no interference from users. They believe the requirements gathering process is more efficient when it’s done by technical experts, not the users or the clients. Their reasoning is that the users/clients don’t know anything about the technology at the heart of the project. So why waste time explaining it to them? The PM and technical experts will develop the requirements quickly and efficiently and then explain the results of their work to the users/client. This thinking is often based on war stories of previous battles over requirements and project deliverables with the same users/clients. The attendees at the secret requirements meetings also want to avoid listening and learning about the users/clients’ business requirements. They hope to apply their technical expertise very narrowly and give the users/clients an elegant technical solution.

These secret requirements meetings sometimes get the active support of executives who want to start work quickly and not waste a lot of time on meetings and paperwork. They also don’t want to give the users/clients control of the project by letting them specify the requirements and deliverables.

The consequence of this approach is a great deal of conflict and, most importantly, a lot of wasted time and money. The project team will undoubtedly produce deliverables that don’t meet the users/clients’ needs or lead to improvement in performance. Unfortunately, this is a downward spiral that organizations often repeat.

Requirements Gathering Blunder #2: Requirements are Just Technical Specifications 

In the second blunder, the project team experts produce a complex list of requirements and specifications that the user/client is asked to sign off on and approve. For some odd reason, the project manager believes this process will protect them from criticism if the user is unhappy with the project deliverables. In the real world, the conversations go something like this:

Dissatisfied User: “These deliverables are not giving us what we told you we needed! They do not meet the needs of our business. We told you what we wanted and you have not given it to us. This crap is useless!”

Project Manager: “But you signed off on the technical specifications and requirements that we gave you. I have a document right here and that’s what we delivered.”

Dissatisfied user: “We had absolutely no idea what that technical gobbledygook meant. We told you what we needed to improve customer service and you have not given us the tools we need.”

Project manager: “I have the signed document right here.”

Dissatisfied user: “Good.  You can show it to my boss when I tell him about all the time and money you’ve wasted turning out garbage.”

The advantage the PM perceives from compiling the list of requirements and technical specifications is that it saves the project manager and team from listening to and understanding the stakeholders business and the business problems they want to solve. Obviously, that is not an advantage. Project managers need to aim the project deliverables at the customer’s business needs, not at a sheet of technical specifications. Unfortunately, project managers often combine blunder #2 with blunder #1.  Then the projects resemble the trench warfare of World War I.

Requirements Gathering Blunder #3: Let’s Make Up a Shopping List

This blunder is friendlier and happier, at least initially, than the preceding choices. But the project result is similar. These blundering project managers approach requirements gathering as if they were making up a shopping list. They go around and ask the stakeholders and other people what they want, then add it to the list. Several bad things happen with this approach. First, they tend to miss requirements and find out they’re missing after they have started work.  That causes delays. Second, people add things that may be good ideas but aren’t needed to produce the scope.  That wastes time and money. Third, people get in the habit of adding things to the project without justification. And that never stops, even after the PM has begun to execute the project plan.

So the PM gets many change requests people expect him to add.  They’re disappointed if they are not. The PM must do a good job limiting what is included in the project plan based on a clearly defined scope. Overruns are the result when they don’t.  If people think they can add things to the project plan whenever they wish, the project will suffer from scope creep. This means its duration and budget will grow every week. That’s when the stakeholders and other people become unhappy.

Requirements Gathering Best Practice: Prototyping

Another way to gather requirements is by prototyping, which may or may not be a blunder.  With this technique, the project team does some requirements gathering, then goes to work, and produces the initial project deliverables. Then the user/client evaluates the prototype and tells the project team about the prototype’s flaws. The team goes back to work to fix those issues. Then they produce another prototype for the user/client to evaluate, and the cycle goes on. Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Proponents say this produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype. More on Prototyping

Requirements Gathering Best Practices

The right way to handle requirements gathering is to have a crystal-clear scope of the project deliverable and the major deliverables that lead to it. Each of these deliverables is defined with an acceptance criteria so you are not dealing with a vague “to do” list. The entire requirements gathering process should be constrained by these criteria which are objectively measurable. Then the user/client justifies their requirements by showing the PM why they are necessary to produce the specified deliverables. If a stakeholder can’t link a requirement to a deliverable, it’s not included it in the project plan.

Let’s look at an example. This company has lots of complaints about their service. Many are tied to the fact that 20% of the customers have to call back repeatedly to get their problem resolved. So you will start by working with the project sponsor to define the acceptance criteria for improvements in the company’s telephone and web-based customer service process. You come up with acceptance criteria for the scope which is “Fewer than 3% of customers have to contact us a second time about the same problem.”

Next you work with the sponsor & senior stakeholders to detail the high level deliverables that are required to move the company from where it is now to the scope definition. That is, to go from 20% of the customers to fewer than 3% of the customers have to call back a second time about the same problem. Those high-level deliverables are:

  • Customer service system provides 18 months of customer transaction and complaint history in less than five seconds
  • Customer service cubicles have an average peak noise level of 72 dB
  • 95% of the customer service reps can answer the top 30 inquiries in less than 45 seconds
  • Customer service hourly staffing creates maximum workloads of 85% of capacity.

The above acceptance criteria give you the tools to constrain the requirements gathering. You link every requirement with one of those major deliverables or the lower level deliverables that support it. You keep track of who requests each deliverable and the performance commitment they made.

You work on requirements gathering at the beginning of your project planning phase.  The requirements are necessary for many other project management tasks. You can gather your project requirements very simply or have a much more elaborate requirements process where you track the originator of each requirement and tie it to their performance commitments.

A very common mistake when gathering requirements is to treat the process as simply making a list of everything everybody wants. This tends to keep people happy because they can add anything they wish to the project. However, you will suffer the consequences of stakeholders adding additional requirements every week. This is the classic form of scope creep where you continue to add new features, bells and whistles to the project. This process also substantially increases the project failure rate. That’s because you usually will not get additional time or resources to fulfill those requirements. So the project will be late and over budget.

Requirements Gathering: Step-by-Step

  1. Immediately after the sponsor approves the scope, you use the information about the identified stakeholders to conduct initial requirements gathering meetings.
  2. You meet with the stakeholders to discuss their requirements for producing the major deliverables of the project. You are not compiling a wish list. Instead, the discussion focuses on each of the major deliverables and what is required to produce them.
  3. You put every suggested requirement through a test of whether it is necessary to produce one of the project’s deliverables. If the requirement is a good idea, but not necessary to achieve the project’s scope, it is not included.
  4. You meet with as many stakeholders as possible with the intent of unearthing all potential requirements. Many of these requirements will not be included in the project plan. However, it is good to identify them during the beginning of the planning process rather than finding out about them late in the project.
  5. For every requirement that is included in the project plan, you complete the requirements register, which documents the individual who is accountable for the requirement. This documentation maintains traceability back to the originator of every requirement in the plan.
  6. When you and sponsor have considered all of the requirements and either accepted or rejected them, you and team can proceed to the development of the work breakdown structure.

You can learn how to gather and manage project requirements in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier. We also offer this Basics course for IT, construction, healthcare and consulting project managers.

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

What Is a Project

Dick Billows, PMP
DicK Billows, PMP
CEO 4pm.co

Wondering about what is a project and what is not? Here is an example of a project.

The manager of the department you work in tells you the people are wasting time getting supplies from the supply room. He wants you to do a project to fix the problem.

Most projects are small like this example and will have three or four people work on them. They have a specific objective and the goal is to achieve it; so we do the project only once. Things we repeat over and over is called operations.  If you keep doing the same project over and over, obviously you’re not achieving the results the manager wanted. Some projects are much bigger than that example but the characteristics of projects are the same; they have a special and specific objectives and we do them once. Examples of projects include:

  • opening a new business
  • developing a computer program to process payroll
  • resurfacing highway
  • opening a new healthcare clinic
  • What is a Projectbuilding a swimming pool

All of those efforts are projects and all follow the same general steps:

  1. Project initiation– in this first step, a manager or executive comes up with the idea for the project and gives a project manager and other people an overview of the idea. The initiation process often includes securing organizational approval for spending money on a project. When approval is given, we begin planning.
  2. Project planning– when we’re doing a project, we need to communicate what we’re trying to produce. That’s called the scope and that’s defined by the executive who initiated the project. The project plan may also include a budget, a schedule, and the people we need to work on delivering the scope. Larger projects have much more extensive plans and stakeholders, people who are affected by the project. The project manager presents the project plan and schedule to the organization and when it’sapproved, we begin to execute the plan.
  3. Executing the project– most of the time and money on a project is spent during the executing phase. This is where we actually perform all the tasks specified in the project plan. In those tasks, the team produces the deliverables. After they’re produced, the project executive or stakeholders review and accept the deliverables. They may also ask for changes. While all that’s going on, the project manager is monitoring everything.
  4. Monitoring and controlling– the project manager will monitor actual results and compare them to the plan and identified variances between the two. When there are differences between the plan and actual results, the project manager works to correct them.
  5. Closing– when the final deliverable has been produced and accepted, the project needs to be closed out. That involves holding a lessons learned meeting so we don’t the same mistakes on future projects. Archiving data from the project makes future projects easier and more successful.

You learn all of those skills in our project management basics courses. Take a look at the basics 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

Project Scope Statement

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

The Project Scope Statement is defined by the project sponsor. The project manager must ask the right questions to get the sponsor to clearly state the end result they want the project to deliver. It must be stated in measurable terms as acceptance criteria. Those criteria are the real definition of what the sponsor wants and how they will measure if the project is a success. Project Scope

Executives who are not used to project managers asking questions may resent it. But a successful project manager responds to the sponsor’s objections with a reasonable statement like, “I can’t deliver the business end result you want if I don’t know precisely what it is.”

Executives may not like that push back. But it is worth a bit of early executive dissatisfaction because it helps you define a measured business result for the project scope rather than a list of ever-changing requirements.

Project Scope Statement: The Sponsor’s Role

Another reason why the Project Scope Statement definition is not easy to get is because too many sponsors don’t know how to properly play their role in the project. During project planning, the sponsor’s role is to define the project in a statement of work (SOW), prove its value to the organization in a business case and define the scope statement. After they have completed those requirements, the sponsor’s role and their level of involvement declines. Then it consists of approving plans and any changes to those plans as well as accepting or rejecting project deliverables. Project Phases Main Page

In too many organizations, the project sponsor role is poorly played. Instead of defining the Project Scope Statement that will drive the project to a successful end, many sponsors do destructive things. Some play cat and mouse games with the project manager, refusing to commit to exactly what they want. They may do this because they don’t actually know what business result they want the project to deliver. So they are unable to define the scope. Or they are vague because they want to be able to avoid blame if the project fails. They can say, “That’s not what I wanted the project to deliver.”

Either way, this behavior dooms the project to failure. It drifts from one goal to another while the project manager and team members try to figure out what the sponsor really wants. They often find out a month before the due date (which the sponsor has arbitrarily set). That sets off the “end of project panic” which is also caused by sponsors who don’t know their proper role. The PM and team frantically try to produce something close to what the sponsor now says he/she wants. It’s not a surprise that what the team produces has no value. So they will spend the next six months trying to fix it. Bad sponsors leave a trail of these project failures in their wake. That’s how you can spot them… and, hopefully, avoid managing their projects. Project Scope

You can learn these techniques for defining the project scope statement in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier.

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

Presentation Body Language Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Effective project presentations don’t come from being a smooth talking project manager. You need a strong presence before the audience and that comes from your Presentation Body Language coupled with your words. Relevant content & media should be augmented by engaging body movements an gestures that communicate your message.

This video illustrates five common body language problems in presentations. Then it gives you an example of an effective use of body language in the presentation. Listen as Dick Billows, PMP points out  the good and bad techniques in each of the presentations as well as the professional level techniques used by the last speaker to make his presentation very persuasive.

Presentations & Body Language

Making effective presentations is critical to building support for your project and influencing people you work with and for. Both are keys to project success.

As you’ll see from various speakers in this video, the PM making a project presentation can use Presentation Body Language of facial expressions, hand gestures and body posture to accentuate various parts of the presentation. Body language can also help you engage the audience and cause them to want to listen to and absorb the information you’re presenting. Of particular importance is the use of eye contact with the audience. This does not involve staring down a select number of individuals. It involves sweeping the crowd with your eyes so that all the members of the audience feel you are talking to them. As importantly, use of your hands and arms to accentuate points improves your communications. You will be more interesting to watch that a person who stands still at the front of the room with their hands clasped, stuck in their pockets or gripped behind their back. Even worse are the people who play with their clothing, hair or jewelry during the presentation.

In all our courses, you make live presentations privately with your instructor over the web. You practice Presentation Body Language and get a video of your presentation along with your instructor’ feedback and coaching. Practicing presentations and seeing yourself on film are the best ways to improve your presentations.

You learn all of those skills in our project management basics courses. Take a look at the basics 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