In 1976, General Electric was among the first large companies to try out the new organizational structure called “matrix,” which is probably the most used organizational structure today. One key concern was how managers outside the business units could lead people and teams effectively when not under their direct management. Today, most organizations have implemented the matrix structure with roles such as project managers, team leads and product owners pushing for more resources to deliver their projects.
In a large organization, one of the hardest things to align on is a best practice for resource management, whether it be generating demand or allocating people — and rebalancing the effort as priorities change. Allow me to try to share some top learnings from real-life implementations.
Rule No. 1: Define Requirements For Resource Transparency
Most data on resource capacity and demand lives in gigantic spreadsheets looking several quarters or years ahead. In most cases, you will find a spreadsheet for each project, where people have been assigned for each month. These spreadsheets are then combined into a master spreadsheet, where management now sees people and roles summarized on the projects.
This means an organization can now add the total capacity, analyze if they have enough resources and adjust accordingly. Most managers want to see as far into the future as possible. For that reason, project managers and resource managers are asked to forecast several years ahead.
PROMOTEDCivic Nation BRANDVOICE | Paid ProgramHow “Black Girls Vote” Empowered Baltimore Residents To Get To The PollsUNICEF USA BRANDVOICE | Paid ProgramUNICEF Is Getting Cash Directly To Yemeni Families Who Need It MostGrads of Life BRANDVOICE | Paid ProgramWhy Investing In Jobs For Young People Can Boost Economic Recovery
The solution is for top management to define “the rule of transparency.” In other words, defining how far ahead people’s responsibilities are to be planned and separating the “roles” from “people” information. It could be expressed as the rule of 18/6, where 18 stands for “months ahead of role-based allocations” and 6 is for “named people” allocations. Some industries might require more or less transparency (e.g., in R&D-heavy organizations, where building the next product could take up to 10 years).
Rule No. 2: Roles, Not Skills
When analyzing resource capacity data, it’s important to avoid the “multiple roles per person” scenario. Some might speak English and Spanish, but that isn’t a role — it’s a skill. Instead, each person in the company should have one role that is used for allocations. Some find this hard (e.g., when a developer can also take the role of a project manager). However, if you are hired as a developer, then that is your role, and being able to also manage projects is one of your many skills.
Worst-case scenario, use the title on the business card to define a person’s role.
Rule No. 3: Only Roles, Only Names
Every project manager or product owner I have worked with always know who their favorite team members are. For that reason, it can feel frustrating to learn that they must request on role level and leave the prioritization and people selection to the resource manager in charge. However, this must be the golden rule to protect the individual employees from feeling ripped apart by the many stakeholders who want a piece of their calendar. In a big organization, the best man for the job might not be available and for that reason, so asking for named people should be a side note and not the resource request itself.
Rule No. 4: Resource Capacity And What It Means
When a project manager asks for available capacity, it means something else than when a resource manager asks the question. Resource capacity is very challenging to explain inside an organization. A person is hired to work 160 hours a month, but in a forecasting scenario, we already know the person will be on vacation for several weeks each year. We also know there will be sick days and can’t expect eight hours of productivity each day. If we do, we will be delayed on day one.
My approach is to define four types of capacity dimensions:
- Total capacity: The number of hours available according to contract.
- Adjusted capacity: The contract hours minus expected vacation and estimated nonworking days.
- Operational Capacity: Hours available for administrative and operational work.
- Project Capacity: Essentially, what is now left of hours.
Finally, in a resource request process, no one cares about the math; they will simply ask for X roles, with Y workload over Z duration. It’s not until the resource manager steps in that it becomes complicated, because they have to balance new initiatives with operational work.
Rule No. 5: Resource Breakdown Structure Is Owned By HR
Improving resource management maturity quite often leads to the implementation of an IT tool. The resource breakdown structure (RBS) is what defines the organizational breakdown, which can be used to calculate departmental capacity. The RBS is also the governance mechanism that controls which requests should go to which manager.
Considering large organizations often change their structures, it’s crucial that the HR department understands its role in administrating the RBS. Make sure HR is on board and ready to continuously update the RBS so others can focus on the request and allocation processes.
These five rules are essential to getting started with organizational resource capacity management. From here, organizations can truly begin to improve their efficiency and make better decisions from accurate data.
However, in order to feel the impact on the actual project performance, more factors than capacity and roles are in play. One key learning is from an organization that was bold enough to assess every employee using Belbin personality types. It started to benchmark project performance to discover that some of the most successful project managers were in charge of the most balanced teams, from a personality perspective.
Looking ahead, I expect to see more complexities when implementing agile operating models in a matrix organization. If an agile team is static in size, then resource allocation becomes easy. But if we don’t know the team efficiency, or how it ranks against top priorities, we could become even less agile than when working in a traditional manner.