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 Web site 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 organisation. I'd like to share with you how it works.
A Matrix in Action
Within our IT organisation, there are four groups reporting to the CIO: the project management office, data centre 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 organisation 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 prioritised 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.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.