We’re all very familiar with baselines in life. We may not call them by that name, but they’re all around us. They tell us when we should change the oil in our cars, how much we can afford to spend on vacation, how much our monthly payment is for our house, and what age our child needs to be to start school. Dictionaries define baselines as an imaginary line or standard by which things are measured or compared. That is why they are a valuable tool for us in life. They guide us and let us know if we get off course.

In projects, baselines are invaluable tools that help us navigate towards success. They’re communication devices that establish expectations between parties: when is the project going to finish, what is going to be delivered, and how many hours of effort will it take to complete the project? Yes, baselines are only estimates at the start of a project, but they also set the expectation that gets everyone on the same page. Baselines are often formalized in project charters and plans, requirements and design documents, schedules, and budgets. They are distributed broadly to establish a consistent set of expectations.

When baselines are compared to current progress and new estimates they produce variances. These variances let us know how far off we are from where we want to be, signaling we need to take strong action to get the project back on course. When these variances are monitored closely, they indicate trends that point to root causes of negative results.

Given that baselines are expectations between all project stakeholders, they need to be revered and protected. While it may seem like no big deal to quietly change some portion of the project baseline without letting everyone know, it destroys the trust and cohesiveness of all parties involved when it happens. Baselines should only be changed when approved by a configuration management process were all stakeholders are informed of the desired change and the ramifications of doing so. This is not to say project baselines should not change: quite the opposite. Baselines must change. Very few projects are completed as estimated at the start; therefore, the expectations must be aligned closer to current reality as the project moves closer to completion. It is always better to be proactive and announce less than favorable news as soon as it is known than to delay it until it becomes a bigger problem and more of a surprise.

People struggle with project baselines in three ways. They delay setting the baseline in the beginning until they get further along in the project so their estimates will be closer to what they actually deliver. They keep their distribution limited and don’t share their baselines broadly leaving people in the dark. And lastly, they never change the baseline during the life of the project which only disappoints stakeholders when the project is delivered. At the root of these three scenarios is the fear that the baselines will hurt them: they are seen as a weapon to be avoided, not a valuable tool to be embraced.

Take Becky for example, who was excited when she was assigned her first project to lead. It was a smaller project but it was her chance to move into the role of project manager. Becky built her project plan and established a schedule. She had it reviewed by her team, boss, and project sponsor and, once approved, she began work. In the beginning things progressed well and Becky was excited. One day her sponsor came to her office and told her he wanted to add one more item to her list of deliverables. She told him no problem, she would make it happen. A few weeks later her sponsor came by again and told Becky he needed the project to be finished three weeks early. Again, because things were going so well she thought she could meet his request. Then the project began hitting some tough times. One of her key team members got sick and missed two weeks of work. Then she realized it would take twice as long to produce the extra deliverable the sponsor requested. Now Becky’s schedule showed her finishing a month later than she first estimated, and almost two months after her sponsor wanted it finished. She told no one about the projected change in schedule and just hoped for a miracle. Becky felt that if she told her boss and the sponsor she would never get another project to lead in the future. For four months Becky didn’t tell anyone about how late the project would be delivered. When the expected date of delivery came she finally broke down and told her boss and sponsor. They were shocked and surprised. Both of them explained they could have helped her if they had only known.

Becky stumbled in two major areas related to baselines. She did not treat the baseline as sacred and changed it without going through the rigorous configuration control process. Changing scope, or end dates always has an impact that needs to be understood and communicated. She also failed to communicate the schedule variances and the need to align the baseline to the current state of the project. As a result, Becky limited her ability to take corrective action. The lesson to be learned is that if we don’t embrace the value of baselines it will not only diminish our effectiveness, it will handicap our project stakeholders and cause tough times for them. And, nothing good comes from a surprised and disappointed stakeholder.