Managing a project is difficult. Scope, resources, expectations, schedules, and budgets are always changing. Although Project 2016 can help you with the mechanics of organizing, planning, and tracking a project, it can’t help you prevent all the pitfalls in project management. Here’s a look at ten of the most common pitfalls and tips on how to avoid them.
Starting too small
To start out on the right foot in a new project, start by reflecting on the big picture and work your way down to the details systematically. You have to understand the purpose, the objectives, and the strategic importance of the project before you dive into the detailed tasks that are necessary in order to complete the project.
Start by asking these questions: Should the project be organized by deliverable? By phase? By geography? By type of technology? Think through the implications of organizing your project in each of these ways.
When you determine how you want to organize the project, you can begin your work breakdown structure (WBS). If you decide to organize your project by phase, each phase of the project is reflected in the top level of the WBS; if you decide that deliverables are a better way to organize the project, those are the top level. When your top level is established, you can start to decompose the top level into more detailed work packages and from work packages into tasks.
Failing to cover your assumptions
You couldn’t plan a project without some assumptions. Making assumptions isn’t a problem, but believing that other people know — or even share — your assumptions is a problem.
Whenever you start a new project, create an assumption log — either in an Excel spreadsheet or as a Word table. Document the assumption, specify the deadline for validating it, and add a field for comments. It’s very simple, but it ensures that everyone is operating under the same set of assumptions.
Paste the assumption into the Notes section of the tasks affected by the assumption.
Treating your project as the only VIP (very important project)
Your project is important to you; in fact, it may be the most important aspect of your work. It may not be as important to everyone else, however. If you work at an organization that has many ongoing projects, yours is likely not the number-one priority. Whenever resources are pulled from your project to help out on another one, simply return to the schedule and revise your plan to complete the work. You may need to revise the baseline or even create a new one.
Believing that availability is a skill set
When you’re working deep inside the project and trying to balance resource availability with the work that must be completed, the easiest strategy is to look for the first unallocated, or under-allocated, resource and assign that person to a task. The problem is that the unallocated resource may not have the skills to do the work. An employee’s position in the IT department, for example, doesn’t guarantee, or even imply, that he can build a database or architect a system. Identify the skills necessary to complete the work, and identify the skill sets of available resources. You may even need to identify skill levels, such as entry level, midlevel, and expert.
Subscribing to the myth of unlimited resources
If you aren’t calculating the effort in, and duration of, every task, you run the risk of assigning too much work to a single resource. In most cases, resources aren’t dedicated to projects full time. Many resources work in a matrix organization — they work on multiple projects, or they do project work.
If you don’t determine how long resources must spend on the project and level the work accordingly, you face an unpleasant surprise when the project lags because its resources aren’t 100 percent dedicated or because you’ve over-allocated them.
Relying on unrealistic estimates
As a project manager, you rely on team members to provide accurate cost and duration estimates of their work. After all, you can’t be a subject matter expert in every field. However, because you’re still held accountable for the schedule and budget you develop, you should understand how the estimates were developed and then verify the appropriate estimating method.
In the Notes section, document the basis of estimates and the assumptions used to develop an estimate to help keep track of the variables associated with the estimate.
Forgetting to prepare for Murphy’s Law
A project manager has a can-do attitude. Being in the business of solving problems and delivering results, however, doesn’t mean that you can afford to be blindly optimistic about projects. Delivering on time and on budget depends partly on establishing contingency reserve for both the schedule and the budget. You can establish reserve for individual tasks that are inherently risky and set an overall project reserve. For simpler projects, a reserve of 10 percent is sufficient. For leading-edge technology, you may need a 50 percent reserve or more.
Succumbing to meeting madness
The number-one impediment to completing tasks is undoubtedly The Meeting. You may recall workdays where you hustled from one meeting to the next, only to reach the end of the day and realize that you failed to complete any of your own work. You probably didn’t need to attend all of those meetings. And if they at least had been run more effectively, they could have concluded in half the time.
Stop the meeting madness! Schedule meetings — even weekly status meetings — only when necessary. Experiment by holding team meetings every two weeks or conducting one-on-one meetings with individual team members. If a specific topic on the agenda requires input from a stakeholder, invite that person to attend only that part of the meeting and then be excused to return to work.
Forgetting that it’s only a model
After you know how to create an effective schedule using Project, don’t mistake the schedule for reality. The schedule is simply a model of reality, given the information available at the time. Information, assumptions, estimates, and resources all change; risks and issues are ever-present; and of course, the scope of the project changes. As soon as you baseline the project, it’s probably outdated.
Do your best to update the model with the latest information, but remember that simply scheduling an event doesn’t guarantee that it will occur.
Relying on miracles
If you can’t figure out how to meet a deadline given the resources and the information you enter into Project, you’re unlikely to meet that deadline. In fact, Project can help you communicate the problems inherent in an aggressive delivery date. You can show stakeholders the schedule and ask them to help you determine how to speed the completion of tasks. In some cases, stakeholders can provide relevant information that helps you finish sooner; in other cases, however, they want the project done by a specific date, but there’s no reasonable way to meet the due date.
When you face an unrealistic deadline, meet it as best you can. If the deadline is simply impossible, however, acknowledge it. You can use Project to search for alternative approaches to achieving the project deliverables — though you can’t use it to compress time.