Eliminating Bottlenecks with Balanced Staffing
Successful outcomes require a team with all the skills needed to win. In many projects, there are skill shortages that can lead to programs that are late, over budget, or cancelled - and with the increased complexity of development, this is becoming more common than ever. Why is it a problem now? Our recession has caused many organizations to let go of many functions besides engineering, as they are often deemed as support. Inevitably, business picks up and new projects are initiated, but they often lack the key resources surrounding engineering (product management, project management, user experience, and quality). A simple tool that looks at staffing ratios - the ratio of the headcount of a skill to the number of projects - can help managers restore balance and execute more effectively.
What Is the Tool? Staffing Matrix
The staffing matrix contains a summary of all the projects in a given function (as row headings) charted against the key functions found on a cross-functional team. Typically in hi-tech, these functions would be engineering, product management, project management, user experience, and quality. Clearly, this needs to be adapted to your particular situation. These functions besides engineering are needed to ship a product and would be commonly understood as possibly contributing to delays if insufficiently staffed.
The columns consist of a list of the names of the actual team members for each function for the projects on which each individual is working. Columns can also summarize this information so that an additional column consists of the total number of projects for each staff member.
This summary can be analyzed and assessed. The first step is to see how overloaded some of the individuals are. Often the best producers are loaded up with an increasing number of projects until they break down given the workload. Management can address these individual situations. The second step is to compare the average ratio in a given function to benchmarks. In our benchmarking work, the average ratio is 1.0 product manager per product family (or major product), and the average ratio for a project manager is 1.5 projects (a large and a small project).
Our interest in staffing ratios started with a benchmarking project for a Fortune 500 company that wanted to assess best practices in new product development. We benchmarked over a dozen companies all over the world and found that the most successful had one dedicated product manager per major product. Furthermore, these product managers only focused on inbound marketing - getting the voice of the customer into the organization.
Similarly, research has been performed for the project management function, and the effectiveness was found to vary based on the number of projects managed. The curve peaks between one and two projects. The optimum workload for a project manager was found to be one large project and one small project. This allows the greatest throughput because whenever there are activity gaps in larger programs, the project manager can turn their attention to smaller ones.
What Are the Benefits?
Is a quick way to cut through politics whenever a manager asks for more people
Makes engineering much more efficient by eliminating functional shortages
Improves project outcomes because only qualified workers are assigned tasks (as opposed to having developers be a poor substitute for a quality engineer, for example)
Which Business Problems Do We Solve?
Throughput in the organization can be greatly increased because you have skilled individuals working on key deliverables rather than engineers filling in and doing their best. That’s a double win because you are no longer asking the engineering staff to work on non-engineering tasks and you also have the tasks executed better since you have trained individuals working on them. In addition, this can be accomplished by no increase in budget. For example, if you redeploy a small number of open requisitions from engineering to these critical functions, you can solve most of the imbalance problems. Furthermore, if you transfer some engineers who would like to try different functions, you can improve the balance and create a better environment for employees who would like to expand their experience.
What Are some Considerations?
There are many risks in applying this best-practice method since skill levels vary to a high degree (all are not created equal), projects vary so much in size and complexity, and the definition of some specific roles is not iron clad. So when this method is applied, all these variables must be factored in. When you are setting benchmarks on your own, the same concerns apply to the benchmark targets. A case in point is that when we discovered that the best practice is one product manager per product, we also discovered that the role of these product managers in those benchmark companies was limited to inbound marketing (no promotion, advertising, or sales force management). This means that if you do not also adjust their role when you change the ratio, you will only solve half the problem.
A large software development organization with approximately 200 engineers and 15 projects in its portfolio was having trouble getting products out on time. Morale was low because the product definition was constantly changing and the engineering team was increasingly frustrated. An analysis was performed to look at the staffing ratios, and it was discovered that there were approximately 7.5 projects per project manager while best practice is one project per project manager.
Rather than blowing the budget to hire 13 more product managers, the organization decided to convert three open requisitions from engineering into requisitions for product management. In addition, there were two engineers who wanted to get into product management, so they were transferred there and not replaced. With minimal impact to the 200 engineers, the organization was effectively able to get closer to benchmark numbers (from 7.5 products per product manager to 3 products per product manager). The organization decided to see how these changes would impact product development this year and which additional changes they would want to make next year.
This shows how overloaded the Product Management function is in this hypothetical organization.