Designer

Jan Artemenko, then Senior Associate in Stantec's Buildings group

Stantec

Stantec's Buildings group connected project requests, individual workloads and resourcing reviews through weekly allocations. The same records fed Power BI views of utilisation and forecast fees, while people retained responsibility for staffing decisions.

Stantec · 3 December 2025

Why MortaCoordinate project requests and staff allocations

Team contextStantec Buildings

Weekly rhythmFriday requests and Monday resourcing review

Data shownInvented staff and projects in the demonstration hub

Weekly review rhythmproject managers requested resources on Fridays and resourcing groups moderated allocations on Mondays.

Forecast from allocationsplanned time and staff rates fed Power BI forecasts, with actual fees held in separate systems.

Project demand can change before the next resource meeting. For Stantec's Buildings group, Jan Artemenko connected project requests, individual workloads and resourcing reviews in Morta. The same planned allocations provided the inputs for Power BI views of utilisation and forecast fees.

Stantec sign on a curved building facade beneath a glass tower — *Stantec building detail used in Jan's November 2025 presentation.*

Executive summary

Stantec's Buildings teams needed to coordinate specialist staff as client priorities changed, projects paused and several offices contributed to the work. Jan linked staff and project records through weekly allocations that stated how many days a person was expected to spend on each project. Staff could inspect their own assignments, project managers could enter and review project demand, and resourcing groups could moderate competing requests against capacity and expertise. The allocations also fed scheduled Power BI reporting for utilisation and financial forecasts. Jan used invented staff, projects and amounts to demonstrate the model. People still made the staffing decisions, forecasts depended on realistic remaining effort, and onboarding each person to a personal view remained manual.

Build and implementation

Jan put the build time at two weekends in his November 2025 presentation.
He said implementation took place within two and a half weeks.

The results

One allocation, several working views

An allocation connects a person, a project and the days the work needs in each week. Grouping those records by person gives staff a work plan. Grouping the same records by project lets project managers see the demand they have requested. Resourcing groups can compare both perspectives and filter them by office or discipline, which gives a smaller group a focused set of commitments to review.

The personal view added the project manager and task notes to each assignment. In one demonstration example, a person was allocated to three projects, including one day per week on Project 13. The names and projects in these views were invented to explain the structure.

Personal workload table listing example project assignments, task notes, a manager and weekly planned days — *The demonstration personal view brings one staff member's projects, tasks, managers and planned days into one place.*

Workloads that give planners a question to resolve

Power BI totalled planned days by person and week. In the demonstration heat map, red represented zero allocated days, green represented five and blue represented more than five. Leave information sat alongside the allocations. Planners could use the colours and absences to find people and weeks that needed discussion, while the choice of response remained with the team.

The live hub described in November 2025 used an hourly or half-hourly refresh. The demonstration refreshed once a day. Both were scheduled updates rather than a continuous live feed, and the displayed people and values were demonstration data.

Weekly staff allocation heat map with red, green and blue cells and filters for discipline, office and project status — *The demonstration heat map highlights weekly allocations for team review. Its names and values are examples rather than Stantec results.*

Planned effort expressed as a financial forecast

Planned work also supported two management views. Combining future staff effort with the rates held against staff records produced an expected-fee forecast by office and discipline. Applying the same principle to a project's remaining schedule produced an approximate cost to complete. This gave management a financial view of the staffing plan because every forecast period had planned time and a rate behind it.

The view was only as useful as the remaining effort entered for each project. Actual fees came from separate systems and stayed distinct from these forecasts. The monetary amounts pictured below were invented for the demonstration.

Stacked monthly revenue forecast bars and an office-share ring chart with office and discipline filters — *The demonstration revenue view groups forecast fees from planned effort and staff rates by office.*

Approximate cost-to-complete table with project rows, weekly forecast amounts and a total column — *The demonstration cost-to-complete view values remaining project effort across future weeks.*

The challenge

Resource planning had to respond to projects starting, changing or going on hold. Jan needed to understand immediate availability, look three to six months ahead for possible recruitment needs and find people with the right expertise. Winning work was a separate question from having the people who could deliver it.

The information sat in different spreadsheets and databases. That made it harder to compare demand and capacity when projects involved several offices or time zones. Bringing the records into one shared structure gave the Buildings teams a common basis for their resourcing discussion.

Four-column slide describing staff availability, longer-term resource planning, recruitment and the expertise needed for delivery — *The resource-planning challenge covered availability, future demand, recruitment and the expertise required for delivery.*

The solution

Start with project requirements

Project managers described the engineers and time their projects needed. Those requests became proposals for resourcing groups to examine against each person's other commitments and relevant expertise. The purpose was to support project delivery, rather than allocate work simply to fill everyone's week.

Central diagram showing a project manager passing information through Morta to moderation and resourcing, then to all staff — *The workflow passes project requests into a resourcing discussion and makes the resulting allocations available to staff.*

Connect people, projects and weeks

Staff records held office, discipline, role and employment status. Marking someone as no longer employed preserved their history instead of deleting the record. Project records held codes, managers, status and the offices and disciplines involved.

Each allocation linked those records and added planned days across successive weeks. Predefined views presented the relevant fields on working pages, while Power BI received the same underlying allocation data. Staff, project managers and resourcing groups therefore worked from comparable commitments even when their views differed.

Resource Planning table with project, staff, status, manager, discipline, office and weekly allocation columns — *The demonstration allocation table connects project, staff and weekly planning fields used by the other views.*

Keep demand visible before naming a person

A project did not need a named person before its demand entered the plan. In Jan's demonstration, a technician role required two days per week for the next couple of weeks. A placeholder kept that role and time visible in the unassigned-work view.

The resourcing group could compare that requirement with people who had spare capacity and the suitable expertise. The role and days gave the group something specific to match, while the group still chose the person.

Unassigned Work table with project rows, task notes and question-mark role placeholders in the team column — *Role placeholders keep project demand visible in the demonstration until the resourcing group selects a suitable person.*

The implementation

Friday requests, Monday review

On Fridays, project managers entered the people and days needed for the following week, or looked four to six weeks ahead where the work was clear enough. On Mondays, resourcing groups compared those proposals across projects. They checked over-allocation, available time and whether the proposed person had the expertise the work required. The Friday entries supplied a current plan for the Monday discussion, rather than an automatic allocation decision.

Different groups could organise that review by project or by staff and narrow it to an office and discipline. Jan used Oxford as one example. That allowed a local group to concentrate on the people and projects it could act on without changing the underlying allocation records.

Keep the working views current

Project managers could move a project from bid to live, completed or on hold. Completed projects then dropped out of active views while their details remained in the records. Jan also described the option to restrict allocation editing to project managers so staff could inspect a plan without changing it. Jan presented that as a configuration option rather than a single permission setup used everywhere.

A person's personal workload view depended on associating their invited account with the right staff name. That step was manual. Once associated, the view could find the projects and allocations attached to that person.

Before and after

Planning task	Before	With Jan's approach
Compare resource demand	Project requests and staff information sat in separate spreadsheets and databases.	Person, project and weekly allocation records provided one basis for the review.
Review a person's workload	Commitments across projects were harder to reconcile.	Personal and grouped views presented the same allocations for staff, project managers and resourcing groups.

About Stantec

This story concerns Stantec's Buildings group in November 2025. Jan introduced himself as a Senior Associate in the group, with a mechanical engineering background and a focus on digital work within Buildings. The resource-planning model coordinated people across projects, offices and disciplines in that part of the organisation.

What's next

At the source date, each invitation still needed a manual association between a person's account and staff record. Jan expected that onboarding hundreds of people would need an easier bulk process. Bulk onboarding remained a possible next development.

Watch Jan Artemenko's resource planning and tracking presentation, published 3 December 2025.

Try Morta on a real project.