Context of our client
Our client is an energy system operator, serving industrial customers via proprietary distribution networks.
It relies on a large I.T (Information Technology) department, which is divided in multiple teams who are each responsible of specific tasks (Maintenance, security, DevOps, etc.).
All I.T teams planned their work each year:
- according to their own team budget,
- without taking transversal projects and tasks into account,
- without sharing a common a view on the ratio between maintenance and project work.
As a result, problems were bound to occur and escalate exponentially. The smallest flap of a butterfly’s wing on a developer’s ear would cause tornados in project roadmaps and server rooms.
Portfolio was thus forced to lead the I.T department “in the dark”, as it could not answer questions like:
- Who will do the work?
- When can resources do a task?
- What is the work that needs to be done?
- What should the priorities be?
Portfolio was well aware of these issues — recurrent roadmap and agenda alignment meetings were painful to go through. Worst: business did fully trust their ability to commit on project delivery.
These circumstances hindered the capability of Portfolio and Project managers to shine at their job and highlighted since long the need for the implementation of a Resource Capacity Planning solution. But, before our journey together, 3 earlier attempts to implement Resource Capacity Management did not hit the mark.
We were mandated to restore the trust of Business in the IT department. Our logical first step was thus to bring Resource Capacity planning in the picture, so that I.T could mathematically prove its ability to deliver projects in the future.
Initial Starting point:
When our journey started together, all managers were sceptical.
We expected it. Our team was about to start a journey many had tried, but none had succeeded. It took numerous meetings with all managers, pinpointing the pitfalls in which they fell in the past to make resistance vanish.
Despite having the mandate on Portfolio’s side, and managers’ trust, we knew the success rate was dependent on operation adoption.
Into the action
We started organized information sessions about what would be the added value for them in our Resource Capacity Management solution, with use cases from our past missions.
We did not however overpromise a tool implementation that would only work in a world where:
- data is matching the reality perfectly
- department culture is aligned on the readiness to change way of working
- everyone is aware of how to get insight and act
Instead, we implemented a fully customized Capacity Planning Prototype. By building a high-level overview of the workload of all teams (and of what they requested from each other), we diagnosticated:
- Issues with the scope definition method
- Maintenance budget was way above industry standards.
- Every resource was fully booked, even before the year had started, without any buffer for extra projects, holidays, or sickness.
- Based on the 2021 budget, previous years’ lead times, and interviews with team leaders, we determined the workload for each of the teams for 2021 and compared it with the available capacity.
- We then tried to spread the workload over the year. N.B.: some teams may have sufficient resources for their projects over the year, but that does not mean that capacity is available when needed on each project.
- Keeping the numbers up to date is a key success factor.
The figures thus initially kept up to date through meetings with the different team leaders to know the status of the projects and eventual changes in the different teams.
This data was then uploaded into our Excel prototype, which, per request of the client, to become integrated into Project Online (Microsoft’ Cloud-based PPM Solution). We took that opportunity to analyse how to adapt existing processes, so that project managers could directly share the status updates of their projects as well as the number of days remaining for each team in their project.
What we learned on the spot
- Many ideas (that turned into projects on a whim) did not have a project manager making it more complicated to know the corresponding workload.
- Many teams did not update lead time with the correct task name.
- In view of the figures we collected through Microsoft tool, we noticed that team leaders often forgot to plan work for the support teams, which are the specific teams in which we found recurring “bottlenecks”.
We therefore lowered the priority of the Microsoft Project Online integration and worked first on user adoption of the prototype before going further
Instead of asking lead time to Project Managers, we set up an automated data gathering process which transform the information teams have at hand into normalized data for our Capacity Planner to work with
The prototype 2.0 then gathers that data and automatically calculates the workload for the different teams and distributes it over time according to the project dates and the different project phases.
Portfolio and I.T managers are now able to see at one glance:
- the transversal needs,
- the work distribution
- the project bottlenecks
At the team level, they can see for example a 3.4 FTE shortage in the month of August for the budgeted work. With that level of proof in hand, I.T department is empowered to ask the business department for more budget in accordance with their requirements or to rethink their priorities.
In other words, the trust is back.
The quick next step would be that when projects are assigned to a project manager, the latter checks and updates the data pre-calculated thanks to the questionnaire.
This point is however still a question mark, as it changes the project manager function, implies training about new processes and new responsibilities.
The long-term goal is to implement a project management methodology to document the processes above and take us one next step toward a sustainable Target Operating Model.
- Update Project Management Processes
- Implement Project Management Methodology
- Create a sustainable Target Operating Model.