How Matrix Management Works

Two years ago, the IT group at my company, a national think tank on workers’ compensation insurance, faced a dilemma. One of the goals we had set for ourselves was to use our website to provide the best internal and external customer support and to deliver high-quality tools to our customers. What made it a challenge was the fact that most of our programmers spent much of their time supporting existing legacy systems, while most of the new product development was being done by external consultants. Our staffers were not getting the chance to build new skills so that they could take over our new Web-enabled platform.

To solve the problem, we adopted a matrix management approach, which essentially involves rotating people based on project needs. This model has brought significant benefits to our organization. I’d like to share with you how it works.

A Matrix in Action

Within our IT organization, there are four groups reporting to the CIO: the project management office, data center operations, application systems and quality assurance. Within each of those groups, there used to be several teams that served each of our company’s three business units. So, within the application systems group, for example, there were subgroups for corporate systems, data systems and risk services. Each staffer was assigned to a particular business function; he worked on projects only for that group and never crossed boundaries.

With the matrix model, all that has changed. We have a total of 120 application programmers, and they now rotate among projects so that each person averages two large projects in a given year. For example, one programmer might spend part of the year working on a project to develop tools for our customers (Fortune 500 companies) to measure worker compensation levels, then be switched to an internal infrastructure project after that. The management team working with the staff decides who is available and has the necessary skills to work on a particular project at any given time.

During the course of a project, each application programmer reports to the technical project manager assigned to that project. (In addition, each programmer also reports to a permanent manager who helps with personal training and development.) The technical project manager reports to a manager who has responsibility for the project. For example, one project involved building a pricing tool that would allow our customers to gauge how their own pricing structure stacked up within the industry. To do that project, we brought in the technical project manager from another technical team, and programmers were selected from other teams as well. The technical project manager reported to his own manager and to the manager in charge of the particular project. The developers also reported to two people: the technical project manager on the project and their own permanent manager. Despite this complex reporting structure, the project was delivered on time and budget, and our customers loved the new tool.

Obviously, it takes a lot of cooperation to make this kind of matrix organization work. It takes a few projects and about eight months to a year to get everything smoothed out.

In the first year of using the model, we began by applying it across the application services group. To start, we prioritized the first set of projects and assigned to each a technical project manager and a business project manager, as well as the programming staff. Those initial projects ranged in duration from six months to a year. After we met with some success the first year, we then applied the process across all IT divisions, using the entire pool of programmers.

Keys to Success

One of our biggest challenges was getting people to accept the need to work with different colleagues on each project. Within IT, that was a difficult transition for some of our managers, who were used to managing the same people each time. A combination of coaching and experience over time helped us overcome the resistance. A similar phenomenon occurred among business partners, who also had become used to working with the same IT staffers on projects. In that case, the key to winning their acceptance was obtaining buy-in from senior business executives and achieving some early success on projects managed by a variety of people.

For programmers, we found it was critical to provide education about how the new organizational model worked and what benefits they would gain. One of the greatest benefits for programmers was the exposure and skills they would gain by working on different types of projects. Programmers were particularly concerned about performance evaluation and how it would work when they were no longer working directly for their regular managers on all projects. The way we handle this is by using roundtables to gather input from all the managers as well as incorporating customer feedback from the business team.

Selecting project teams is another area that involved some tricky issues. Now that each project enjoys a larger pool of talent to select from, our management team has to make sure to pick the right combination of business expertise and systems knowledge to make the project successful. It remains important to make sure a team “clicks,” both internally and with the business partners. On some occasions we have had to make changes to teams, either for personal reasons or to acquire the skills a particular project needed.

In general, we’ve found that the matrix model is great for high performers because it allows them to stay challenged without getting bored. On the other hand, it puts more pressure on poor performers, who can no longer hide under a maintenance function or a single project.

Sweet Rewards

Two years later, we’re still pleased with our matrix organization. We no longer rely on consultants for development, and we use consulting resources only when needed to supplement a skill set or a team with too few people. Our programmers have actually learned more about our business, and we’ve received positive customer feedback about their deeper understanding.

The attrition rate for our staff has also improved. Before adopting the new structure, it was as high as 10 percent, but it’s now down to about 3 percent. Staffers have said that they like having the opportunity to work on different projects with different people and getting exposed to different parts of the business.

Meanwhile, the delivery of all our benchmarking and customer data products is done through our website. We have actually reduced head count in our call center and driven down expenses as well as given customers the ability to serve themselves. In short, we have found a successful working model that we will continue to build on as we move forward and get more experience with the organization.