Introduction
Is there a magic recipe for what a project manager should know? What skills do project managers lack? How does one cut through all the books and articles on project management to find the key skills and techniques that are essential for making projects successful? For the last 5 years I have been investigating the answers to these questions in order to guide PMP‘s and non PMP‘s. The results are interesting. Let's see how you stack up.
The Basics
First, let's start with the basics. Project managers work on small and large, simple and complex projects. Are there some tools of project management that apply to all? Many people seem overwhelmed with the number of project management tools and processes that are available when they first learn project management. They wonder where they should start. If they have little support for project management, which project management tools or processes should they concentrate on? Others have been working on large projects for so long that they have forgotten the most important tools of project management and how those tools can benefit their projects. In all cases, the following are the key tools of project management that many project managers are just not using and do not know enough about.
- Project charter
- Work breakdown structure
- Risk management
- Communications planning.
The following is a brief outline of why these components of project management are so important.
The project charter is a one or two page document that can be thought of as the target for the project. It provides high-level direction from management on the goals and objectives of the project. Why is a charter so important? It:
- Provides direction to the project manager from management
- Gives the project manager authority
- Formally recognizes (authorizes) the existence of the project
- Clarifies what is to be done on the project
- Provides the goals and objectives of the project
- Prevents rework
- Becomes the “target” that the project is to hit
The charter is so important on even the smallest projects that I tell my students, “No Charter, No Project!”
The work breakdown structure is a graphical picture (looking like a family tree or organizational chart) that breaks the project down into smaller, more manageable pieces. Why is a work breakdown structure so important? For even small projects, the work breakdown structure:
- Helps walk through the project before it is done, making the project easier the “second time”
- Provides the basis for estimating time, cost, resources and risks
- Helps make sure work is not forgotten
- Helps get the project organized
- Provides a vehicle to determine what should and should not be done to accomplish the project objectives
- Prevents conflict and changes later in the project
- Helps gain buy-in
There is no other tool that can effectively provide the benefits of a work breakdown structure.
Risk management is the process of determining what can go right and wrong with a project and then determining strategies for decreasing the negative effect of risk on the project. Risk management is important because it:
- Forces attention on using existing expertise to prevent future problems
- Can eliminate a huge majority of problems on the project, thus freeing up the project manager and team for more productive activities
- Helps the team better understand the project
- Helps assign roles so that when a problem occurs, there is already a plan in place and a person assigned to complete the plan
- With such plans in place, the project suffers less of an impact when a problem occurs - no meeting about the problem is required
- Directly reduces the overall project time and budget while still in planning
- Makes use of the skills and talents of the team to make the project more successful
- A final schedule and budget can not be calculated without risk
- Allows you to compare the risk of one project with that of other projects and make a project go/no-go decision
The number one problem on projects is, believe it or not, communications. Communications planning determines what needs to be communicated to whom, when and in what form. It also includes a plan for how communication problems will be uncovered and resolved. A formal plan for communications on the project has the following benefits. It:
- Is easy
- Decreases communications problems since communications requirements and how they will be met are clearly stated
- Decreases conflict
- Aids in clarifying roles and responsibilities
- Decreases wasted project time and cost
Believe it or not, many experienced project managers either do not know about the tools above or never understood why they are so important on a project. This problem is so prevalent that these items must get more attention. Why not read through the lists again and see if you can pick up any new reasons to make sure you use them on your projects.
Advanced Concepts A Project Manaager Really Needs To Know
Now for the more advanced topics. Over and over during the last few years, I have seen highly competent project managers look at me in shock when a topic comes up in my project management classes that they have never heard about. The shock becomes even greater when they realize that the topic being described is something that could have been saving them quite a bit of time and effort over the last few years. Why let this happen to you? Let's figure out what you really need to know.
Common Misconceptions
First, I would like to tell you something that all project managers should realize; most non-project managers have misconceptions about project management. In order to be a great project manager, you should know about those misconceptions, including:
- They confuse a project charter and a project plan, attempting to make them one and the same.
- They think a project plan is just a Gantt chart, when a real project plan includes a work breakdown structure, budget, risk management plan and risk response plans, communications plans, and many other components.
- Gantt charts turn them off to project management since they do not know what they are or how they are created. They seem like micromanagement.
- They think project management only consists of creating a Gantt chart, when a Gantt chart is really a minor piece of project management. To clarify, the Gantt chart is a schedule or status reporting tool designed to show a relationship of tasks to calendar time.
- They think a work breakdown structure is an indented list
- They think that an expert in a technical field should be able to manage a project – they do not realize there is a distinct skill set required
- They believe that software titled “project management software” must tell them how to manage a project
Watch out for these interpretations when you communicate with others.
Project Plan Development
Interestingly, one of the most common things a project manager needs to know that many do not know is how to develop a project plan. “What,” you might say? All project managers create project plans! Yes, most project managers do create project plans but although they think they know the purpose of a project plan, what a project plan is and how it should be created, in fact they may not! It is silly that so many advanced project managers could miss this, but they do so in such numbers as to make this one of the top things on my list. Stop for a minute and think! What do you think a project plan is?
A project plan is a document created for the project team for the purpose of guiding the execution and control of the project. The project plan is essentially a detailed plan for accomplishing the project charter. It may change over time but it is intended for use as a day-to-day management tool.
A project plan is NOT created by “project management” software. A project plan contains such items as:
- Project charter
- Project definition/scope statement
- List of relevant available data
- Work breakdown structure
- Network diagram
- Responsibility charts
- Schedule/budget
- Risk response plan
- Quality plan
- Assumptions
- Communications plan
- Management plans
- Change control plan
The project plan is not just something thrown together and then never referred to again. The project plan should be B.A.R.F. ed - e.g., creating a project plan that is:
- Bought-into by stakeholders and the sponsor
- Approved
- Realistic
- Formal
Can you imagine what it would take to create a project plan that is realistic? A realistic plan proves what can and cannot be completed. It is one that everyone believes can be achieved. Most project managers forget the following when coming up with a B.A.R.F project plan.
- Other projects
- Meetings/sign-off from functional managers
- Meetings/sign-off from the team
- Creating management plans and control plans
- Including contingency and management reserves for risk in the project schedule and budget
- Working through iterations of the plan (changing the work breakdown structure after risk analysis)
- Meeting with resource managers to get the best resources and get managers to approve the schedule
- Analyzing the skills and knowledge of all the stakeholders and determining how you will use them on the project
- Meetings with stakeholders to define their roles on the project
- Meetings or presentations to let stakeholders know what project objectives cannot be meet
- Dealing with unrealistic schedules (as described below)
Dealing with Unrealistic Schedules
An unrealistic schedule is a desired end date set by management (or the customer) that the project manager feels cannot be achieved. Sound like a common problem? It should not be. Read the following example of how to handle unrealistic schedules. As you read, compare what is said to your real-world practices.
- Ask, “How was that date determined?” Then ask, “Is the date a desired date or based on a real business need? What is that need?” In other words, push back to get clarification.
- Tell the manager you will get back to them if you discover a problem in meeting that date as you plan the project.
- Ignore the desired date and plan the project (charter, WBS, network diagram, risk, estimate, budget, schedule and a schedule reserve to account for risks). Come up with an initial date for project completion.
- If the initial date is on or before the desired project completion date, get approval of the schedule from the team and team members’ bosses and publish it.
If the initial date is later than the desired date, work with the team to compress the schedule, if you can, by cutting scope of work, crashing, fast tracking or identifying and eliminating or mitigating the risks in the estimate and re-estimating some of the tasks on the critical path. (You know what these activities are if you are a PMP, right?) Continue these activities until you come up with the most optimized schedule and still meet the project charter and the project constraints while controlling the overall project risk.
- If this new date is on or before the desired date, get approval of the schedule from the team and team members’ bosses and publish it.
If it is not, come up with additional options for saving time by cutting scope of work, crashing, fast tracking or identifying and eliminating or mitigating the risks in the estimate and re-estimating some of the tasks on the critical path.
- Present the actual expected end date to management and explain how it was derived (charter, WBS, etc.).
- Ask for the end date to be changed to what you come up with. This is an important step. Management is learning that the project manager has tools to create project schedules that are standardized, used internationally and that make logical sense, and that the project manager is the only one who can compile a project schedule.
- Ask for the close; “So can we go with a project schedule of 30 months?” If you do not ask, you cannot get.
- If management says yes, celebrate! If they say no, present your options.
This is also a critical step, as management is being forced to see that they cannot get all the scope of work, with limited resources and an appropriate amount of quality AND still get the project done on time. Something has to change and such change is usually management's decision. So present your options. They take the form of, “I have looked at ways to meet that end date and we can do it if you eliminate this task from the project, give us this many more resources, get commitment from the customer that they will give us this information by a certain date, or if we decrease project quality in this way.”
The results here are huge toward having a B.A.R.F. project plan. Any option(s) selected by management to resolve the issue creates a viable project that the project manager, team and management can believe is realistic and can be accomplished. Plus, management is involved in a way that benefits the project and does not hinder it.
If your management says no to all options and wants you to get it all done for the time available, then you have not adequately proven your case and the fault is yours. Many project managers will simply state, “This gives me a dilemma in that what you ask is impossible. I have attempted to prove that, but I must not be doing a good job of it. How do you suggest I get more work done than is possible within the available time?”
If nothing works and they still want you to get the project done within the time available without making any changes, get another job, as this is physically not possible and it would not be ethical to hide cuts to schedule, quality or take on too much risk.
- Offer to be involved in budgeting the next project so this problem does not occur again.
Why do project managers not do this? First, project managers are not taught to deal with this common problem in many project management classes. If it is covered, it is simply to explain crashing and fast tracking without it being applied to real-world situations. Lastly, many people mistakenly think a schedule is created using a Gantt chart; the network diagram they learned in project management class is not really useful, or the Gantt chart can be used in place of a network diagram. Many people think that management does not want you to push back, they just want you to say, “Yes sir!” Just the opposite is true of every one of the senior managers asked in my Executive Briefing course on project management for senior management.
Worse yet, project managers do not follow the process for creating realistic schedules because they blame an unrealistic schedule on management. In truth, an unrealistic schedule is the project manager's fault.
Following this process, you can get these valuable results:
- A viable project schedule that you, the team, management and other stakeholders will feel is realistic.
- Proof that project management works and should be supported.
- The chance to show you are in control of the project, understand it intimately and are competent.
- A better relationship with management where you have proven your value and have pushed back in a way that management wants (yes, 100% of management in my informal studies say they want their project managers to push back.)
- Management has been involved in project decision making in a positive way instead of the less than positive way that frequently happens, and the project manager has gotten management buy in to the project.
Measuring and Taking Corrective Action
Corrective action is defined as, “Any action done to bring expected future project performance in line with the project plan.” This seems simple, so why don't most project managers do it?
The first reason is the concept of measuring. One needs to measure in order to determine current and expected future performance. Not many people like having their performance measured. So most project managers do not even try and never really know how their project is doing or whether they can meet project requirements. The end result is that the project manager has no choice but to cut scope, force the team to work overtime or take some other unethical action to “complete” the project on time and within the project constraints, or simply not meet the project constraints. Not a good situation, but an extremely common one.
Measurement has the following benefits:
- Allows problems to be caught before they become too big
- Improves the probability of project success
- Provides the team with an updated project plan so that they know when they need to accomplish their project tasks
What many project mangers forget is that in real project management, the project plan is created by the project team. This allows the team to have bought into the plan and how performance will be measured, resulting in less resistance to measurement. The project manager should be constantly measuring performance.
The second reason that project managers do not measure and take corrective action is that one needs to have a project plan to measure against. In addition to a project plan, specific areas of importance (cost performance, the number of resources used each month) should be determined to be measured later in the project to determine performance.
As previously explained above, project managers do not have a B.A.R.F. project plan. Therefore, neither the project manager nor the stakeholders really believe that the project can be completed according to the project plan. Why measure against a schedule (for example) that is unrealistic?
If project managers are not measuring or taking corrective action, it follows that they are not taking the next step – evaluating the effectiveness of corrective action. This means taking the time to re-measure after corrective action is taken to see if the action succeeded in bringing project performance in line with the project plan.
Take these examples and turn them into action items for your projects.
- Determine what measures you can take on your projects to determine current and future performance.
- Plan those into the project so that the information is available.
- Tell the team you will be measuring performance and why measuring performance will help them.
- Involve the project team in measuring and determining appropriate corrective actions.
- Keep corrective actions as an agenda item for most team meetings.
Project Control
Far and away the worst scoring area on the PMP exam is project control. This means that most very experienced and very competent project managers do not know what they should be doing to control the project!
The reasons for this relate to some issues previously described; they do not have a real, B.A. R. F. project plan to control to, people do not generally like to control others, they have not been adequately trained in real-world issues of project control.
Project control includes the creation of a collection of formal, documented procedures, paperwork, tracking systems and approval levels for authorizing changes. It also involves the concept of integrated change control, which means that any change to one aspect of the project (scope for instance) should be evaluated for its impact on the rest of the project constraints (quality, cost, time etc.). In other words, you cannot get something (a change) for nothing (without impact to other aspects of the project.)
As described in “PMP® Exam Prep” (Mulcahy, 2002) control may also involve the following activities:
- Taking corrective action
- Working with a change control board
- Managing configuration
- Using and ensuring compliance with the change control system
- Managing changes
- Ensuring compliance and periodically reassessing change management plans
- Controlling all the components of the triple constraint to their baselines
- Exercising judgment to determine what variances are important
- Refining control limits
- Collecting data
- Holding meetings regarding controlling the project
- Handling paperwork
- Negotiating
- Communicating
- Resolving conflict
- Working within policies
- Identifying the root cause of problems
- Issuing updates to the project plan
How many of these activities do you do in the real world? Why not all of them?
Summary
No matter how many years of experience you have in working with projects, there are probably gaps in your project management knowledge and practice. Unfortunately many of these gaps are hurting you and your projects. After all these years of project management experience and professionalism, it is a sad state of affairs that even some basic project management tools are not used and misunderstood. Isn't it time to learn more about:
- Charter
- Work breakdown structure
- Risk
- Communication Plan
- Common misconceptions
- Project plan development
- Dealing with unrealistic schedules
- Measuring performance
- Taking corrective action
- Project control
Think this paper covered simply topics? This again, why would most project managers not be doing them?
