You’ve probably heard the expression “We’re flying by the seat of our pants.” In project management, we call it operating without a baseline.
Many years ago, I had a boss who used to say that all the time. He owned a successful company, which encouraged him to try his success in other areas, few of which had anything to do with his background. I remember asking him if he really knew what he was doing, and he laughed.
“Not really,” he admitted as he reviewed the website mockup for yet another startup. “I’m just flying along by the seat of my pants.”
If you’re involved with a startup, there’s a certain excitement and glamor in taking things day by day and being open to possibilities. Try doing that in project management and you’ll soon realize that you’re in the wrong profession.
All projects are governed by hard rules like scope, deadlines, and budget. These are all part of a project baseline and without them, you don’t have a project: you have a potentially endless odyssey that no one will enjoy- least of all you.
What is a project baseline?
The simple definition of a project baseline is the starting point for your project plan. Once it’s established, you use it to measure progress and overall performance. When you’re wondering whether you’re on track and within budget, the good or bad news can be found in the baseline.
For example, let’s assume that you’ve spent $10,000 of the budget allocated for your client’s new food service app. Is that a good or a bad thing? If your budget is $50,000 and you’re well into the project, it probably is. On the other hand, if the budget is $20,000 and week one is barely over, you’re going to have to review the project’s actual vs. projected cost with the client.
The typical project baseline has three elements:
All three are monitored and controlled to ensure that everything is on track. If one component runs into complications, it can affect the project outcome if you don’t rectify the situation in time.
Why is a project baseline important?
A project baseline allows you to efficiently oversee and manage how a change in your schedule, cost, or scope affects everything else. When you’ve integrated all three elements properly, you can, for example, see how a delay in the schedule will affect the cost of the project and even change its scope. When integration is incomplete or nonexistent, problems may not be recognized until it’s too late for a cost-effective solution.
Examples of problems include:
- Schedule delays. Without a project baseline, the schedule can be delayed by issues like mistimed material delivery or insufficient human resources. If the delay is due to lack of a scarce resource, you could be waiting weeks or even months to get back on track.
- Lack of sufficient resources. If your schedule is not thoroughly planned, you may underestimate the number of resources you will need. I saw this happen when another project manager at my agency failed to realize how many coders he would need to launch a global ecommerce site. His team worked unfairly long hours, which did little for morale, until he got the additional personnel, .
- Quality management problems. When you don’t define your scope clearly, the project deliverables may be less than what you intended. For example, if you know that the client wants a particular type of UI for their new app but not the decorative aspects like font type and background color, you may get a functional product that they won’t be happy with.
- Problems monitoring progress. If you don’t have a clearly defined schedule that you can monitor, how do you measure progress? I keep track of my projects by using Toggl Plan, a web-based project management tool with Gantt chart timelines that helps me measure progress AND detect problems as they arise.
According to the Project Management Institute, the baseline is your project’s touchstone because it has to be understood and supported by all stakeholders. As the above problems suggest, an unclear baseline is a leading cause of project failure.
How to Baseline a Project Plan
You’ve been handed a new project. (Congratulations, by the way!) Now it’s time to create your project plan by planning its three major baselines.
Develop the Scope Baseline
I use a scope statement to support the scope baseline. In my opinion, it’s the most important document in your project plan because it describes:
- What the project outcome is expected to be
- What the deliverables are, along with key milestones and the approach to delivery
- The business need for the project deliverables and what business problem they solve
After explaining the deliverables in the scope statement, I develop them into a work breakdown structure, which accomplishes the following objectives:
- Identifies all the work that must be done to create the deliverables
- Breaks the large deliverables into smaller ones, so that the team understands the path to completing each one
Develop the Schedule and Cost Baselines
I develop these two baselines at the same time because, in my opinion, they’re interdependent. Once the tasks and activities are identified in the scope baseline, I create the schedule and cost by:
- Identifying the resources for each task.
- Estimating how long each task will take to complete.
- Estimating the cost of each task. I come up with my numbers by using supplier estimates and the average hourly rate of the team members who will be working on the task.
- Using the tasks list and estimates to develop the schedule. As I stated earlier, I input my schedule into Teamweek, which also allows me to specify which team member is doing what task, how long it will reasonably take for them to complete it, and what the start and end dates are.
If I’ve worked on similar projects before, I know which tasks are dependent on others (and to what extent), which makes it easier to develop a critical path. If I’m venturing into new territory, I talk to more experienced colleagues or go on the Project Management Stack Exchange, which is an excellent Q&A resource for project managers.
Meet With the Stakeholders
When you’re baselining a project plan, stakeholder buy-in is essential. During the kick-off meeting, explain the plan to your team, the client, company management, and everyone else who is involved, so that they understand what they have to do, approve, etc. Make sure that they don’t equate the project plan with its timeline, which is only part of the baseline.
Go into detail about the cost, schedule, and scope baselines, and how they are used to determine whether or not the project is on track. At my agency, we also have documents that we call ‘baseline management plans’, which explain how any baseline variances will be handled. In my opinion, you don’t want to start a project without one because some baselines will change- guaranteed. Suppliers run out of stock, team members get the flu for a week, and prices for key supplies can change without notice. When something happens, the management plans specify:
- Who needs to be notified
- What process will be followed
- How any changes will be funded
If any stakeholder expresses valid concerns, don’t hesitate to update the project plan. Now is the time when you can do so with the least amount of hassle.
When should a project baseline be changed?
I concluded the previous section by mentioning changes. You can count on them being made during the course of your project, but if your baseline includes change control procedures, any setback should be minor.
All baseline project plan changes should be documented and controlled with tools like change request forms and an approval process. When you allow frequent and random changes, measuring progress becomes next to impossible because the original baseline gradually becomes meaningless.
On my teams, I only support re-baselining when a significant project change occurs, such as a new or expanded scope. I haven’t seen this happen often, but clients can change their minds about anything, including key aspects of their project.
Once you make the decision to re-baseline, create a proposal for the client to approve. Once they give you the green light, act fast. In this case, delay represents risk to the project.
Why project baseline planning fails
Like all project processes, baseline planning can fail. According to Forbes, 25% of all projects fail. It’s not a promising statistic, but it is one that you can avoid if you make sure that the baseline is clear to everyone. Baselines include project goals, and if no one really understands what they’re supposed to achieve, then the tasks, deadlines, and requirements have nothing to hold them together.
Other problems include:
Lack of communication. If your project plan doesn’t include a standard process for communication, you—and the rest of your team—will be trying to piece together status reports and requests for information from emails, Slack messages, Toggl Plan comments, and more. Inefficient communication is a source of major stress. I avoid this issue by using Toggl Plan, which can integrate with Slack and other project communication platforms.
Unrealistic deadlines and goals. I’ve seen novice project managers agree to backbreaking deadlines simply to please and impress the client. I’m not judging- I used to do that too, and I understand my early team had special nicknames for me as a result. Slavedriver allegations aside, don’t promise a result that will damage team morale and produce a ‘hurried’ result.
Poor resource allocation. The Project Management Institute’s 2018 survey suggested that poor resource forecasting causes 18% of project failures. If you don’t consider all the resources you’ll need when creating your baseline project management plan, you’ll run out of time, money, or both. Avoid this problem by carefully plotting the resources you’ll need given the scope and schedule.
Project baselines are indispensable tools that can keep your projects on track, your teams motivated, and your clients happy. By taking the time to create, optimize, manage, and track them, you’ll overcome most hurdles and produce results you’ll be proud of.
Rose Keefe is an author and technical writer who has over ten years’ experience in supporting project managers in the manufacturing and construction sectors. One of her primary responsibilities was developing product manuals that supported efficient use of industrial equipment. She continues to write on the subject of time management and commercial productivity for trade websites and publications.