Connecting Baseline and Forecasting into One Planning System

Baseline is the agreed project plan. Forecast is the latest view of what the project is now expected to cost.

The gap between them helps a consultancy understand whether a project is still on track. Proteus already supported both, but the module had been designed around smaller and shorter projects. Our largest client brought a very different scale: projects running for years, work breakdowns with thousands of rows, people priced by discipline, location and grade, and rates that change every financial year.

The work touched several related areas: project plan structure, cost and price escalations, plan management and the forecasting tool itself. Each area made sense on its own, but together they needed to become one experience for a project manager. I focused on connecting those pieces into a workflow before designing the key screens.

The old screens were not only visually dense. They broke one planning task into pieces.

The clearest example was the cost type tabs. Baseline and Forecast both separated Labour, Equipment, Software, Expenses and Purchase Costs into different views. That made each table smaller, but it also forced project managers to switch tabs to understand or update one project plan.

The most important problems were:

• Project state was unclear. A project can have several baselines and forecasts, with drafts and active versions. The interface did not clearly tell a project manager which one mattered or what they should do next.
• Planning was fragmented by cost type. Labour, equipment, software, expenses and purchase costs were managed separately even though they belonged to the same plan.
• Planning still needed a working grid. Project managers spread hours across months or years, which is much closer to spreadsheet work than completing a form.
• Rate changes depended on manual calculation. Cost and fee rates can increase every financial year, leaving project managers to calculate and enter the changes themselves.
• Review was too shallow. Before submission, users could see a few totals but not enough detail to understand which part of the project had moved.

Before designing the interface, I needed to understand the rules that controlled it.

Project controls has its own terminology and financial logic. Early in the project, I could not always tell whether someone was confused by the interface or disagreeing with the underlying business rule. I worked closely with the BA to understand the domain, then used reviews with the client's project controls team to test the rules and design decisions as the work developed.

The biggest gap was the path across the related pieces. I mapped the user's goal, project state, available actions and screen as parallel lanes. This exposed the principle that shaped the rest of the design: the state of the project decides what a project manager is allowed to do.

I first iterated on the Project Plan Manager journey. It connected user goals, plan status, available actions, screens, system behaviour and decision points, so the hidden rules became visible before I moved into detailed interface design.

I then turned the same logic into a high level user flow for baseline and forecast. These flows helped me, the BA and the client team confirm when a plan should be created, completed, reviewed or submitted, and what the system should do after submission.

These maps were most useful during the initial alignment stage. Once we moved into detailed design, later changes and new requirements were handled directly in the design files rather than by maintaining these flows as ongoing documentation.

The workflow also needed to respond to project data created elsewhere, such as work packages, rates and approved variations. I treated those as system inputs to Baseline and Forecasting rather than part of this case, so the story stayed focused on planning state, cost type planning and review.

Once the system rules were clear, the interface came down to three main decisions.

Decision 1/3

Make the Current State and Next Action Obvious

Status first, records second.

The new Project Plan Manager leads with the current state of the baseline and forecast, with the relevant forecast action attached directly to the status. Submitted plans remain available below as the project record.

In the interface, I kept the status language deliberately simple. A project manager mainly needs to know whether there is nothing to do, a draft to finish, or a new forecast to create. More detailed system language would have been technically accurate but less useful.

Decision 2/3

Bring All Cost Types Into One Planning View

One project plan should feel like one working surface.

The old version separated Labour, Equipment, Software, Expenses and Purchase Costs into tabs. This reduced the amount of information on each screen, but it made users rebuild context every time they moved between cost types.

In the redesign, cost type became part of the planning table. Resources and other project costs sit under the relevant work package, so users can scan the full plan without changing tabs. Time periods still run across the page, which supports the way project managers spread hours and costs over months or years.

The same grid supports both baselines and forecasts because the difference is what the plan represents, not how a project manager builds it.

Keep Predictable Calculations Out of the User's Work

Rate increases are set elsewhere in the system. Cost increases are controlled centrally, while fee increases belong to individual projects because they come from client contracts. Project managers plan using the rates they know today, and the system applies the correct increase to future periods.

I treated escalation as background logic in this case, not as another task inside the planning grid. The planning experience needed to show that rates were affected by escalation without asking project managers to calculate those increases manually in each period.

Decision 3/3

Show the Full Comparison Before Anything Is Committed

Review is a comparison task, so the important numbers need to stay visible together.

The Review screen puts the key financial positions in one place, from the agreed baseline through actual spend and the latest forecast. Each position is broken down by cost type across both cost and revenue, helping project managers scan for the line that changed before submission.

The workflow became part of day to day project management for our largest client.

The new baseline and forecasting experience went live across the client's projects and was used immediately rather than remaining an optional new module. Continued use led to several rounds of follow up requirements and refinement after launch, giving us real usage to improve the product against.

For an enterprise planning tool, that continued demand was an important adoption signal. The project did not finish when the first version shipped. Real project work exposed the next set of needs.

Live use showed that the planning grid needed to support more day to day work.

Follow up requests included clearer totals by cost type, notes on planning rows and the ability to hide rows a project manager was not working on. These were small changes individually, but together they showed that users spend much more time working inside a draft than they do submitting one.

The totals request also exposed a useful data lesson. Plans are built from the people and costs a project manager expects to use, while actual cost can return at a more aggregated level. I had to think more carefully about where planned and actual values could be compared honestly.

This project changed how I approach complex domain products.

I learned that understanding the domain was part of the design work, not preparation for it. Until I understood the difference between a usability issue and a disagreement about project control rules, I could not evaluate feedback properly.

I also became more deliberate about following data through the whole system. It is not enough to understand how a value is created. I also need to understand where it is later used, transformed or compared.