If you’re going to effectively monitor, control, and manage a project schedule, you need to measure progress against an original set of estimates. A project baseline is the official record of the original cost and time estimates based on a project’s scope.

In perfect PMBOK theory, it makes sense to record and adhere to a project baseline; in practice, some project managers are reluctant to commit to a baseline. I’ve seen project schedules where the baseline is finally committed when there are only two or three weeks until the deadline. Here are four reasons why some project managers exhibit what I call “baseline bashfulness” and suggestions on how to overcome these issues.

Reason 1: Project scope is not completely defined

In a perfect world, IT projects would be similar to construction projects, where the design and architecture are well defined and explicitly detailed on a blueprint. Software projects need to be more adaptive to changing business processes and designs as requirements are further understood. The reality is the project team can waste months defining every detail only to have the business process change.

How to overcome it: You should commit to what you know and apply the rolling planning concept. For example, baseline tasks one to two months out and set the baseline for the new tasks once you understand the scope further. Management and stakeholders always want a commitment date, but with IT projects, we need to establish target dates with the expectation for adjustment. As your project approaches those target dates, the task to reach the next target needs to be baselined, otherwise you won’t know how far off you are on the plan.

Reason 2: Unknown or uncontrollable external factors

Another frequent concern is unknown dates for work sourced to other project teams. These teams may be external to the project or the company but still can affect the IT project team’s schedule. The project detail for each vendor or external team may not be fully defined or controllable; you might even have to work with external teams that refuse to publish a project schedule and will only communicate a handful of dates.

How to overcome it: The project team should be able to make estimates for the work even if every detail from the external team is not known. By baselining an estimated milestone, the team can document the assumption that the date will move once the unknown scope is clarified. The project team still needs a target date they can plan for rather than try to manage the unknown.

Reason 3: Fear of top-down management

Project managers might be reluctant to baseline if they’re fearful of how executives will respond to missing dates. The amount of attention and help received for a missed milestone will vary based on the organization’s project management culture. Delivery-focused organizations find ways to help without rebuke, while less successful organizations penalize the project manager for not having an accurate crystal ball.

How to overcome it: There isn’t an easy solution that will make the project manager feel better. The best bet is to communicate a distinct action plan early in the project, which will help demonstrate the project manager is in control despite the slipped date.

Reason 4: Lack of hands-on experience

I can get PMP certified by taking a weekend prep course, but I’ll learn how to pass the exam rather than the fundamental project management principles. Newly minted PMPs and even experienced project managers run the risk of failing to “walk the talk,” even as they talk about the importance of managing to dates with a performance baseline. I’ve worked with project managers responsible for large scale projects who asked me, “What’s a baseline?”

How to overcome it: Organizations need to couple project management theory with good old-fashioned practice. By partnering experienced project managers with new project managers and sharing templates, filters, views, and realistic techniques, everyone will benefit.

Baseline flexibility

If the concept of a project baseline still seems daunting, remember you can always save a different version of your plan or record a different set of baseline dates. In Microsoft Project, you can create 11 versions of the project baseline within the same file. By recording your original baseline date with subsequent re-baselines, you don’t lose track of the original estimates and can plan better in the future using the original set of estimates and actual data. Microsoft Project also supports deadlines that can be used as a “soft” baseline for key tasks. You can create and validate deadlines to manage the schedule if you’re uncomfortable with baseline dates and variance analysis.