Project trade-offs are the best technique to use when you’re dealing with executives who want to make changes to the plan. Knowledgeable project executives understand the concept of balances or trade-offs when they want to add or delete something. They know that if they ask you to squeeze the duration by one month it will affect the scope, cost or risk. Those are the 4-corners of a project.
Unfortunately, some executives think they can shorten the duration of the project by a month without impacting the other three corners. In this project fantasyland, they believe they can increase the scope and the deliverables without affecting the duration (schedule), cost or risk. They think any changes they want to make to the project are “free.”
Project managers who allow project executives to live in this fantasy world are doomed to repeated project failures. Once you give the executive free changes to the project, he will keep requesting (or demanding) more changes.
Using the 4-Corners
Skilled project managers always talk to executives about trade-offs between the project’s 4-corners: scope, duration, cost and risk. They make the point that there are no “free lunch” changes. Every change to the project impacts the other corners and requires a trade-off. But tactically, the PMs never say “no” to a change. That never gets them anywhere. What they say is, “Yes, I can change the schedule to finish two weeks earlier. But that will increase the project cost by $14,000 to pay for overtime and hiring several consultants. Do you want to do that, sir? Do you want to trade off a two week earlier finish for a $14,000 increase in the budget?”
Project managers should talk trade-offs with executives during the initial planning and in the approval presentation. They should continue this discussion every week when change requests are submitted and as variances appear.
They also always have the data on the 4-corners and always carry an iPad or small PC so they can generate tradeoff data in a minute or two from their MS Project schedule. You need to quantify the scope, budget, rick and duration.
We teach this tradeoff technique in all our beginner and more advanced approach in our advanced classes. You can also read more on quantifying the 4-corners in our articles of risk management, scope definition, budgeting and scheduling.
Every project manager does project scheduling. For a project that you can do in a day, a yellow note pad is often enough. When there are others doing some of the work, an Excel spreadsheet may work to plan everyone’s dates and dollars. When the team reaches 4-5 people and the duration is more than a couple of weeks, PC software specifically designed for project scheduling and budget control is most efficient.
Project Schedule: Data
Some project managers have very little data to help them successfully managing their projects, deal with change orders or respond to variances. They may not even know when they have a variance. The key to identifying problems is getting estimate-to-complete information from your team and vendors.
Project managers who receive that data are able to quickly gather information about problems and opportunities. The key to their success is that they find out about problems early, before the problem causes a due date to slip. Here are the keys. First, you must get information on every task that is in process. Second, you must know how much work has been completed and how much remains. This allows you to forecast the project completion date and the total expense on all the tasks. You can control any variances, handle change requests and take corrective action early and easily. You can use project scheduling software to optimize your schedules. In this article we’ll show you how to do all these things.
Project Schedule: Software
Previously, project managers didn’t use project management software because of the high cost and the amount of time required to learn how to use it. Those two excuses are no longer valid. There are some adequate project management software programs that are free and easy to learn. It only takes 30 to 40 minutes to learn how to use the software through the entire project lifecycle. Gantter is a free program available with your Gmail account. There are editions for smart phones, tablets and desktops. This software provides all the capabilities you need for small and medium-size projects. The learning curve is short considering the benefit you get. Project Schedule & Software Main Page
More capable software for larger project scheduling includes Microsoft Project®. It is almost $600 but provides more capabilities and a tremendous amount of decision-making data. It includes the ability to do budgeting and cost tracking and also manage multiple projects. These features are adequate for even large projects. You will need to invest a few hours of time to learn it.
Now lets talk about how a project manager using a yellow note pad, an Excel spreadsheet, or project scheduling software would handle three common situations.
Project Schedule: Finish Date, Changes & Status
The project manager doing project scheduling with a yellow note pad can quickly tell the client the finish date by using his or her ability to pick a number out of the sky. There is no basis for this completion date other than a guess about how long the project will take. This “yellow pad project manager” makes a similar guess about the cost. Projects scheduled on yellow pads usually finish late and cost more than anticipated. This means the project manager and their company lose money if they’re doing a project for a customer or client. This project manager uses the same approach when the customer wants to change the project or the deliverable. The project manager guesses about the impact the change will have on the finish date and the cost. And they are usually wrong. The yellow note pad project scheduling technique gives project managers a very limited career future.
The PM doing project scheduling with an Excel spreadsheet does a bit better. He or she enters start and finish dates for all the tasks they can think of. Then they let the program give them an idea of how many days or weeks it will take to complete those tasks. The problem with using Excel spreadsheets for project scheduling is that if the client wants to make a change, the project manager has to redo the entire spreadsheet. The same is true if the client adds a task or alters a finish date. The “Excel spreadsheet project manager” spends endless hours laboring over their PC instead of managing the project.
The project manager who uses project scheduling software does the best of all. If they are using the software correctly and following best practices, they base the project schedule and budget on work estimates. Instead of picking a finish date with a Ouija board, this project manager works with historical data, published estimating information, and the opinions of the project team members. They use this data to build a schedule based on estimates of the amount of work required. When project managers use work estimates, they gain all the benefits of the project scheduling software. They decide how much work each team member can do and the project scheduling software will assign the work to the team members so the project finishes as soon as possible. These calculations take the software about two seconds. This project manager can work with similar speed on a change request. They merely change the amount of work for the task(s) the client wants to alter. Then a nano second later, the software re-schedules the entire project and gives the project manager a new completion date reflecting the change request. If the project manager has entered hourly rates for the team members and the material costs, the software will also calculate a budget and give the project manager data on the cost of that change request.
Finally, this project manager can give accurate status reports based on the team’s estimates of the amount of work they still have to complete on their tasks. This lets the project manager anticipate problems early, not after getting hit in the face with them. There is a very good reason consistently successful project managers use project scheduling software. It allows them to spend their time managing the team and solving problems. They don’t have to spend their time making guesses or laboring over an Excel spreadsheet or a yellow note pad.
Project Schedule: Optimizing the Schedule
Too many project managers control the sequence of tasks in their projects using the start and finish dates. Instead, they should use project scheduling software with predecessor relationships. For example, these relationships tell the software that Task B can’t start until Task A is finished. Or that Task A and Task B must finish at the same time. Entering start and finish dates wastes an enormous amount of time during the original creation of the schedule and every week after that. Project managers who don’t use project scheduling software with predecessor relationships spend hours updating their schedules and changing all the start and finish dates. Even worse, the schedules they create with this fixed date technique almost always have longer durations than they should. However, project managers can experience these problems even if they use project scheduling software like Microsoft Project®. This happens if they use start and finish dates to control the sequence of tasks instead of using predecessor relationships.
Project Schedule: Increase Efficiency
Predecessor relationships are the key to building dynamic schedules. These are schedules that update themselves whenever you make a change. As an example, if you discover that Task D is going to finish two weeks early, or two weeks late, you merely enter that fact into your project scheduling software. It will automatically change the start and finish dates for every one of Task D’s successor tasks (the tasks that depend on Task D). The alternative is to manually change each task’s finish date. Using predecessor relationships saves you hours in the initial project scheduling and significant time every week for the duration of the project. That is reason enough to use this project scheduling technique. How To Use Dynamic Project Scheduling
Project Schedule: Finish Earlier
Using dynamic scheduling, you set up our predecessors in the software by identifying the type of relationships that each task has with its predecessors and successors. There are three types of predecessor relationships:
Finish-to-Start predecessor relationship between Tasks A and B is scheduled by the software so that Task B starts after Task A is finished. You’ll use this type of predecessor 85% of the time. That is why it is the default in project scheduling software.
Finish-to-Finish predecessor relationship between Tasks A and B is scheduled by the software so that these two tasks start at the time that’s required for both of them to finish at the same time.
Start-to-Start predecessor relationship between asks A and B is scheduled by the software so that these two tasks start at exactly the same time.
You can get fancier with predecessors by using leads and lags. But these three types are the basics and are a great way to get started.
Project Schedule: Parallelism and Concurrency
You make a project take less time to finish when you sequence the tasks by building in parallelism. This means you have many things happening at the same time. It makes sense that if a project has three or four tasks going on at the same time it will finish earlier than a project that has only one task happening at a time. In other words, you don’t want the whole project to be a long sequence of Finish–to–Start relationships. Instead you want to design the predecessor relationships for each of your major deliverables so as many tasks as possible are occurring at the same time. The simplest way to create parallelism using the project scheduling software is to give a task multiple successors. Whenever you can do that, you will shorten the project duration. A parallel design is always going to take less time than scheduling those three tasks to occur one after another.
There are obvious limits on parallelism, such as limits on how much work a person can do and the technical or physical dependencies between tasks (e.g.: the materials must be delivered before they can be installed). But using predecessor relationships lets you avoid unnecessarily long task sequences. That makes reporting and updating faster and saves you hours of time.
Take a look at our online Project Management Basics course where you can learn these techniques from an expert PM. In this instructor-led online training you have as many phone calls, e-mails and live video conferences with your instructor as you need.
You need to build project plans by using a lot of science and a touch of art. The art comes in deciding which processes, tools and techniques are best for each new project. The lazy way is to use the same Project Plan steps on every project. But that approach buries small projects with paperwork, meetings and processes that don’t contribute to the odds of its success. On the flip side, it often leaves large strategic initiatives with insufficient project management and overly simplified techniques. You have to use the right techniques and processes for your Project Plans to improve the project’s end results. In this article, I suggest the right steps for building a plan for projects of various sizes.
Your first step in Project 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 Plans recommendations for projects of different sizes.
Project 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 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 Requirements
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.
The Work Breakdown Structure (WBS) tasks are the basis for the project manager’s assignments to the team members. They are used to estimate costs and the schedule (duration). It is also the framework for reporting the project’s status to the sponsor. The WBS is central to everything a project manager does and plays a major role in determining the project’s success. You build this network of tasks by breaking down the project scope and major deliverables. The Work Breakdown Structure (WBS) contains everything that the team must produce to deliver the project scope. Main WBS Work Breakdown Structure Page
Work Breakdown Structure Tasks – Questions
People always have questions about how to build the Work Breakdown Structure (WBS). They often ask how big the WBS should be and how many tasks it should have. There is no magic number of tasks in a project. The number in your work breakdown structure depends on the capability of your team members. You need to consider a number of factors.
What is the correct duration for the assignments I’m going to make to my team?
How frequently do I want to receive status data and estimates to complete from my project team and vendors?
How often do I want to update the project schedule with current data?
How risky are the tasks in this project?
Work Breakdown Structure Tasks and Team Capabilities
As you can see from this list, you design the tasks in the Work Breakdown Structure to fit your management style and the capabilities of the project team members. In this article, we’ll consider the team member’s capabilities. If you have a project team made up of experienced professionals who have performed their tasks dozens of times, your work breakdown structure will have a small number of large tasks. The tasks will have longer durations because these experienced professionals can handle assignment durations of 7 to 21 days. you should give experienced professionals larger, more challenging assignments and the independence and decision-making freedom that go with it.
WBS Work Breakdown Structure
However, not every team is composed of project superstars. You’re going to have some people on your team who have some experience with projects and know their jobs but for whom a two-week assignment would be discouraging and maybe even intimidating. So for these people you’ll design task assignments that are about 5 to 7 day’s worth of work. You’re still giving them responsibility for an important deliverable but you’ve broken it up into smaller pieces. That lets you track their work more frequently. Frequent deliverables are a major factor in the accuracy of your status reports. That’s because even before a deliverable is finished and accepted, your team members report how much work they’ve completed and how much work remains to be done.
Finally, you may have a team with new hires or people who have little experience with your company. Or they may have limited expertise in the technology of their task or no experience working on projects. With these people, you want to break the assignments into small pieces where they have a deliverable to produce every day or two. You would have a large work breakdown structure containing smaller tasks with short durations. That kind of Work Breakdown Structure works best with inexperienced people because you will be expecting several deliverables from them every week. This gives you the opportunity for frequent feedback on their work and coaching to improve their performance. With these newer team members, it is a valuable motivational technique to increase the size of their assignments as they demonstrate their ability to produce deliverables on time and within budget.
Designing your Work Breakdown Structure with these team member considerations also allocates your time properly. You don’t want or need to spend a much time reviewing the work of one of your experienced project superstars. That kind of micromanagement will irritate them and interfere with their feelings of independence and professionalism. That’s why you give them the biggest assignments with the longest duration. The people who need the most review of their deliverables will have the smaller assignments and shorter duration. That’s where you’ll spend most of your time.
Work Breakdown Structure Task Risks
The last consideration in the Work Breakdown Structure is the risk of each individual task. They can affect the risk of the project as a whole. If one or two of the high-level deliverables have a high risk of duration or cost overrun, you’ll break down those major deliverables into smaller pieces. Some examples are deliverables that have a high risk of changes in technology or the technology is uncertain and cost overruns are likely. When you break down those major deliverables into smaller pieces, you’ll get reports on them every day or two. That prevents big problems from surprising you when it’s too late to fix them.
You can learn how to create the Work Breakdown Structure in our online project management courses. We offer online project management courses in business, IT, construction, healthcare, and consulting. At the beginning of your course, you and your instructor will have a phone or video conference to design your program and what you want to learn. We make certain that your case studies, project plans, schedules and presentations fit your specialty. You can study whenever it fits your schedule and work at your own pace.
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, “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.
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.
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 project. 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
Define the project scope as a deliverable with measurable acceptance criteria Employees find the file they need in less than 60 seconds.
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.
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.
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
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. More information on the lean project methodology
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.
There is lots of talk about an emerging approach to project management called “Agile Project Management Methodology.” Understandably, 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 developmentprogress 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.
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.
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 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 unforeseen 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?
It 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.