A key success factor for project managers is making crystal-clear assignments to their project team members. This ensures the team members understand what’s expected before they start work.
As importantly, clear assignments lead to accurate estimates for their tasks. This ensures the overall project estimates are accurate. It’s important for team members to be committed to those estimates and have some “skin in the game” in terms of hitting their work and duration numbers. You get all these benefits by using a work package for each assignment.
Work Packages Store Data for Future Projects
Project managers need a vehicle to capture and store historical data on each project. So when you or other project managers have similar tasks on new projects, you can look at the actual assignments in the work packages from completed projects. You can use some of that data for the current project’s tasks. You should be able to retrieve the estimated hours versus the hours actually used and apply that information to the analogous estimates on your project. The use of the project work package addresses several success factors.
The project work package is a simple tool that improves the clarity of project assignments. At the same time, it increases the level of team member commitment to their estimates. In a very real sense, the work package is the contract between you, the project manager, and the project team member. In it, you make clear exactly what you expect of the team member on each task. The work package details the metric you will use to measure the assignment as well as the approach the team member should take to complete it. It also details the input deliverable(s) the team member needs to start their work. Additionally, it specifies the output deliverable(s) which are the things other team members need from this assignment before they can start their work. The work package also allows you and the team member to discuss risks and how to handle them. It is a very important part of the estimating process.
Learn How to Use Project Work Packages
You need to work with your team members to introduce the project work package. Be careful that it’s not viewed as “just another form to fill out.” You want to talk with them about it as a contract or agreement that the two of you will use on the project. It does the following:
defines an assignment
states their availability to work on the assignment
includes their estimate of work and duration.
You should point out that it offers them protection against changes to their assignments that don’t include adjustments to the work and duration estimates. You may honestly explain that the work package is a device to reduce the padding of estimates. That’s because it offers the team member protection against unfair changes to the scope of their work assignment. If the scope of their assignment changes, the two of you can can discuss a change to their work package.
It will take one or two projects for the team members to become accustomed to using work packages but the benefits are substantial. They are helpful on the current and future projects. The project manager can review completed work packages to use as the basis for estimates on future projects.
The WBS or work breakdown structure is not a “to do” list that you can assemble on the first day of a project. It’s a hierarchy of tasks that results from breaking down the sponsor’s major project deliverables (the scope) into supporting deliverables the team has to produce.
Each of the deliverables in the WBS is a measurable business result, like “Customer hold time reduced to 20 seconds on average.” It is not an activity like “Lower hold time.” That is ambiguous. How would a project team know when they were done? How would they know if they achieved the goal?
Creating the WBS with team members is always worth the time it takes. It’s a great opportunity to develop the team members’ commitment to the project deliverables and give them a sense of ownership. Unfortunately, on many projects, the team members don’t see their tasks until after the project manager has listed everything they must complete. So the team members don’t understand how their individual deliverables connect to the overall scope. And they don’t have a sense of ownership of their individual tasks and the project as a whole. Don’t make that mistake. Here’s how to create a WBS the right way. Main WBS Work Breakdown Structure Page
Create WBS: Begin With A Measurable Scope
The starting point for working with your team is after the project sponsor has approved the project’s scope and 4 to 7 major deliverables. You should develop the work breakdown structure by working top-down from the scope. Do not assemble a list of the things people want in the project. That “to do” list approach yields projects that cost more and take longer than they should. That’s another mistake to avoid.
You and your team members should decompose the project scope by breaking it down into 4 to 7 high-level deliverables. Each major deliverable is an entry in the WBS and is stated as a metric. That means it is measurable and has an acceptance criteria. You break each of the major deliverables into its component parts. They are the elements required to produce that deliverable. You work down each level of deliverables, subdividing them into smaller deliverables. You stop when you get down to the level of individual team member assignments. That’s how you develop the work breakdown structure top-down.
Create WBS: Brainstorming With the Team
When your team members participate in defining the deliverables with acceptance criteria they understand how the entire network of deliverables fits together. And they are committed to the project’s success because they participated in the process. Let’s dig deeper into the process of brainstorming with the team to break down a deliverable into its component parts. Let’s say you’re decomposing a measurable deliverable like, “Employees can retrieve items from the supply inventory in less than 180 seconds 90% of the time.” You and the team might identify the following supporting deliverables:
install new supply room map that lets 90% of the people locate the shelf with their item in less than 60 seconds
reorganize shelves so people can find their specific item in less than 45 seconds
automate the supply “signed out” process so people can record the item(s) they took in less than 1 minute and 15 seconds.
There may be many ways to go about achieving the high-level deliverable of reducing the time required to retrieve supplies. During the conversation with your team, you would allow people to suggest different ways of achieving that end result. But it’s a best practice to achieve consensus on the approach to each of the deliverables.
Create WBS: Archived or Expert Information
Another way to develop the work breakdown structure is to use work breakdown structures archived from previous projects. You may not be able to use the prior project’s entire work breakdown structure. But very often you and your team can find a section of a WBS that’s close enough to what you’re doing in the present project that you can copy the deliverables.
On larger projects that are more complex, you may bring in experts on certain kinds of deliverables like computer programs, remodeling of workspace and so on. You would use their expertise to help you and the team develop the deliverables for your project.
Create WBS: Sequencing and Assigning Resources
The sequence of tasks in the WBS is controlled by predecessors. Predecessors identify the relationship between tasks. They tell the team what tasks are linked to other tasks. For example, Task A must be completed before Task B can begin. Or Tasks C and D must begin at the same time.
Next you assign resources to each task in the WBS. The resources can be people, materials, or contractors. You get input from the team members on the amount of resources required for each task. Their input is invaluable if they have experience with the specific or similar tasks. When you calculate the duration of every task in the WBS you have completed your project schedule. After the project sponsor approves the schedule, you save that approved version as the baseline. As work begins, you keep track of the progress the team makes on each task compared to the baseline. That is the basis for your weekly status reporting.
Create WBS: Best Practices
The WBS is central to the entire process of planning, scheduling and tracking a project. The best practices for developing a work breakdown structure involve these steps:
After the project sponsor defines the scope (overall objective), the project manager and team members begin creating the WBS. They decompose (break down) the scope into 4 to 7 major deliverables that are measurable.
The project manager and team members break down each of the major deliverables into smaller deliverables. Each one is stated as an acceptance criteria metric.
The project manager and team members sequence the deliverable tasks and assign resources to them.
The project manager obtains the sponsor’s approval of the WBS plan and schedule before beginning work.
Emergency projects challenge every PM’s professional discipline. When the emergency strike High ranking execs want fast action now… they don’t want thinking, or planning. If you are not moving at high speed… Get out of the way! Everyone else is frantic and if you don’t start responding franticly, they’ll think you don’t care. These hysteria enablers won’t be still until they have a to do list headed, “Start Work NOW!”
So give them the todo list and then use the resulting silence and calm to identify the decision makers who will judge the success of the emergency response. Let them define success then you can start the planing with a quantified deliverable which defines the scope.
What if people/property are in danger!
If the emergency is in the “Act of God” category (fire, flood, earthquake, tsunami, meteor strike), there will be law, public safety and political officials all over the place. They each will have their own goals want to be in charge of saving people and property. You won’t begin work until all the people and property are secure. But in the meantime, you can plan so once the people and property are secure you can start work with a developed and detailed plan for whatever type of emergency you face.
Another type of emergency is affects the organization’s:
product competitive positions
loss of prized human resources
There are many examples of these emergencies. In one of them a competitor might exclusively acquire a new technology that will allow them to profitably sell your #3 product for 35% less than you do. Resulting in a potential drop in your revenues of 23%.
Recovery Project Scope
The initial thinking about the scope of the recovery project is often focused on “getting back to where we were.” In other words, the recovery project should aim to make us just like we were before the emergency. But a better way to think through the planning is to recognize that we may
Often the best thing to do is take 5 minutes to assemble a todo ir only It doesn’t matter if you are the most experienced PM out there or if you just started your career in this field. There will be times when things don’t go your way and you have a crisis project. As a matter of fact, if things wouldn’t go wrong from time to time, we would not have an opportunity to learn from our mistakes. However, it is also important to remember that no matter what the situation, a good PM always turns to problem analysis and planning first, that’s good crisis management. Project Planning Main Page
Towards the end of last year, I was reminded of the importance of planning during times of crisis. We had just completed a smaller migration project. This project was a rather routine exercise, as we had done similar projects multiple times before. The objective of the project was to move a number of trading transactions from one book to another in our main trading platform. We had a standard plan for this kind of project, everyone had signed-off on the plan, we had a number of test rounds, and finally, we did the migration in our production system. And then came the crisis. During our initial analysis and throughout the implementation phase, we had overlooked a small, but rather important parameter, and as a result we had produced a little mess in our main general ledger. Needless to say that most of our users had a tendency to panic, and the first thought was to move into action immediately, and to just adjust the ledger manually. This would have taken a whole day, and it would have bound numerous resources.
So how do you convince a crowd not to just jump into action, but to first perform an analysis and a planning session? You remind them about the consequences if the quick fix doesn’t work. The reason we had been in this situation was that we overlooked something before; hence, I reminded them that we don’t want to do the same mistake twice. Obviously, not everyone agreed, but most users understood the importance of analyzing the error and planning the response. So we did our analysis and created a simple “project plan”. This was not an endless document, on the contrary, it was an email, but a structured one. The email had the following sections:
Objective including a “business case”, which was the result of the error analysis
List of Stakeholders
Risks & Constraints
Procurement (we concluded that we can fix the problem ourselves)
A brief WBS
During this “crisis” planning phase we discovered a very simple method of fixing the error, so the fix was truly “quick” and required a lot less time and resources than the original quick fix. Once the fix was implemented, I produced a lessons learned document and adjusted our standard plan for procedures like this. By following the standard project management during a crisis situation, we had forced ourselves to think first and agree on the way forward. In our case, the analysis part revealed a better solution, but even if we would have had to manually correct the error, we would have brought everyone back into the boat.
Over the last 10 years, technology has allowed team members to work at home in great numbers. That is in addition to the contractors and stakeholders from other locations. The technology for remote team members forces changes to the project manager’s leadership techniques. The most frequent mistake we see (and we made it ourselves at first), is to think that technology will let you manage the team the same way you did when they were all in the same office. Leading Teams Main Page
The truth is that your leadership style still has to accomplish 4 things with all your team members, no matter where they work. You must:
Give them clear performance expectations and explain how you will measure their work.
Gain their commitment to the team’s goal and understanding of how their assignment fits in.
Ensure that they understand the status of the project and their assignment(s) each weekly.
Practice giving praise publicly. That’s your most valued reward.
Live Video Conferences
PMs can use live video conferences to make their leadership effective for remote team members. When you use the video conference as a substitute for face-to-face meetings, you need to avoid falling into the video conference Tar Pit. Let me explain what I mean.
Video Conference Tar Pit
In the Tar Pit, managers start the video conference off by logging into the meeting, saying hello and then turning down the sound. They proceed to catch up on emails and phone calls while occasionally glancing at the screen and listening to the muttering voices. The Tar Pit spreads like the flu when these managers mistakenly call their subordinates who are in the same video conference. Oops! People quickly realize that faking their attendance and attention is the “cool” thing to do. Soon no one is listening.
The project manager realizes that the absence of any questions from the attendees is a symptom of the Tar Pit. So they start asking questions of random people or threatening the group with a test. That works for a while until an attendee answers the question with, “I can’t hear you; there’s too much static” or “Excuse me, I need to use the restroom.” The excuses and their entertainment value skyrocket until the PM stops asking questions. Here’s how you can avoid the Tar Pit:
Limit the size of your video conferences to 1-4 people.
Limit the video conference time to 30 minutes.
Use the conferencing software feature to display everyone’s image, not just yours.
Keep the conversation moving. Schedule 1-on-1 sessions to discuss details that aren’t of interest to the entire group.
Keep the meeting moving by asking people’s opinions.
You should also leave the video conference open to other team members. You can decide whether to admit them based on the topic being discussed. That gives the meeting a social boost which people working at home need.
Collaboration between remote team members
You need to give your team members tools to work with each other. This collaboration is important for both efficiency and social bonding. It’s where remote workers are made to feel they’re part of the team.
Most of the “remote team” software products provide several communication tools that can function between team members, working from home, in different offices, or another country. In addition to video conferencing, they include: texting, email, Twitter, Facebook, live streaming of meetings and much more. These tools have enabled remote team members to collaborate effectively. But some programs have a few bad features. Among the worst are the “drop in” communication packages. They let you or a team member connect directly with another team member’s PC. That team member is rudely interrupted (and possibly frightened) when someone’s face appears in a window on their screen. Working remotely, however, can also create some challenges when working as a team.
Successfully managing remote teams requires keeping up with technology and producing the same, if not better, results than if you were working with your team locally. Here are five suggestions for effectively managing your remote teams.
Conduct the Remote Project Teams Kick-Off as You Would for Local Projects Managing a project remotely may not allow for a face-to-face initial kick-off meeting, but the same principles should apply during initiation, determining scope, etc. Brainstorming sessions, although potentially easier in person, can still be conducted thoroughly via video conference. This is opportunity to identify as many questions, concerns, ideas, timelines, constraints, etc., as possible to help ensure clarity toward the end goal throughout the project. Other Suggestions: Kick-off with a clear agenda that includes project purpose, goals, and success factors. Ensure team member roles are established and explained and include appropriate people to positively support the project.
If in Your Control, Form Strong Remote Project Teams If you have the opportunity to build your own remote project team, seek motivated, positive, self-sufficient and of course, knowledgeable people. A self-sufficient and motivated team member will help offset the potential communication challenges a remote environment offers like time zone differences, meeting availability, or lack of face-to-face meetings. An opportunity to work with the most qualified candidates increases with the pool of employees from across the country or even globe. This is a big advantage of managing a remote team. Other Suggestions: Invest time in your project team. Get to know your team members. You can use LinkedIn to learn something about them. Also, it’s best to speak with your team members about more complicated items rather than using email.
Conduct Regularly Scheduled Meetings (as needed – daily, weekly, etc.) Communication is key, especially when distance of any length exists among your team. Project team members can easily get distracted and focus more on other tasks or projects when “out of sight, out of mind.” Detailed status reports containing issues, items for attention, etc. should continue to be sent before each meeting and used as an agenda for the meeting. This helps keep meetings at an appropriate length. I have never heard anyone complain about a meeting being too short. Please be mindful of time zone differences (if needed) to accommodate the entire team as much as possible. Other Suggestions: Gain a reputation for being reliable and dependable. These characteristics become even more important when working in a remote environment. Respond to inquiries and issues in a timely manner. This behavior typically is replicated and benefits the entire project.
Set Expectations Throughout the Entire Project Lifecycle Similar to an exercise program, consistency is crucial. In addition to regularly scheduled meetings, project statuses and updates should be communicated frequently. The team must be aware of exactly where the project is on the overall timeline, which tasks remain open, and the status of each task for each team member. Consistent and appropriate communication should occur at both the individual and team level. Other Suggestions: Customize for individual expectations. Work with each member individually, as needed, to ensure expectations are clear. While some members may prefer and even excel in multi-tasking various responsibilities, other members may be more effective with a shorter list of tasks.
Recognize Team Members for Positive Performance Most people enjoy some type of positive recognition. Recognition can be tailored to each individual team member depending on their preference. For example, a team member might finish their task early, which could correlate to an earlier project finish time. That person might appreciate even more responsibility and assisting with another task. Another person might appreciate getting the “extra time” to work on other projects. In addition, an email to their immediate superior recognizing their good work is always appreciated. Other Suggestions: During each (weekly) meeting, do a “shout out” in praise of at least one team member and document the recognition of their achievement in the meeting minutes.
Managing a unique project from start to finish, whether working with a local or remote project team, will always present challenges. Working with a motivated team through appropriate and timely communication channels can help overcome at least some of these challenges.
A highly motivated, problem-solving team is a key reason for every project success. These teams are committed to completing their assignments on time and within budget so the project goal is met. The proven techniques for leading teams to success include:
selecting the right team members
crafting the right-size assignment for each person
accurately estimating hours of work and duration
gaining team member commitment
receiving status reports
giving constructive feedback.
Leading Teams: Techniques for Three Sizes of Projects
The techniques are different for each project, depending on the size and scope. Here are the project size definitions:
Tier 1: Small – they’re done within one department Tier 2: Cross-functional – they affect multiple departments and cross organizational boundaries Tier 3: Strategic – they’re organization-wide programs or projects for clients with strategic impact.
Leading Teams Technique #1: Selecting Team Members
In the selection process, you’re trying to get the best people for your project team. But you’re also gathering information about their work habits and personality so you can craft the right assignment for them. Tier 1: Small projects: You are usually familiar with the potential team members’ work performance and quality standards when you all work in the same department. During the project planning phase, you need to ask the boss for the people you want on your team. That’s when the boss is focused on the project and can give you hints about the correct assignment for each person. Tier 2: Cross-functional projects: When you have to borrow your team members from other departments or organizations, it is more difficult to make sure you get productive team members. If possible, you should interview potential team members to assess their work ethic, problem solving ability and quality standards. Tier 3: Strategic projects: On large projects for your organization or your clients, you may not be able to select the team members. If personal interviews are possible, you can gather information about potential team members’ experience and work standards. You will use that information to design the right assignments for each person. If interviews aren’t possible, you will have to make an on-the-spot judgement about the right assignment for each team member. Leading Remote Project Teams
Leading Teams Technique #2: Designing Appropriate Assignments
You must design the assignments so they fit the capabilities and personality type of each team member. You want to give larger/longer assignments to people who have solid technical experience and are skilled problem solvers. They will appreciate the assignment’s challenge. You should give shorter assignments to people who are inexperienced and/or less capable. This will let you easily track their progress and help them when it’s necessary. Tier 1: Small projects: You usually have flexibility about the duration of assignments. For trainee-level team members or less capable people, you want assignments that are 1 to 3 days long. For the average team member, 5-day assignments are usually the right size. For experienced professionals, you should design assignments that are 2 weeks or longer to give them a challenge and independence. Tier 2: Cross-functional projects: With people borrowed from other departments, it is often acceptable to talk with their boss about the right-size assignment and the level of challenge you should give them. If that’s not possible, then you will adjust the complexity and length of the assignment as they work on the task and you learn their capabilities. Tier 3: Strategic projects: On larger projects with people who are accountable for major deliverables, you need to engage them in the design of their assignments. You must avoid micromanagement of these experienced people who are very capable. On the other hand, you should give “rookies” assignments that are within their capabilities in terms of time and complexity. Team Micromanagement
Leading Teams Technique #3: Work Packages
You must clearly describe, in measurable terms, the deliverable(s) the team member should produce. And you must document their availability, as approved by their boss. Tier 1: Small projects: This level of documentation is often skipped on small projects with three or four team members working on a project within a department. On the other hand, giving a simple work pack to each team member avoids confusion about your expectations for their deliverable. Tier 2: Cross-functional projects & Tier 3: Strategic projects: For larger projects, you should document a work package for each assignment. It will make the assignment clear and document the deliverable you expect the borrowed person to produce. The work package also provides a standard information base for estimating the tasks’ hours of work and identifying their risks. It is best to document the work estimate and give a copy to the borrowed team member’s superior. Team Building Techniques
Leading Teams Technique #4: Estimating Task Work and Duration
A project management best practice is to estimate the required hours of work so you can measure progress during the assignment. All projects: Regardless of the size of the project, you should engage the team members in the process of estimating the amount of work their assignment will take. The work package is the basis for the estimating effort. You should always estimate the amount of work (50 hours, for example). You should never estimate just the duration (Oct. 21 through Nov. 7, for example). Estimating the amount of work required for the task provides you with the ability to more accurately track progress and spot problems. Their team member’s availability to do the work (halftime or 2 days a week, for example) is also documented. Team Building
You should also discuss the assignment’s potential risks with the team member and what can be done about them. This helps you avoid, eliminate or mitigate those risks. Finally, the work package should list the task’s required deliverable, the approach to take on the task and the inputs the team member requires to finish their task. Team Building video
Leading Teams Technique #5: Status Reporting
Team members should report status on their tasks every week. This allows you to find problems early so you and the team have an opportunity to fix them before the task or project is late or over budget.
All Projects: Data can come to you by phone, e-mails, a form, template or on “sticky notes.” The important thing is that each week you get the hours of work competed, as of that date, and the estimated hours required to complete the task. No narrative is necessary. You should make status reporting easy so people will do it. It is a best practice to give all team members updated status data on the entire project.
Leading Teams Technique #6: Giving Feedback
All projects: You must give feedback to team members on a timely basis. People want to be praised for a job well done. Remember that public praise is the most effective. People also need to be told when their performance does not meet your expectations. This should be done in private and include what they can do to improve. You must deliver feedback in a way that encourages people to tell you about problems early, when you and the team can define a solution or a “work around.” Constructive Feedback
It is extremely ineffective for you to get angry with team members who report bad news. This action (or reaction) causes team members to hide problems. Then you are doomed to find out about problems when it’s too late to fix them. Dysfunctional Project Team video
Leading Teams Summary
Use these proven techniques to successfully lead project teams:
select the right team member for each task
assign the right size task for their capabilities
create a work package to define their deliverable
involve the team member in estimating the amount of work required and the duration of their task
receive weekly status reports from the team members
give team members constructive feedback and praise
You can learn these techniques and enhance your skills for leading teams in our online project management courses and certifications. You begin whenever you wish and control the schedule and pace. You work privately with an expert project manager and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.
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.
The number one challenge to project leadership is the fact that the project manager has no formal organizational authority over the project team. Another factor that makes project leadership difficult is that project managers are usually technically-oriented people with little experience or skill in motivating others.
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.
Organizations need lessons learned review processes to make sure they don’t relive project failures. But these processes are ineffective in most organizations. So they make the same mistakes on one project after another. Even worse, the bigger the project failure, the less likely the organization is to learn from it. The same issues that cause a project to fail also prevent the people involved from learning from that failure. Let’s examine a typical Lessons Learned review session. Then we’ll talk about the right way to do it. Project Lessons Learned Main Page
Lessons Learned: Poking Through the Wreckage
You shuffled into your Lessons Learned review session, sick and tired of the political games and the finger-pointing. Twenty minutes later, you trudged out with the voices still echoing in your head:
“No, you’re responsible for us finishing late!”
“Me? You kept making changes. I’m surprised we ever finished!”
“You still aren’t finished. The crap you gave us still doesn’t work!”
“What? We gave you what you asked for! You just didn’t train your people to use it“
“They’d need PhD’s to use what you built!”
You walked down the hall knowing the project failure was your fault. Sure, there were some jerks involved in the project and it would be easy to blame them. But you knew that a good project manager could structure things to make even the jerks be productive.
As scenes like this repeat themselves after each project, the organization’s processes for doing projects don’t improve. The same problems wreck project after project. But there is an alternative.
Living Lessons Learned
What you need instead is a “living” lessons learned process that gives the organization and its project managers an opportunity for continuous improvement. The time you invest in your post-project review should also positively affect projects that are underway. It should reinforce the use of a consistent project management methodology. You gain these advantages with a living lessons learned process conducted in three stages.
Lessons Learned: Step 1 – Pre-Launch Peer Review
Many of our clients use peer reviews of projects that are ready to launch. That sounds fancier than it is. This just means that PM’s get feedback on their project plan from other PM’s. Sometimes they hold a live web meeting to discuss a recent plan. That gives PMs the chance to share ideas and renew their understanding of the methodology.
While the pre-launch stage is a busy time for project managers, it’s also the point at which correcting mistakes is least expensive. The process is straightforward. Early in the project lifecycle, the other project managers review the business situation faced by the user or client. Then they independently critique the project’s strategic plan, scope statement, requirements, WBS, charter, accountability structure, team assignments and schedule. If the organization’s project management methodology places a premium on thinking rather than paperwork, it doesn’t take the other project managers very long to review several project plans.
In the review session itself, the other PM’s ask questions and offer ideas, which the project manager whose work is under review may use or ignore. The project manager gets the benefit of the thinking of other PM’s engaged in the same type of work. Every project manager suffers from tunnel vision as he or she works through the final development of their detailed project plan. So the thinking of other project managers who are not buried in all the details is enormously helpful. They can spot disconnects between the user’s or client’s business problem and the project plan details. However, it is important to keep this conversation up at the project management level, focusing on “Are we doing the right project for this business problem?” and “Does the planned control process make sense for the desired business result and resources involved?” The conversation should not sink into a technology debate.
Sessions like these are effective in building consistency in the use of a project management methodology. Compliance with project management standards tends to slip under the pressure of all the work that must be done just before launch. But when project managers know their peers will be reviewing their work, they tend to comply with the standards.
These pre-launch peer reviews are ideal for reinforcing the organization’s project management methodology. The right people are dealing with real business situations and projects, not theoretical ideals. As a result, these sessions are good opportunities to renew people’s skills in using the organization’s project management methodology.
Lessons Learned: Step 2 – Corrective Action and Changes
The second step in the lessons learned process is regular (usually weekly) review of project variances. The PM and team members will decide on the corrective action they will take on variances at the weekly status report meeting. Then the PM should go through the variances again. During this second round, they focus on how to avoid the same variances in the future. They also identify other tasks that are likely to have the same issue. The focus is on ways to avoid a repeat and it doesn’t take long to identify the options.
To do this review, the project methodology must give PM’s a reliable method of identifying changes to the approved baseline schedule. The organization needs a methodology that gives the PM objective measures of project progress plus the work and cost estimates to measure the variance.
Lessons Learned: Step 3 – Team Culture and Leadership Style
The last step in the lessons learned process is the periodic assessment of the culture of the project team and the project manager’s leadership style. Obviously the project team members’ work attitudes and effectiveness are strongly influenced by the leadership behavior of the PM. But even a professional team may suffer in silence about the PM’s leadership rather than take the risk of providing constructive feedback.
Constructive feedback is very useful so you have to offer a “safe” environment for team members to give it. An effective technique is to ask the team to have lunch together once a quarter without the PM. They write a summary of the PM’s strengths and weaknesses on which they reached agreement. The PM should digest the information but ask no questions about it. Most importantly, the PM should not ask them to justify any of the negative feedback. That makes the PM appear defensive. Good project managers act on negative feedback and make themselves better. Bad PM’s can’t handle the criticism and learn nothing.
Lessons Learned Review Summary
The lessons learned review is a three-step “living” lessons learned process for project management improvement. It is an important element in moving the organization toward delivering consistently successful projects because it is a process through the entire project lifecycle. It also contributes to developing a cadre of consistently effective project managers who get better over time and don’t repeatedly relive failures.
The project estimator knows how to play the commitment game. The project sponsor wants commitments about the project’s duration and cost very early in the project. The process is often political and involves much more than numbers. But experienced project estimators play the estimating game properly and don’t get caught committing to numbers that have a low probability of success.
Project Estimator: The Tactics
Let’s look at some of the games surrounding project estimates and then discuss what tactics the project estimator should use. In the real world, estimating a project’s duration and cost is a high stakes game. The client or executive wants an accurate estimate of the project’s costs and duration. And they want the project manager to commit to hitting those numbers. When an executive asks for those estimates during the initiation process, project estimators often respond with some of the following answers:
I’m 60% confident that we can finish the project within a duration range of 3-8 months and a cost between $50,000 and $250,000.
We’ll be done in approximately 5 months and the cost will come in at about $110,000. But that’s just a rough guess!
I will have no idea until we detail the deliverables, estimate the work and find out how many people I will have to do that work.
When do you want us to finish and what’s the budget?
Answer #1 – It’s truthful but it enrages executives.
Answer #2 – Executives quickly forget the“rough guess” and are happy.
Answer #3 – It’s the whole truth but it’s useless for executives.
Answer #4 – It’s very ingratiating to executives but it’s a project deathtrap.
Which choice do most project managers make? Choice #2. It deals with the reality of the situation. Executives are under the gun to make cost/benefit and priority decisions about projects. There are also strategic realities that force certain completion dates on everyone.
The project estimator, you, are caught in a vise when asked to provide estimates. That’s especially true when the scope of the project is vague and the availability of resources is largely unknown. Project estimator tactics can make this situation a little better for everyone.
Project Estimator: The Four Stage Process
You should announce this four-step estimating process during the project initiation process. You explain the estimates you’ll give executives in each of the four stages in the project lifecycle.
Project Initiating: Use project-level order-of-magnitude estimates that are based on similar projects.
Early in Planning: Use analogous estimates for major deliverables that are based on similar project deliverables.
Final Stages of Planning: Use bottom- up estimates based on data from project team members.
Status Reporting: Use rolling estimates weekly until the project is completed.
Project Estimator: Stage One
Let’s look at a four-stage estimating process that you might use on a very simple project. An executive invites you into the conference room and says, “All these weekly reports from the branches come in with different data in different formats. I want you to develop a consistent template. Pronto. This is a high priority for me and you’ll get everyone’s cooperation. I have to run to a meeting now but come back at 3:00. I want to know when you and your team can get it done.”
You think through your experience with similar projects and access the archives for estimates from those projects. At 3:00 you’re ready and tell the executive, “During the project I will give you 4 different estimates. The accuracy will improve as I know more about the project. The best I can do now is give you a project-level, order-of-magnitude estimate based on prior experience. I’m 60% confident we can have it done in 18 to 35 working days.”
The executive gives you a poisonous look and says, “Okay, come back when you can give me a better estimate.”
You reply, “I can give you a better estimate as soon as we have finalized the scope and major deliverables and you have signed off on what you want.”
The executive frowns and replies, “I was planning to delegate that.”
You smile, “I would still need a sponsor’s signature on the scope and deliverables.”
The executive nods glumly, “OK let’s get together tomorrow at 8:00 AM.”
Project Estimator: Stage Two
After the following day’s morning session, the executive frowns at you and asks, “Now, how long will the project take?”
You look over your notes and say, “At this point, I can give you a better project-level estimate. We’re still working from the top down based on similar projects. But I can give you a somewhat tighter estimate. I’ll apply some ratios to that and give you project estimates for each phase. I’m 75% confident we can finish in 23-30 working days. Using my experience and the ratios between phases on previous projects, I can also say that I’m 75% confident of the following phase estimates:
Requirements sign-off: Branch office managers sign off on requirements: 4-7 days
Development test: test group can complete the template in < 60 minutes: 5-8 days
Training: Users can complete the template in 45 minutes: 4-5 days
Roll-out and enforcement: 95% user compliance: 10-15 days.”
The executive frowns again and asks, “When will I get better numbers?”
You answer, “As soon as I detail the work estimates and get commitments on the people here at headquarters and in all the branches. Then, I can give you a bottom-up estimate, which will be more precise than the top-down estimates I’ve been using. Bottom-up is more accurate because I’ll be using estimates from the people who will be doing the work. Then I’ll aggregate them into the overall numbers.”
Project Estimator: Stage Three
A few days later, you return to the executive’s office and say, “Here is the bottom-up estimate I mentioned. With the work breakdown structure completed and the resource commitments I’ve noted, I’m 60% certain we can finish within 24-28 working days.”
The executive gives another slightly less venomous sigh and says, “Okay, this is getting better but I’d still like really tight project estimates.”
Project Estimator: Stage Four
You nod and say, “The fourth type of estimate I’ll be giving you is a revised estimate each week. As work progresses, the uncertainty will decrease and I’ll give you new, more accurate, estimates every week. We call these rolling estimates. As an example, after the stakeholders approved the requirements, the uncertainty in the development work decreased a lot. So I can give you a much tighter estimate.”
This four-step process illustrated how a project manager changed estimating techniques as the uncertainty about the project declined. In the example, the project manager used analogous estimates based on information about earlier projects. Next working top-down, the PM estimated major deliverables using ratios from prior projects. This information could have come from several sources:
an organizational project databank
commercial estimating methodologies
elaborate statistical analysis of previous projects.
Whatever the source of the data, the top-down estimates provided relatively broad ranges in the overall estimates.
In the third and fourth estimating techniques, the PM used the project work breakdown structure (WBS) and duration/work estimating techniques at the level of individual team member assignments. The numbers got a lot better because the PM used a bottom-up approach. They aggregated the estimates from project team members to develop the overall project estimate. In this bottom-up approach, the PM based the project estimate on the team member’s own estimates for their individual assignments. The fourth estimate type was rolling estimates. They’re also based on a bottom-up approach where the team members make regular weekly re-estimates of their work/duration. As the team completes tasks and deliverables each week, the uncertainty decreases and the estimates become more accurate.
There was one consistent thread through each step. The PM had the benefit of a clear and unambiguous scope definition. And they had measurable outcomes for each of the assignments and project deliverables. Estimating is difficult enough without the burden of a vague project scope or team member assignments that can’t be measured.
Project Estimator Tactics: Archived Estimates
A major step to consistent project success and vastly improved project estimates comes from archiving data from previous projects. This is a modest investment that makes the entire estimating process more effective. When data from completed projects is archived, the organization can stop playing estimating fantasy games. They have a consistent database and methodology for developing the kind of “better and more accurate” estimates we’ve been discussing.
To learn more about these estimating techniques consider our project management courses over the Internet. You work individually with your instructor and have as many live video conferences as you want.
Feedback is not just sharing your evaluation of a team member’s work. An important part of a leader’s job is setting clear expectations and norms of behavior. These help the team members work together effectively and efficiently. You, as the leader, must set and enforce these expectations and norms of behavior. You reinforce positive behavior and change negative behavior by giving feedback to team members. Leading Teams Main Page
Feedback in the form of constructive criticism is one way to change a team member’s bad behavior. It is best to do this in private but occasionally it can be in public. It has the most impact early in the life of a team. During the “forming” and “norming” phases of team development, team members are most sensitive to your efforts to steer their behavior. A small disappointed frown from you when one team member criticizes another is often sufficient to stop that behavior. Later on, it is harder for you to change or stop undesirable behaviors. That’s because they have become ingrained. It is important to avoid punishing people with your criticism. Punishment doesn’t change how people behave and it can produce negative results.
Let’s look at the right and wrong way to handle several feedback situations.
Feedback Situation #1: Team Member is Late For a Meeting
You had e-mailed the project team the agenda for a 30 minute planning meeting. The group assembled several minutes early, except for one team member. There was informal and light–hearted conversation since most of the team members knew each other. Then you started the meeting at the appointed time. After 15 minutes, the missing team member arrived and made a couple of humorous comments as he took his seat.
There are two parts to getting the change in behavior you want. The most important part is to set the standard for timeliness. It may sound silly that you need to tell professionals to be on time for meetings. However, being late for meetings might be OK on some teams. You must make your expectation and the standard clear because it may differ from the norms they have on other teams. Let’s look at the ineffective and effective ways to handle the first part. Team building
Ineffective Feedback: Setting Standards
“By being late you have wasted all of our time. That is unprofessional and inconsiderate. If you do that again, you and I are going to have trouble.”
You are trying to punish the late arrival and this threat is an overreaction. It only makes you look silly. There is a better way to define what you expect from all the team members.
Effective Feedback: Setting Standards
“When people are late for meetings I can respond two ways. I can interrupt the meeting to let them catch up. But this wastes everyone else’s time. Or I can let the late arrival figure things out as we move on. Those are both bad choices. So please, let’s all be on time for meetings.”
The next part of the criticism is changing his behavior, not punishing him. So you should talk to him in private and give effective criticism. Two approaches to that next conversation with the late team member are below.
Ineffective Feedback: Giving Criticism
“I find that people who are late also do sloppy work and are very unprofessional.”
Stating stereotypes of people who are late as being sloppy and unprofessional is insulting. It may actually get in the way of changing the person’s behavior. You need to focus only on the behavior you want, not on personality traits.
Effective Feedback: Giving Criticism
“We are all too busy to have our time wasted by someone who is late. Please help me enforce the standard that everyone arrives on time. Thank you.”
There is no personal criticism in this feedback. There is no implication that the person who arrived late is a bad person. This is a clear comparison of the behavior you want, compared to what you got. The request for their help is a nice touch to make the criticism more effective.
Feedback Situation #2: Functional Turf Wars
As you continued to work with the team, you noticed sharp remarks exchanged between the team members from Marketing and Operations. The barbs seemed to focus on a previous, failed project. Each side was implying that the other was to blame for the project failure. You quickly decide you have to do two things. First, you have to define the norm and the kind of behavior you want from the team. Second, you need to effectively criticize the barbs being made by each side to make clear how their behavior deviates from what you want.
Ineffective Feedback: Defining Norms of Behavior
“I don’t want to hear any more of these inter-departmental turf wars. It’s stupid and completely unprofessional.”
That statement is publicly criticizing certain people on a personal level. It produces resentment, not better behavior.
Effective Feedback: Defining Norms of Behavior
“Let’s focus on the future and the brilliant things we will deliver as a team;not on failed projects from the past.”
Next you need to speak privately to the people involved about how their comments differ from the behavior you want. Let’s look at the effective and ineffective ways to do that.
Ineffective Feedback: Past Grudges
“You can dislike the people from (pick a department name) on your own time. On my project, you have to work with them. So get used to cooperating with each other.”
Effective Feedback: Past Grudges
“Everyone will have a separate, measured accountability on this project. And we will know if someone is not pulling their weight or trying to shift work off to other departments. So let’s not re-fight old wars. Let’s focus on making this project a success.”
Feedback Situation #3: Not Meeting Assignment Requirements
You cannot wait for team members to deliver bad assignments to define your expectations. You must do it upfront during the initial project planning phase. Leadership and Team Assignments
Ineffective Feedback: Meeting Expectations
“Top management is watching this project very closely and they will know very quickly if someone is not doing a good job on their assignments. So don’t let bad work on this project ruin your career.”
This is the perfect way to have people start working on their excuses for avoiding blame. They’ll do this even before they start work on their tasks. There is a better way to define your expectations.
Effective Feedback: Meeting Expectations
“The most important part of my job as project manager is to make sure you understand exactly what is expected of you. That’s why we are developing a work package that defines what each of you must do to succeed. The work package describes the deliverable you are responsible for producing. That deliverable is defined with a metric and the standards you must meet. The work package also lists all the documentation that you must produce. If you produce what’s in the work package, your assignment will be a success. If people in the organization want something that is missing from your work package, that is my fault. It’s not yours.”
As you execute the plan, there may be assignments that fall short of the expectation defined in the work package. Let’s look at the wrong and the right ways to handle that situation.
Ineffective Feedback: Falling Short of Expectations
“You have not given me what I asked for because you didn’t listen. This is all wrong due to your poor work.”
This is too vague and does not tell the team member what they did wrong. It also heaps a lot of personal accusations on them. This will not change their behavior for the better.
Effective Feedback: Falling Short of Expectations
“I guess the work package I wrote was not clear. I would like you to complete the deliverable with this new, better defined work package.”
Taking some of the blame, whether deserved or not, will make the criticism more acceptable to the team member. And, with the focus on the future, it may improve their attention to detail going forward.
Effective Feedback Summary
It’s easy to handle situations that involve good news, like finishing early and under budget. But it’s challenging to manage situations when the project that is late and over budget due to team members’ poor performance. You need to focus on changing their behavior, not punishing them. You do this with effective feedback delivered in private. It’s easy to lose sight of how your own behavior and emotions can get in the way of building a high-performing project team. To master skills for giving effective feedback, you need to practice handling these situations the right way.
You can learn and practice these skills in our private, online Project Management Basics course. You will work individually with an expert PM on a realistic project case study. You have as many e-mails, phone calls and live video conferences as you need.
There are two different techniques you can use when you are making project team assignments. The easiest way to assign work to your project team members is to give them activities to complete, like items on a “To Do” list. That technique doesn’t take much thinking and the assignment is usually a little vague. The more effective technique is to make the team members accountable for producing a specific deliverable. Each deliverable must have a measurable outcome. This technique takes a lot of thinking because you must specify exactly what you want the team member to produce and how you will measure it. Deliverables are always better assignments than a list of To Do’s. That’s because the team member will understand exactly what you expect of them before they start work. People perform at a higher level when they are accountable for deliverables and that is the key to consistent project success. Let’s discuss how to define and assign deliverables. Leading Teams Main Page
There are several components when you assign a deliverable to a team member. You need an estimate of the amount of work the deliverable will take. You also need to identify the risks in producing the deliverable. A team member often needs to receive work products from others to be able to produce their deliverable. All that information should be stated in a work package. The work package is a one-page document that gives clear assignments to team members. It also lets team members participate in defining the approach to the task and estimating the amount of work it will take. But let’s get back to the key element, the performance expectation.
Project Team Assignments: Deliverables versus Activities
There is a clear distinction between project team assignments that are activities and those that are deliverables. Activities are “To Do’s” like “teach the payroll system training class.” Deliverables are end results like, “After the payroll class, 85% of the attendees can enter 30 pay changes per hour.” After receiving each of these assignments, a team member can teach a payroll class. But the content will be different with the deliverable assignment because the trainer is not just conducting a class. They have a measured result they are accountable for delivering. Project managers who design team member assignments as deliverables have significant advantages over those who use activities. Before listing these advantages, let’s make sure you’re clear about the differences between team assignments with activities and those with deliverables. Effective Feedback
Project Team Assignments Example #1: Assignment to a Teenager
The Activity: “Clean up your room.”
The Deliverable: “Put all the empty Pepsi cans and candy wrappers in the garbage can.”
With the activity assignment, the parent have only told the teenager to perform an action. They have not defined the expected outcome. The teenager has to guess what the parent wants. There can be many interpretations of what the “Clean up your room” activity involves. So it is likely that the parent won’t get the end result they’re looking for. The key flaw in this (and any) activity assignment is that there is no clear performance expectation. There is no performance standard to measure the teenager’s actions against. There is only a vague idea of what a “clean room” looks like. As a result, the parent can’t gain the teenager’s commitment to the assignment. And they can’t reasonably deliver consequences for the teen’s good or bad performance. Team building
With the deliverable of “All the empty Pepsi cans and candy wrappers in the garbage can,” the teenager has the potential for better performance and commitment. The expectation is clear and it is possible to get the teen to commit to it. If there are still empty cans and candy wrappers on the floor after the teen says they’re done, they will have to agree that the standard wasn’t met. On the other hand, if they also put their textbooks and computer on the desk, the parent must agree that the teen exceeded the standard. In this example of a deliverable, any rewards and punishments have a better chance of being seen as fair because the standard was clear.
Project Team Assignments Example #2: Assignment to a Team Member
The Activity: “Develop recommendations to reduce turnover.”
The Deliverable: “Get management committee’s approval of policy changes that will cut turnover by 10%.”
With the activity assignment of “Develop recommendations to reduce turnover.”, the project manager must continuously check the team member’s work to guide them. That’s because the team member cannot have a clear idea of what the PM wants. (It’s also possible the PM doesn’t know what the assignment should achieve.) The team member doesn’t know whether to develop 200 recommendations to eliminate all turnover or just a few to bring it down a little. This leads to a game of “Did I get the right answer?” each time the team member thinks they are done. The team member does some work and brings their recommendations to the PM asking, “Is this what you wanted?” The answer to this question is usually “No.” Then the PM blames the team member, saying, “You didn’t understand the assignment.” So the team member goes back to the drawing board, frustrated and irritated.
These problems are solved with the deliverable assignment of “Get management committee’s approval of policy changes that will cut turnover by 10%.” The project team member knows what’s the PM expects them to deliver and doesn’t have to guess. The PM has a better opportunity to gain the team member’s commitment and positive or negative consequences will be clear and fair. Additionally, the team member can get a sense of satisfaction from meeting the expectation.
So why do PMs assign team members activities rather than deliverables? The answer is because it’s much easier and safer than assigning achievements. There are two reasons for this. First, by assigning activities, the PM doesn’t have to think through the situation and commit to exactly what he/she wants. They have some wiggle room to change their mind on what they want. Second, it is difficult for the PM to make a mistake when assigning activities. Only the person doing the work can be wrong. Weak PMs always use activity assignments because it’s safe for them and always leaves them wiggle room.
Now let’s look at some more good and bad assignment examples. The bad ones are more entertaining so we’ll start with them.
Project Team Assignments Example #3: Counting the Wrong Thing
Here are a few examples of counting the wrong thing on a customer service improvement project. The project scope is defined as “Provide World Class Customer Service that Delights the Customer.”
A PM measures the engineers’ performance by the number of lines of code each one writes. The engineer with the highest total gets a lunch with the CEO.
A PM measures the trainers’ performance by the ratings that class attendees give each trainer. The trainer with the highest rating receives a certificate of appreciation.
A PM measures the performance of customer service reps by counting the number of interviews each person conducts with customer service managers. The team member with the most interviews gets publicly recognized at a status meeting.
What performance will the PM get from project team assignments like these? In the first example, the engineers will write a lot of lines of code. Some of it may benefit the customer service division but a lot will not. In the second example, the training class attendees will have a fun time and give the trainer a high rating. But they won’t learn much. In the third example, the team members will conduct a lot of interviews. But much of the information will be gathered in a hurried manner and may be useless.
The project managers in these examples counted the activities being performed and got the results they deserved. These activities produced high volumes of whatever the PM was counting, even if it contributed little value to the project. The PMs probably didn’t know what business value the project needed to deliver. So they created assignments that were activities they could identify without much thought.
Project Team Assignments Example #4: Counting Only Dates
Another form of counting the wrong thing occurs when the project due date or duration is the only measurable result. The due date usually comes from an executive. It doesn’t consider the amount of work required or the availability of the people to do it. Next the project manager picks the due date of each assignment to support the entire project’s due date. In this situation, the team members have no commitment to their assignments’ dates because they were forced upon them. They often recognize that the dates are impossible even before work starts.
At each status meeting the PM asks, “Are you on track to hit your due dates? You committed to them.” Most team members give the PM an optimistic thumbs up. Then one day a truthful person says, “No, that date is impossible. There is no way I can hit it.” The PM gets angry and from them on, everyone is afraid to tell the truth about their assignment. So they report they are on target to meet their dates. They don’t mention that they’re counting on miracles to do so. When the due date draws near, the team members slap together whatever they can and turn it in. It’s poor quality work, but at least it’s on time. The organization then spends months and thousands of dollars to fix the failed project.
Project sponsors drive much of this “due date behavior” when all they focus on is the due dates of the entire project and the team assignments. I don’t mean to imply that the dates are not important; they are. But delivering junk by the due date does not make the project a success. Unfortunately, most project sponsors are used to to having only dates for tracking the project’s progress. Too many project managers don’t report anything else that is measurable. Everything else they report is vague, subjective statements. So it’s not surprising that sponsors like dates because they are objectively measurable and unambiguous.
What project managers need to do is to count the right things. They need to count the end result (the business value) the project produces, the date, the cost and the risk. These techniques take a more time but they yield enormous benefits. Let’s see how you do that.
Project Team Assignments: Assignment Deliverable Hierarchy
To be a successful project manager, you must work with the sponsor to define measured deliverables for the project scope. Then you define the major deliverables that lead to it. This includes the acceptance criteria the sponsor will use to measure the project’s success. Let’s use the customer service project example again. This time the scope definition the sponsor sets is “Complete 95% of customer phone calls within 3 minutes with less than 3% calling back about the same problem.” This is a clear measured outcome. Then you break it down into smaller achievements that support the scope.
As you break down the scope into its IT system deliverables, you come to the GUI (screen display) that an engineer has to develop for the customer service reps to use. That measured achievement could be “Customer service reps see 6 months of customer history within 4 seconds of entering the customer’s name or number.” Please note that this achievement is measured in the users’ business point of view. It is not measured in the IT system engineering department’s business point of view. This is much more supportive of the project’s scope than lines of code (like the PM used in the earlier example).
The trainer has a different achievement, too. Their assignment could be “80% of the class attendees can answer the top 20 customer questions in 120 seconds or less using the new GUI.” Again, what you are counting is more relevant to the project’s scope than whether the attendees enjoyed the class and the trainer.
The team members interviewing the customer service managers could have a measured business outcome like, “Managers reach consensus on the ten most important customer service problems.” This is much more supportive of the project’s scope than counting the number of interviews conducted.
That sounds pretty straightforward but it takes time, thought and planning to create this assignment deliverable hierarchy. You must think about what to count and measure. They must be relevant to achieving the project’s scope. Performance expectations must be clear to the team members before they start work. So you must define team members’ assignments in measureable terms. That encourages their commitment and makes estimating and tracking much more precise. It also lets you spot problems early, when you have a chance to fix them. It plays an important role in managing projects that deliver successful results. When you assign a project team member a deliverable, it is easier to clarify your expectations, gain their commitment and give them rewards that are based on performance. All the techniques in this article are part of our private, training courses and certifications delivered over the Internet or as in-person seminars for organizations.