Project Management Offices (PMOs) often fail to improve their organization’s project success rate. Most frequently, the PMO either tries to impose pointless paperwork on all the project managers or it gets no executive support for changing the way projects are done in the organization. With either of those barriers, the project management office is doomed to fail.
We tell our clients who are considering a PMO “the pain of project failure must be severe for you to succeed with a project management office.” We’re trying to communicate that the sacrifices and restrictions that come from an effective PMO are painful. They are painful for executives who lose some of their decision-making prerogatives. They’re also painful for project managers whose work is more closely scrutinized. So to get the necessary support, the organization’s pain from project failure has to be much worse than the pain from establishing an effective project management office. The organization is ripe to establish a PMO and make it work immediately after a large project failure that affects many parts of the organization.
Why Creating an Effective PMO is Hard To Do
One of the things that makes a project management office or PMO so hard to get off the ground is that you must start by controlling the initiation of new projects. Uncontrolled initiation of projects is almost always the major problem in organizations that have poor success rates. That is defined as 70% of projects fail to deliver their scope on time and within budget. There are simply not enough resources to complete all the projects that are started. What we consistently find is that when managers and executives who want to launch a new project are required to explain and commit to the business benefits that will result, at least a quarter of the projects vanish.
PMO Must Control Project Initiation
While this early success in controlling initiation looks good, it does not do away with the fact that the process will eventually restrict the ability of executives and managers to start any project they want. This is a bitter pill for many of them to swallow. However, it is absolutely necessary for the organization to identify the business benefit of all new projects.
First, the organization needs to eliminate the projects whose benefit is far less than their cost. Second, identifying the business benefit is also the basis for setting project priorities and that is the basis for the allocation of resources. Organizations that can’t properly allocate resources are unable to complete strategically significant projects. Why? Because those large strategic initiatives are starved for resources by all of the “puppy” projects that are launched in large litters every year. Bringing the initiation of new projects under organizational control is exceedingly difficult. What we’re fighting here is the executives’ belief that because of their rank they can start a project whenever they wish. Their belief that they can start a project using their own subordinates whenever they wish is especially strong. But an effective PMO must control the initiation of projects across the entire organization. That is the only way to prevent wasting resources on projects that produce little benefit. We often encounter situations where organizations have skipped controlling initiation because it is so difficult. The project office never succeeds when that step is avoided.
PMO Must Set Project Priorities
The second most difficult thing in beginning a PMO is setting project priorities. What this means is that senior decision-makers have to sit down periodically and decide which projects get “first call” on the organization’s human and financial resources. These meetings can be very nasty in the beginning. Hostility and conflict between functional divisions of the company make compromise and bargaining difficult. However, after the executives have met three or four times, they all realize that it’s important to make bargains and set priorities. Specifically, the way to play this game is to have everybody around the table owe you because you’ve made a compromise so they can get one of their projects ranked highly. If each executive behaves that way this process becomes very smooth. All project-based organizations (organizations that make their living doing projects like consulting firms, accounting, engineering, architecture) are effective at allocating resources. With some coaching and counseling, most executive groups can make this prioritization a smooth running weekly process.
PMO Must Allocate Resources
With projects having to pass a business value screen before they can be initiated and with project priorities set, the rest of the PMO is comparatively easy. The vast majority of organizations use the desktop PC to combine the project plans and allocate resources to them based on the priorities the executives have set. On a regular basis, all of the “project people” in the organization get a schedule of which project(s) they’re going to work on. As part of the allocation process, a ceiling is set on how many hours of project work a line manager or supervisor can be assigned. That’s because everyone wants them on their project teams. Emergencies certainly come up and there are crash projects that have to start immediately. The mechanism in place to allocate resources allows the PMO to make changes to the priorities and reallocate the resources when there is a project that must be staffed immediately.
PMO Must Report and Solve Problems
The most publicly visible part of the PMO is turning out data on the status of projects. This requires the implementation of a reasonably standard project management methodology and regular reporting by team members. The key to early identification of problems is to have all team members report not only how many hours of work they completed on their task but also how many hours of work remain. With this “estimate to complete” data, the PMO can identify problems early and take corrective action while the problems are small.
PMO Must Have a Project Management Methodology
Organizations need a scalable project management methodology. One size does not fit all. Small projects that are only going to take a couple of weeks don’t require the amount of documentation and planning that a six-month effort with a dozen people needs. Three levels of project methodology are sufficient for most of our client organizations. They share some common elements even though the scale is different. First, they don’t have project “to do” lists. Project planning is more effective and efficient when the plan is based on deliverables. Team members have a deliverable that is clearly described and they are held accountable for producing it. This is much better than trying to tell them everything they have to do. The only exception to this approach is for a brand-new employee or trainee who obviously needs much smaller assignments so they can learn their job. But if all projects are planned with a consistent methodology, the initiation of new projects, the setting of priorities, the allocation of resources and the tracking of problems can all be done smoothly and effectively.
The differences in team member personality types provide a constant challenge to project managers trying to build cohesive teams. What happens most often, is that the project manager assumes that everyone else including the entire team is just like him. That is, they assume that everybody else likes to receive information the way they do. They may like to receive new information in chronological order. Or, they may prefer receiving information is a summary and then ask questions and get the detail if they wish. Still others want all of the detail right up front.
They also assume that everyone else makes decisions just like they do. Some people like to be presented with detailed information and listen to it and then think about it for a while and then make a decision. They don’t like to be rushed and they will not be comfortable with summaries. That is very common. In fact it is the most common decision-making style. But if you are a person who likes to make the decisions based only on the big picture and you try and force your team members to make decisions the way you do you will never build a cohesive team.
There are many other differences between people which affect the best way to work with them. Project managers need to be very savvy in this regard because they very often don’t have a great deal of formal authority over the people they’re working with.
The ability to read your team members and communicate with them in the way they prefer is one of the major differences between consistently successful project managers and those who are not.
Watch this video of a project manager dealing with a strongly introverted project team member. In the first part of the movie, the project manager makes many mistakes and alienates the team member. In the second part of the video, the project manager applies “best practices” techniques for this personality type and builds a stronger relationship with the team member. The key point to notice is the behavior of the team member which in the first movie the project manager ignores and in the second movie the project manager pays very careful attention to the behavior and reaction of the team member Leading Teams Main Page
After watching the video, you should at the very least learn to pay attention to the people you are talking to rather than ignoring them. You should observe how they react as you say different things. Observe if things you say or do make them upset or angry. A good project manager instantly reacts to that and inquires of the team member, “What is wrong?” Or “I’m sorry that I said something that’s causing you concern.” Comments like that give you a chance to correct problems during your session with the team member. Ignoring them makes your errors have a long term impact on the relationship you have with the team member.
Project managers often receive demands to cut the project duration. Sometimes these demands come weekly or even daily. There’s a right way and a wrong way to handle requests to cut the project duration. If you handle it incorrectly, the stakeholder will go over your head to the sponsor or a senior manager. Those superiors will arbitrarily change the project duration without giving you additional resources to help you finish the work faster.
Cut Project Duration: The Wrong Way
You’ll see how this happens in the first part of the video where the project manager handles the request poorly. That error leads to what truly will be a Project from Hell. Project Schedule & Software Main Page
In the second half of the video, you’ll see how the project manager properly handle requests to cut the duration. He doesn’t flatly refused to change the duration. Instead, he gives the stakeholders choices and options for finishing earlier. Each one is feasible and leaves the project manager with a plan that is achievable. Modeling those choices requires the right kind of project schedule and a thorough understanding of techniques like critical path, fast tracking and crashing the project plan. These tools are available in project management software. You enter the data to model options and tell the stakeholders what it will cost to finish one week earlier, two weeks earlier, etc.
You should present each option as a trade-off like, “I can finish two weeks earlier if I have one more engineer for three weeks.” Notice the trade-off has two sides; the positive side of finishing earlier and the negative side of needing more people. Skilled project managers present a number of options for cutting the duration. And they go out of their way to try to accommodate the stakeholder’s requests. However, every option has a trade-off. Here are some examples:
– spending more money to finish early
– adding more people to finish early
– lowering the project scope to finish early.
You give the stakeholders several choices; each of which preserves the feasibility of the project. That’s the key to correctly handling duration reduction requests. You don’t resist changes or try to argue against making them. On the contrary, you’re willing and eager to discuss possible options for finishing early. But each of the options you present has a trade-off that you modeled in the project management software.
You learn all of those skills and how to use project management software to identify ways to cut the duration in our project management basics courses. Take a look at the course in your industry specialty.
Project bidders conferences are part of the process of selecting vendors/sellers who provide goods or services to the project. That process begins during planning when the project manager and team formulate the request for proposal (RFP). At the same time, they create the vendor/seller selection and evaluation criteria they’ll use to rank the proposals. During procurement planning, the project manager should also secure or draft the contract he/she will use with the winning vendor/seller. These documents become part of the approved project management plan. The vendor/seller evaluation process is protected from political influence because any changes to those documents have to go through change control.
The request for proposal (RFP) that is sent to potential vendors/sellers contains information about a meeting, a bidders conference, held prior to the submission of the bid or proposal. All prospective bidders are invited to this public meeting. Here the project manager and other stakeholders from the organization describe what they want and how they will select a vendor/seller to provide it. Prospective bidders can ask questions and receive answers from the project manager and procurement officials. Meeting minutes are taken and distributed to all prospective vendors/sellers, including those who did not attend the bidders conference. The intent of the bidders conference is to ensure that all prospective vendors/sellers have the same information to use in preparing their proposals.
Project Bidders Conference – Procurement Process
In terms used by the Project Management Institute (PMI), the bidders conference is a tool and technique of the “Conduct Procurements” process. Project managers make the decision to have a bidders conference and develop the procurement documents during the “Plan Procurement Management” process. T
he purpose of the bidders conference is to solicit proposals where the vendors/sellers will develop much of the statement of work (SOW) detail and their approach. It is often advantageous to give potential vendors/sellers the opportunity to ask questions in a forum where all of them can hear the answers.
Project Bidders Conference – Format and Information
The bidders conference is described in the RFP but the exact date and time are often announced later. While there are no set standards for the bidder conference, many organizations have a consistent format they use. This format may include presenting information such as the overview of the organization, the project, bidder qualifications, minimum requirements, deliverables, time frame and the SOW for the project. They also use these conferences to encourage vendors/sellers to offer creative and novel approaches in the proposals they make.
Prospective vendors/sellers often attend the bidder conference in order to fill in these details by asking questions regarding the product of the project. These questions often focus on issues such as the legal and financial requirements, the technical specifications of the product and the time frame for the project. They also attend bidder conferences to assess the competition and their odds of success.
Project Bidders Conference – Rules
In order to ensure a professional environment at the bidders conference, a few rules are implemented before the conference begins. Depending on your organization and its legal and regulatory environment, the rules of your bidders conference may be well documented and exacting, or they may be casual and informal.
Most importantly, the selection process should be fair and meet ethical standards so that no one can accuse your organization of favoring a particular vendor/seller or divulging more information to one than the others. So it is critical to avoid any private conversations between the potential vendors/sellers and the project manager and/or project stakeholders. It is necessary to give every potential vendor/seller the opportunity to ask questions and have them answered at the conference. All questions and answers must happen in front of all of the potential vendors/sellers. The questions and answers are recorded and distribute to everyone who received the RFP, whether or not they came to the bidders conference. If a vendor/seller asks a question after the bidders conference, the question and its answer must be documented and as an update to all potential vendors/sellers.
When project managers handle project change control badly, it irritates stakeholders and cause overruns on budget and duration. Fighting all changes doesn’t work and neither does accepting all of them. We’ll discuss the mistakes project managers make on change orders. Then we’ll review a methodology for doing it the right way.
On many projects, the project manager faces a never-ending stream of additions and changes. These begin five minutes after the sponsor approves the project plan and continue until five minutes before they accept the last deliverable. Watch this video of a typical change control process.
Walking out to the company parking lot, you ran into the executive who was the sponsor on your current project. The sponsor said, “The project is really coming along well but I do need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it. You knew it was time to exercise project change control. But the sponsor continued, “These items are really vital to what we’re trying to achieve on our project.” How to Manage Change Order Requests
You looked down at the paper and replied “We couldn’t possibly make any additions at this point. The due date and budget are in danger now. If we keep adding things we’ll be way over.”
The sponsor said, “But these are critical! Without these additions, this whole project will certainly fail.”
You responded, “I think the project will contribute a great deal even without these items.”
The sponsor disagreed, “These were really part of the original requirements. You must have missed them.”
You replied, “I’m sorry but these items were definitely not on the original list of requirements you signed.”
The sponsor grew re-faced and retorted, ”These were part of the business plan for customer service. I don’t care what was on that long list of technical mumbo jumbo you designed. It was just geek talk that none of us understood!” Scope Change Video
You looked back down at the list and tried to calm the sponsor by saying, “Anyway, these seem to have limited business value.”
The sponsor barked, “I’m the one running this operation and I know what’s necessary. And the items on the list are essential if we’re going to maintain competitive levels of customer satisfaction.”
You took a deep breath, “We will be late if we add anything.”
The sponsor took a breath, smiled and said, “These items really won’t take much work. So they should only hurt the schedule or the budget a little. I know you can squeeze them in.”
You frowned, “That is not the case. We will have overruns. They won’t be my fault because these items were never in the approved requirements.”
The sponsor snapped, “If you won’t add these items to the project schedule, I’m going to bump this problem up the line to the VP.”
Project Change Control with Several Endings…All Bad
1. In the first ending, you said, “OK your satisfaction is my goal. We will figure out a way to squeeze these in and not finish too late. But these must be the last changes we make or we’ll have a disaster! “
The sponsor gave his solemn promise, “Absolutely! These are the last changes.” (If you’re naive enough to believe that, you can forget about project change control.)
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you took the blame.
2. In the second ending you refused to add the additional requirements. Five hours later your boss called and angrily said, “The senior VP just chewed me out about my project managers not being responsive to our management team. Why are you stirring up trouble with your sponsor? We need his support!”
You started to explain about the changes to scope and the boss interrupted saying, “Add the damn changes…just get these people off my back.” You started to agree just as the boss slammed the phone in your ear.
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed.
3. In the third ending, the boss listened as you said, “I’m trying to be customer-oriented but those changes could set us back a couple of months and cost lots of money.”
The boss said, “Give me a memo on exactly how much later and how much more it will cost so I can show the vice president.”
You thought for a long moment and said, “Well, it’ll take quite a bit of time to put that together.”
The boss grunted in exasperation and said, “I need something to show the vice president today. So you’d better just add the changes they want and have everybody work harder. Use your leadership skills.”
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed for not exercising project change control.
Why Does Bad Project Change Control Happen Over and Over Again?
It happens because project managers lack the tools to exercise project change control. One key to project change control success is project planning that develops quantifiable acceptance criteria for the project scope and each major deliverable. These are not technical specs but measured business outcomes in the customer/user ’s organization. Those acceptance criteria with metrics are the foundation of project change control. That kind of scope definition lets you win the argument about whether changes are necessary for project success. That type of scope metric makes the argument about what was and what was not included go away. Everybody knows what was originally included. Then you aren’t arguing the merits of a change or whether it’s a good or bad idea (you will always lose those). Instead, you are discussing whether or not you can achieve the scope without including the change.
The second key to successful scope and project change control is using a software tool that allows you to quickly quantify the impact of a change. You can use the software to quickly estimate, and then model, exactly what effect a change will have on the project’s cost and duration. With this modeling capability, the conversation with your customer/user is quite different. Let’s see how it goes using both these tools for project change control.
Project Change Control the Right Way
The customer stepped into the your cubicle and said, “The project is really coming along well but I need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it and then continued, “These items are really vital to what we’re trying to achieve on our project.”
You looked down at the paper and said, “These are great ideas. OK, let’s quantify the added work and the added time.” The customer’s first item was additional training for customer service reps so they could discuss three new products with customers. You said, “We would have to change the training achievement from “Customer reps can answer questions about 37 products accurately 90% of the time,” to ’40 products.’ I’ll ask the trainer to give me an estimate of the hours required for the change.” You called the trainer who gave you a rough estimate of 12 additional hours of prep time on the new products and 15 additional hours of class time.
While you were writing, the customer said, “It should only take a few more minutes. Anyway, I thought these new products were in the original specs.”
You pulled out the plan for the deliverables and said, “No, here is the trainer’s work package we used for the estimate. It has 37 products.”
The customer agreed the new product training was not covered in the original project scope and plan.
You commented, “If you want to eliminate three of the original products, it would be a wash.”
The customer responded, “No, we need all 40.”
You said, “The trainer says that will add 27 hours of their time and the class itself will be longer for the attendees. You opened the project schedule on your PC and entered the additional hours. Then you leaned back and said, “As you can see, these changes would add 7 days to the project duration and would increase our costs by more than $16,000.”
The customer was surprised at the cost and said, “But these are necessary. They are good and worthwhile additions.”
You smiled and said, “I’m sure they are very good ideas or you wouldn’t have brought them to me. But our question has to be; can we hit our project’s measured achievement of, “Customer reps can answer questions about 37 products accurately 90% of the time” without them? They clearly expand the project scope and I will need to add extra time and money to accomplish what you want. That’s how project change control works.”
The customer said, “Well, I want you to include these items in the project or I will escalate the problem to the senior VP.”
You smiled again and said, “That’s appropriate because in our project change control process, it is the senior VP’s role to approve changes of this size. We have the data now so let’s go speak to the VP. We’ll ask if she is willing to expand the scope and add the cost and duration of your change. But I’ll be honest with you. I don’t think we need any of these changes to hit the original scope we committed to for this project. It’s nothing personal. I’m just trying to exercise project change control.”
A Consistent Project Change Control Methodology
You need the right tools to do project change control correctly and that means a consistent methodology. The methodology begins with the initial planning of the project and gives the you tools and processes to identify the measured business achievements the customer/user wants the project to produce. This is not just the technical specifications. The project change control methodology guides you step-by-step through the development of a dynamic schedule and budget. Those tools allow you to quickly calculate the impact of a change order so you can exercise project change control. This methodology is also used in status reporting. You do the same modeling to calculate the impact of the corrective actions that are needed to solve variances.
You can learn a methodology to effectively manage project change control in our Project Management Basics course. It is private online training where you have as many video conferences and phone calls with your instructor as you need.
Project teams have different cultures and attitudes toward the project and its manager. The project team members bring expectations based on their prior project experience as well as their attitudes about being on project teams. But the primary factor that determines the project team culture is the project manager’s behavior. This behavior includes:
assigning work to the team members
dealing with bad news and
handling pressure from the sponsor for earlier completions and deliverable changes.
How the project manager handles those situations sets the standard of behavior that the project team will quickly learn. Leading Teams Main Page
Watch this video of a planning blunder that many project managers make.
One of the most common (and ineffective) styles used by project managers is team micromanagement. Project managers tend to be very task oriented with a lot of focus on step-by-step procedures and documentation. It’s very easy for these PMs to believe that tight control comes from watching people closely and limiting their independent decision-making. It doesn’t. Tight control comes from giving team members clear assignments that tell them exactly what the PM expects them to deliver. That is very different than the micromanager who decides what he/she wants as the task progresses.
So how do you tell if you’re micromanaging? The first thing to look at is your work breakdown structure. Scan down the list of tasks and look at the durations. Then take a look at which team member is assigned to each task. If you see a pattern where brand-new employees, your project rookies, have tasks that are 2 to 3 days in duration, that’s reasonable. If you have experienced team members who have tasks of just a couple days, that’s way too short. You want to look at opportunities for bundling their tasks into larger deliverables which you manage. Your subject matter experts should have even larger assignments, whenever possible. The idea here is to give the experienced pros on your team the freedom and flexibility to make many of their own decisions. That also increases their commitment to the task and satisfaction with the job. People like to be trusted to make good decisions. Micromanagers don’t get the benefits of team members’ enthusiasm and commitment to their tasks.
Another sign that you’re micromanaging is a line of team members outside your cubicle waiting for you to make decisions for them. Some micromanagers love that. The fact that all of those people are coming to “the guru” for decision-making thrills them. But it undermines the team members’ confidence and leads to a project team that is not focused on solving their own problems. We often hear micromanagers complain about their team members’ lack of initiative and independence. What we find is that the project manager him/herself has created those traits in the team members. Team members believe its safer to go to the project manager for decisions than to make decisions themselves.
Too many micromanaging project managers go overboard on the details. This approach denies their team members any opportunity for feelings of achievement, independence or satisfaction in their work. These PMs think this frequent checking and limiting team member decision-making gives them tight control of the project. That is absolutely false. What team micromanagement creates is a team that has no commitment to the project scope or the deliverables they are accountable for producing. They don’t all work together (or creatively) to meet the same goal. These team members only focus on doing exactly what the project manager said because that’s how they avoid getting into trouble. This often results in destructive behavior. Team members may know that the project manager is wrong about something but they don’t bother to tell him/her. They merely do whatever the project manager says. Team micromanagement also creates situations where experienced team members, the people who have been around awhile and know the ins and outs of the technology and projects, play games. They entice micromanaging PMs to give incorrect directions and assignments that sabotage the project. Those experienced people are so discouraged with team micromanagement that they become vindictive and gladly watch the PM and the project fail.
You can learn all of the skills to become a successful project manager in our online project management basics courses. You work privately with an expert project manager who is your instructor and coach. You control the schedule and pace and have as many phone calls and live video conferences with them as you wish. Take a look at the course in your specialty.
Project Management Skills For a Successful Project Manager
What project management skills do consistently successful project managers have in common? There are personality traits, interpersonal skills, the ability to communicate, and knowledge of the right techniques to use in various project situations. Let’s start by examining the project management skills commonly used to define the consistently successful project manager. We’ll also examine a few of the myths about these skills. Then we’ll go on to examine how an organization’s project management processes and the scope of their projects affect the requirements for the successful project manager.
Project Management Skills and How They Evolved
Project Management Skills: Technical expertise – Expertise is the most ancient of the project manager ingredients. In the old days, many organizations a successful project manager required only strong technical expertise. After all, without outstanding technical expertise how could a project manager command the respect of the team? How could they plan a technically strong solution or solve problems that arose? Without superior technical knowledge, how could a PM enforce high performance standards? How could they avoid having the “wool pulled over their eyes” by team members?
Project Management Skills: Ability to Work with the User/Client – As project management evolved, it became apparent that project managers also required the ability to “sell” and persuade users and clients. Then a basic communication requirement evolved into the need for project managers to “see” the project from the user’s or client’s perspective. They couldn’t just concern themselves with the technical skills. Project managers had to learn to plan projects based on the impact on the users’/clients’ business. They had to be able to drive the effort to deliver business relevant results. Presentation Skills Video
Project Management Skills: Project Management Tools & Techniques – It also became apparent there were specialized tools and techniques that a project manager needed to be successful. For tier #1 projects (small efforts within a department), this tool set consisted of a planning template and software for creating Gantt charts. For tier #2 projects (multi-department or cross-functional projects), the project management skills and tools included higher level communications skills and software tools for modeling options and tracking performance. For tier #3 projects (strategic-level projects),the project management skills and tools grew to include strategic planning skills and interpersonal skills for multiple stakeholder situations. People realized that the best project managers had a big tool kit and the knowledge to pick the right tools for each project.
Project Management Skills: Ability to Motivate Project Team Members – Along with recognition of special project management skills and tools came recognition that the “expert power” of the technical guru was not enough to build highly motivated project teams. PMs, particularly those borrowing people across functional departments, needed the ability to determine the right way to deal with each team member. They needed the interpersonal skills to develop effective project team cultures. The management skills to define the “right” assignment for each team member and the skill to build commitment to estimates and deadlines were essential. Project Manager Communication Skills
Project Management Skills: Ability to Solve Problems – Organizations have always wanted project managers who are good problem solvers, good fire fighters. That fit nicely with the historic requirement that project managers be the technical guru and pull off heroic technical rescues. But executives learned to value PMs who could perform risk management and avoid having any fires to put out.
These skills are a basic list of the project management skills required for success. But there is no such thing as “one PM skill set fits all.” You need to think about the processes an organization needs to develop its own successful project managers.
Moving Up From Tier #1 Projects to Tier #2 and #3
It would be nice if the project management skills and techniques that make PMs successful on small projects were an automatic springboard to success on larger projects. But the reverse is often true. The techniques and styles that work well on a tier #1 project (limited scope within a functional unit) are usually a disaster when you apply them to tier #2 (cross functional) and tier #3 (strategic) projects. Unfortunately, the ingredients for project success change as:
The size of the project team grows
The project’s scope spans functional or organizational boundaries
The project “reaches” for benefits that are less tactical and more strategic.
A PM’s strong technical knowledge can successfully manage small technical projects with 2-4 people. Their technical knowledge and individual problem-solving ability lets them catch and fix all the problems. But that micromanaging style can’t expand to cover a team of 6, 12 or more people. As the scale of their project increases, PMs need to elevate their techniques. They must get rid of that delicious temptation to make all the decisions.
Running a project for the boss within a functional unit is straightforward. The whole team usually has a common boss so authority, priority and resource allocation issues are easily resolved. The boss also controls the scope whenever an issue arises. But when the team is drawn from across functional or organizational boundaries and the stakeholders multiply, superior PM techniques need to fill the gap.
The necessary project management skills also change based on the business outcome the project has to deliver. If it’s enhancing an existing functionality or process, the PM doesn’t need much “strategic vision.” But as projects aim for improvements in operational performance or strategic-level results, the PM must be able to see beyond the technology and drive the project toward those measured business outcomes.
The PM Alone Does Not Determine Project Results
Even the most superbly equipped PMs fail when the organization’s growth or density of projects increases. These factors can make the organization’s project environment a mess of over-allocated resources and priorities that change from moment to moment. When organizations increase the frequency and volume of projects without establishing organizational processes, the project failure rate climbs. And everyone usually points to the capabilities of the project managers as the source of the problem. Good PMs can cope with changing scope, priorities and resource availability. But they cannot overcome issues like the following that plague organizations:
Uncontrolled project initiation
No prioritization of projects
Absence of PM authority to manage borrowed team members.
First, the organization must bring order to project initiation with portfolio management processes. Projects should be treated like investments by the portfolio managers. They must evaluate their “yield” when determining priorities and allocating resources. Management can no longer pretend that 98% of the projects can be priority #1 or that projects can require 350% of the available resources.
Second, they must become a matrix organization for projects. They must give PMs some authority to directly assign work and reward outstanding performance of the people they borrow across functional lines.
Project Management Skills Summary
The ideas in this article may be useful in considering the skills project managers need to succeed with different types of projects. It also helps define a PM’s career progression. But there is a point where the organization itself must evolve to achieve consistent success. This requires implementing consistent project management processes and executive controls. For more information on these ideas, take a look at our Basic and Advanced Project Management courses. These courses are online with private, personal instruction. You’ll have as many live video conferences as you need.
We can also design a customized program for your organization and deliver it at your site or in online webinars.
The project manager in this video is preparing and presenting her PERT-Three Point Estimates to the sponsor and stakeholders. She is facing a tough stakeholder audience who are looking to challenge her data and her estimating methodology so that they can slash the duration she has planned as well as her budget. See how she handles their objections and criticisms as they challenge her numbers. Three-point estimating has some very powerful advantages over other ways of estimating, although it does take a bit longer. Watch how the project manager explains those advantages to the executives and turns them into supporters of the three point estimating process.
As you’ll see, the key to her PERT-Three Point Estimates presentation is not only the accuracy of the numbers at her ability to explain where that came from but also the clarity. She has dated the show the numbers tumblers who are her biggest critics but also Data for people who don’t understand the three point estimating technique. She need to communicate clearly to both of those audiences. You judge how she did.
See if you can identify the strengths and weaknesses of the presentation and how well the project manager makes her case for using the three point estimates. Is it clear how the three point estimating technique gives you good data about the likelihood of the risks the work assignments face? Do you see the mathematical accuracy of using three point estimates rather than just one? Finally, do you understand what three point estimating does to the level of team member commitment? Participating in the estimating process increases commitment to the resulting due dates and work estimates. We hope the video and narration by Dick Billows, PMP, help you understand how and why successful project managers use three point estimating.
Let’s look at a typical day in the life of a Superstar Project Manager and the specific project manager skills and techniques they use. The Superstar Project Manager arrives at work a few moments after dawn (being a superstar is not easy). He has already gone over the weekly status data from the project team. He’s looking at the estimates-to-complete and comparing how that total plus the actual hours worked compare to the task baseline. There are four tasks whose estimates-to-complete will take them beyond the baseline estimates. There is a status meeting today but the Superstar Project Manager is not going to take the entire team’s time to discuss these problems. Instead, the Superstar contacts the four team members and discusses the problem causing the potential overruns. The Superstar and three of the team members design corrective action that will bring the tasks back in line with the original estimates. But it’s obvious that the initial estimate for the fourth task was flat wrong and overly optimistic. It will be 5 days late. The Superstar makes a note for the lessons learned documentation. It includes the task’s actual data and the reason why the estimate was too low. Project Management Skills Main Page
Next, the Superstar looks at the project schedule. The odds of correcting the fourth task’s 5 day variance this week are very low. So the Superstar looks for a “downstream” solution. That is a task scheduled several weeks from now where there’s an opportunity to add resources and recover those 5 days of slippage. Then the Superstar drafts a concise change request. He takes responsibility for the inaccurate estimate and provides the sponsor with an outline of the corrective action. The Superstar also explains that the project’s forecasted finish date will be three weeks late until they can recover the time on the downstream task. The Superstar emails the change request to the project sponsor.
Looking at his personal calendar, the Superstar sees that he is scheduled to “take the temperature” of four stakeholders today. He needs to ensure that they don’t have additional requirements and that there are no problems coming to a boil.
Project Manager Skills – Stakeholders and Change Orders
The Superstar Project Manager wanders into the cafeteria, gets a cup of coffee and stops at four different tables to gather news from people “in the know” about high-level dealings in the organization. Unfortunately there is problem that is bubbling to the surface. A senior director who is providing three members of the project team is facing an audit by an external agency based on a whistleblowers complaint. The Superstar pulls up the project schedule on his smart phone and takes a look at the tasks being worked on by the three members provided by that senior director. He is anticipating that these team members will be pulled off for critical duties to deal with the problem. Two of the team members have no critical path assignments and both have in excess of 10 days of slack on their tasks. The Superstar Project Manager figures that allows sufficient time for them to help their department respond to the audit. Unfortunately, the third team member is working on a critical path task. That individual is a subject matter expert who will be difficult to replace. The Superstar drafts an email to the senior director. He explains that he can work around the loss of two of the director’s loaned team members. But the subject matter expert’s task is critical and losing her would affect the project completion date. The Superstar manager suggests that the workload of the subject matter expert can be reduced to 25% of the original plan if they put a new MBA the company hired on that task. They can work under the direction of the subject matter expert and reduce the expert’s time requirement. The Superstar Project Manager asks the senior director for their approval.
Project Manager Skills – Work “Out in Front”
You’ll note that everything the Superstar Project Manager has done so far involves managing in front of his project team. That is, the Superstar is not consumed with last week’s problems. Instead he is focusing on avoiding problems in the next month or two. This managing “out in front” is a key trait of Superstar Project Managers. Problems rarely catch them by surprise. They are always one or several steps The other trait we see in Superstar Project Managers is that they take the risk of trusting their team members. Superstar project managers do not micromanage Instead, they encourage independent decision-making by their team members (to the extent the team member’s experience warrants it). This allows a Superstar to give the team members a great deal of responsibility and independence. People want to work on the Superstar Project Manager’s projects because of the trust and independence they receive. That always motivates good performers to do their best work. And the Superstar continues to be a successful project manager.
You learn all of these skills in our project management basics courses. Begin whenever you wish and work individually with your instructor at your pace and schedule.Take a look at the basics course in your specialty.