White Paper

The Matrix Organization for Information

Technology Departments

July 2004
Contact Information
This information was prepared by:

Randal J. Goodman, Principal

rjg@rjgtech.com
voice 610.999.0358

R J Goodman Technologies, Inc.

377 Covered Bridge Road, Suite 100
King of Prussia, PA 19406
610.992.0720
FAX: 523.540.7886

www.rjgtech.com

This document is protected under the copyright laws of the United States and other countries as
an unpublished work. This document contains information that is proprietary and confidential to
RJ Goodman Technologies that may not be disclosed, duplicated or used in whole or in part for
any purpose other than to evaluate our services. Any such use or disclosure in whole or in part of
this information without express written permission from RJG Tech is prohibited.

© 2004 RJ Goodman Technologies. (Unpublished). All rights reserved.

The Matrix Organization for Information Page 2 of 17

Technology
Table of Contents
1. Purpose ............................................................................................... 4
2. Introduction ........................................................................................ 4
3. Organizational Models........................................................................ 5
3.1 The Functional Organization .......................................................................................... 5
3.2 The Project Organization ............................................................................................... 6
3.3 The Matrix Organization................................................................................................. 6
3.4 Strengths and Weaknesses of These Models for IT Organizations............................... 7
4. The New Information Technology Organizational Model .................. 8
4.1 Functional Management................................................................................................. 9
4.2 Product/System Design................................................................................................ 10
4.3 Architecture .................................................................................................................. 11
4.4 Programming................................................................................................................ 12
4.5 Testing.......................................................................................................................... 13
4.6 Documentation ............................................................................................................. 14
4.7 Project Management .................................................................................................... 15
4.8 Software Engineering Process Group.......................................................................... 16
4.9 New Organization Chart by Roles................................................................................ 17
5. Conclusion ........................................................................................ 17

About the Author - Randal J. Goodman

Mr. Goodman is a founding principal of RJ Goodman Technologies, Inc., a consulting
firm specializing in project and program management as well as IT strategy and
implementation.
Mr. Goodman has over twenty years experience in creating business opportunity using
information technology. His client industries include healthcare, high-tech product
development, eCommerce services and the government sector. His strengths include
extensive technical knowledge, strong analytical skills, and the ability to organize and
direct large, geographically disparate teams. Mr. Goodman has extensive experience in
enterprise project management, organizational development, full life cycle software
development and data & process modeling using several different techniques. Mr.
Goodman also possesses strong leadership skills, is an excellent listener and is able to
relate well with all levels of employees and management. He is a strong mentor, coach,
implementer and leader.

The Matrix Organization for Information Page 3 of 17

Technology
1. Purpose
The purpose of this white paper is to:
! Highlight the basic differences between organizational process models
! Break down a typical Software Development matrix organization and show the
organizations purpose, interfaces and the associates’ roles within the organization.
Implementing a matrix organization is very difficult, due to the
perceived additional overhead of the functional and project
views. But, when implemented properly, a matrix organization The Matrix Model
provides for all relevant project processes so your people can provides the best
focus on the creative aspects of their craft; not continually balance of project
reinventing the “process wheel”.
accountability with
the ability to
2. Introduction cultivate and
There are many ways to organize an Information Technology leverage strong
department. The organization must address the following function skills and
responsibilities: processes.
1. Project Planning and Control
2. Change Management
3. Communications
4. Project Leadership
5. Departmental Personnel Training and Development
One way that has worked effectively in other organizations is to use a project-based
organization – usually termed the “Matrix Model”.
The Matrix Model benefits Information Technology organizations in the following ways:
! Better leadership than a functional group because there is a one position of
responsibility and authority within a project.
! Better communication between functional areas since the work is coordinated
centrally at the project level.
! Policies and training are improved since there is now a functional manager with the
direct focus on the needs of the staff.
In short, the Matrix model provides the best balance of project All
accountability with the ability to cultivate and leverage strong organizations
function skills and processes. The various organizational models
considered are described below. should care
deeply about
the success of
their projects.

The Matrix Organization for Information Page 4 of 17

Technology
3. Organizational Models
There are three major organizational models for an information technology group:
! The Functional Organization
! The Project Organization
! The Matrix Organization
In the following examples, a software development organization is exemplified.

3.1 The Functional Organization

The functional organization is structured around the major Information Technology
functions, including Requirements, Design, Coding, QA, Documentation, and
Configuration Management. The actual departments may combine a number of related
functions. For example, the “Design” group may perform Requirements Analysis,
Specification, and High Level Design of the application. The organization is structured
so that personnel may become “specialists” in the particular area that best suits their
talents and interests.

Head of
Development

Architecture Design Programming QA Documentation

Figure 1: The Functional Organization

The functional organization makes use of the fact that the major software engineering
functions follow a well-known pattern known as the systems development life cycle.
Projects are accomplished by passing the work from one department to another as the
project moves though its life cycle.
After the completion of the project, the new software may become the responsibility of a
“maintenance” group, which may be a part of the same department, or a separate one.
This group will learn the software and perform minor maintenance. A major new release
of the software will prompt a new project to be initiated.

The Matrix Organization for Information Page 5 of 17

Technology
 There is no single supervisor over the entire project. No one person is “in charge”.
Instead, there is a project coordinator, who does not have the responsibility or authority
to hire, discharge, train or promote people within the project. Moreover, the coordinator
will have very limited or no authority to control the project by taking corrective action.
The coordinator is mainly responsible for monitoring progress on the project and
facilitating communication among the functional departments.

3.2 The Project Organization

At the other end of the spectrum from the Functional Organization is the Project
Organization. In the project organization, the initiation of a project causes the
organization to create a project team.

Head of
Development

Project A Project B Project C Project D Project E

Figure 2: The Project Organization

The project manager has full authority to hire, fire, train and promote people during the
course of the project, as well as take corrective action. In fact, the project manager has
all of the “planning”, “organizing”, “staffing” “directing” and “controlling” responsibilities
and authorities described earlier.
Project teams may be formed from pools of available personnel, or from outside
contractors. At the end of the project, the team is disbanded.
A true project organization will treat requests for service as a
project. For example, a maintenance request to an existing
product that enters the Development organization will cause
The Matrix
the creation of a project team – there is no “maintenance Organization
organization” within Development. If such an organization requires the most
exists, it is always outside of the Development organization detailed definition of
and it handles minor software maintenance requests responsibility.
independently of Development.
Without it, managers
will find it very
3.3 The Matrix Organization
difficult to determine
The Matrix Organization has characteristics of both the
Project and Functional Organizations. The project manager
the limits of their
has the responsibility and authority for completing the authority.

The Matrix Organization for Information Page 6 of 17

Technology
 project. The functional managers provide the resources needed to conduct the project.
These resources are assigned temporarily to the project team, and after the project is
disbanded, they return to the functional area.

Head of
Development

Architecture Design Programming QA Documentation

Project Architet Designer Programmer QA Lead

Doc
specialist
A

Figure 3: The Matrix Organization

In the matrix organization, the project manager usually does not have the full authority to
hire, fire, train or promote people. The project manager does manage the day-to-day
supervision of the project personnel, but the functional manager is responsible for their
career planning, training and well being.
Since the individual worker is “supervised” by two separate managers, this system is
sometimes called the “two-boss” system.

3.4 Strengths and Weaknesses of These Models for IT Organizations

Few organizations fit any one of these models perfectly, but many come close. The
following summarizes the strengths and weaknesses of the three models.

Functional Organization
Strengths
Organization already exists, allowing for
quick project start up and phase down.
Recruiting, training and retention are
easier. Associates can develop deep
expertise in their functional areas.
Policies, procedures, standards, methods,
tools and techniques may be established
Weaknesses
No central position of responsibility or
authority for any project
The interface between development
functions may cause problems, and these
problems are typically difficult to solve,
particularly due to the “pier-to-pier” nature
of the functional areas.
Projects are difficult to control. High risk of
“runaway” projects, as no one will have
ultimate delivery authority and

The Matrix Organization for Information Page 7 of 17

Technology
 prior to the initiation of the project responsibility, resulting in “finger-pointing”.

Project Organization
Strengths
A central position of responsibility and
authority exists for the project. Highest
level of project control.
Much easier to pass work across the
software engineering functions as each
function resides inside the project team.
Decisions can be made quickly.
Staff motivation is typically high.
Weaknesses
Organization must be formed for each
project.
Recruiting, training and retention may be
more difficult.
Policies, procedures, standards, methods,
tools and techniques may need to be
established for every new project.
Team members may not develop deep
knowledge in a functional area.

Matrix Organization
Strengths
A central position of project responsibility
and authority is created, compared to
functional format
Fewer difficulties in passing work across
the software engineering functions than the
functional format.
Recruiting, training and retention should be
easier than project organization.
Policies, procedures, standards, methods,
tools and techniques should already be
established
It is easier to start and end a project than
in project organization.
More flexible use of people is possible than
either project or functional formats.
Weaknesses
Responsibility for and authority over
project members is shared between two or
more managers – unlike project or
functional organizations.
It may be too easy to move people from
one project to another, unlike functional or
project formats.
Staff motivation may be lower than the
project format.
Greater competition exists for resources
than project or functional format.

4. The New Information Technology

Organizational Model
Some major concerns within Information Technology today include scope creep,
improved estimation of effort, duration and the ability to complete projects on time and
under budget. Any organization is under severe time to market pressures and would like

The Matrix Organization for Information Page 8 of 17

Technology
 to provide more effective career development and training. These can be accomplished
by moving to the matrix organizational model.
The matrix organizational model will help in several ways. They are:
! Provides easily identifiable project leadership
! Formalizes the project planning, status and control processes
! Provides distinct responsibility for best practices, functional policy and procedures
and training,
! Provides for easier Change Control mechanisms
The following section describes the roles within the new organization. These roles will
evolve and provide the basis for job descriptions and career ladders. Some of the roles
have a single project focus, while others have a more global focus. On the “Role
Organization Chart”, the single project focused roles are identified with a “D” (Dedicated)
while the more global roles are identified with an “SS” (Shared Services).

4.1 Functional Management

Purpose
Each functional area has functional directors and leads. Their primary role is to be a key
functional resource for projects, enhancement and support. They are responsible for
making sure good project decisions are made within their functional areas. They will do
that by ensuring knowledge is transferred in their areas. They also will establish and
educate their functional areas on best practices, policies and procedures. Functional
management will also facilitate career development of the functional team members -
career path, career plan, training, etc.
It is within these functional areas that specific thought leadership and responsibility is
necessary to incorporate internal lessons learned from each project and evolve the
thinking, approach and delivery of these skills for future projects. From this perspective,
functional managers must help define, track and take responsibility for project
performance metrics related to their functional area.

Roles
Team Lead – Ensure good project decisions are made within their functional area via
best practice and resource management
Director – Ensure overall policies are followed and skill sets are managed and evolved.

Comparison of Management Responsibilities

Project Manager Responsibilities Functional Manager Responsibilities
1. Day-to-day tasks 1. Best Practices
2. Project Status 2. Technology Usage
3. Schedule 3. Technical Guidance

The Matrix Organization for Information Page 9 of 17

Technology
 4. Tracking 4. Policies and Standards
5. Issue Resolution 5. Walk-through Participation
6. Risk Assessment and Mitigation 6. Training
7. Change Management 7. Equipment/Tools
8. Lessons Learned 8. Functional Status
9. “Dotted-Line” Management

4.2 Product/System Design

Purpose
Product Design’s (may be called System Design) mission is to work with Marketing,
Support and Sales or other operational business units to define the product or system
requirements.
In organizations that are developing commercial software, Product Strategists work with
Product Managers in Marketing to develop product roadmaps and strategic plans.
Product Analysts define, analyze and document the product requirements and
communicate the project goals and objectives in the framework of a Project Charter.
In organizations that are developing custom software for internal business units, a
similar requirements process is used that defines a system roadmap and strategic plan.
Again, the overall project goals and objectives are developed into the framework of a
Project Charter that justifies moving forward and allocating resources.
Designers are responsible for the visual presentation of the software and the
development of use-cases that describe how the software will be used. The documents
produced by the Product Design team are the Strategic Plans, Product Roadmaps,
Project Charters, Business Requirements, and User Requirements documents. All roles
will have extensive interaction with marketing and internal or external customers.

Interaction with Other Groups

Product Design customers Product Design is a customer of
! Customers ! Marketing
! Programming ! Support
! Testing ! Sales
! Documentation ! Customers
! Support
! Sales
! Project Management

The Matrix Organization for Information Page 10 of 17

Technology
 Roles
Product/System Strategist – Produces Strategic Plans and Product Roadmaps
Product/System Analyst – Produces Use Cases, Business Requirements, User
Requirements, and Project Charters
Research Engineer – Produces White Papers and feasibility studies
Product Designer – Produces GUI Design Documents, Specifications
Usability Engineer – Produces Usability Profile and test results

4.3 Architecture

Purpose
Architecture’s mission is to work with Product Design, Programming, and Testing to
develop and evolve technical infrastructures, high-level application architecture and data
architecture. The architecture team members all have a strategic vision as well as
project responsibilities. Infrastructure Architects work with Software Engineers and
Software Test Engineers to define and build the application middleware layer.
Application Architects work with Product Designers, Software Engineers and Software
Test Engineers to develop the high-level application architecture components. Data
Architects work with Software Engineers and Software Test Engineers to develop data
definitions and structures that are used across all products. Architecture reviews and
participates in the creation of Specifications, Product Prototypes and Designs, and
produces Architectural Design documents.
In a Matrix Organization, the Architecture functional area has the responsibility and
opportunity to see across projects and coordinate and leverage architecture decisions
and investments for the overall benefit of the organization – and this is balanced with the
needs of the individual projects. The matrix organization must be prepared to arbitrate
when the needs of the project are not consistent with other needs of the organization.

Interaction with Other Groups

Architecture customers Architecture is a customer of
! Programming ! Design
! Testing

Roles
Infrastructure Architect – Determines overall technical framework used and application
middleware layer
Application Architect – Determines high-level application architecture components
Data Architect – Determines data definitions and structures that are used across all
products

The Matrix Organization for Information Page 11 of 17

Technology
4.4 Programming

Purpose
The Programming area’s purpose is to produce high quality software by using
specifications, prototypes, architectural and data designs to develop software modules
that are unit tested. Programming produces Detailed Design documents, Code, and Unit
Test Plans.
Project teams will be assembled quickly and are expected to deliver as quickly as
possible. These teams should not usually be burdened with the development of coding
techniques and tool selection. The Programming area should have best practices, tools
and trained staff ready. These functional areas will typically need to develop a “tool box”
of coding tools from which individual project may select those that are most appropriate.
Organizations that our developing software for internal use may have a tool box that
includes tools necessary for enterprise application development, e-commerce/internet
application development, small application development as well as reporting and
analysis tools. If these standard tools do not meet the needs of a project, then the
project team, with the participation of the functional area will need to find new tools as
part of the project plan.

Related Infrastructure and Development Responsibilities When

Developing Software for Internal Business Customers
Other system development activities such as the implementation, tuning, and
maintenance of application software such as web and application servers, document
management systems and database servers will find homes in functional areas that are
charted to support them. As with the Programming functional area described here,
these teams are responsible for supplying resources to the project.
A functional area such as Data Management may or may not be aligned with the
Architecture functional area. If not part of architecture, Data Management also has the
responsibility to coordinate the use, management and design of data across projects to
meet the long term needs of the organization. Project must not be allowed to create
“silo” systems that are not coordinated
If these internal infrastructure areas do not properly allocated staff and physical
resources to the projects, they will quickly find themselves out-of-sync with the priorities
of the projects. This is one of the quickest ways to develop animosity between a
business unit and the IT organization.

The Matrix Organization for Information Page 12 of 17

Technology
 Interaction with Other Groups
Programming Customers Programming Is A Customer Of
! Testing ! Architecture
! Documentation ! Product Design
! Support ! Project Manager
! Sales ! Testing
! Customers

Roles
Software Engineer – Produces Detailed Designs, Code and Unit Test Plans
Senior Software Engineer – Produces Detailed Designs, Code and Unit Test Plans
Principal Software Engineer – Produces Detailed Designs, Code and Unit Test Plans
Data Base Application Engineer – Produces SQL, scripts, triggers & procedures to
access the data base
Data Base Administrator – Builds and tunes the physical data base

4.5 Testing

Purpose
The Testing Departments’ primary function is to identify defects, isolate their cause, and
report them to developers.
The process of testing involves:
! Test planning & design
! Test execution & verification
! Automated test development
! Defect tracking
Testing types include: functional, software/hardware compatibility, setup, localization,
performance and scalability, error handling and recovery, reliability and robustness.
Testing produces Test Plans, Bug Reports.
While each project may require significantly different testing approaches and test cases,
the functional area, as possible, must be able to leverage a suite of test cases that can
be used as a starting point when each project seeks to implement a related system.

The Matrix Organization for Information Page 13 of 17

Technology
 Interaction with Other Groups
Testing Customers Testing Is A Customer Of
! Programming ! :Architecture
! Documentation ! Product Design
! Support ! Project Manager
! Sales ! Programming
! Customers

Roles
Software Test Engineer – Produces Test Plans and Bug Reports
Senior Software Test Engineer – Produces Test Plans and Bug Reports
Principal Software Test Engineer – Produces Test Plans and Bug Reports
Test Automation Engineers – Produces Test Automation and Training
Software Measurement Engineer – Produces Metrics and Meters

4.6 Documentation

Purpose
The Documentation Group’s primary purpose is to provide accurate, concise, complete,
user-friendly documentation that enables our customers to effectively use our products
to solve their business needs. In addition, the Documentation Group works closely with
the Product/System Design Group to develop easy-to-use user interfaces. The
Documentation Group also provides editorial/graphic/publication support for other areas
of the company. In some cases the documentation group may also be responsible for
the development of training materials.
Whether for a commercial product or for internal users, the Documentation area must be
able to develop consistent documentation so that users of a system developed by one
project will be comfortable with and feel familiar using the documentation resulting from
a different project.

Interaction with Other Groups

Documentation customers Documentation is a customer of
! Customers ! Product Design
! Professional Services ! Project Management
! Marketing ! Programming
! Sales ! Testing
! Customer Support ! Marketing

The Matrix Organization for Information Page 14 of 17

Technology
 Roles
Technical Writer – Produces Documentation
Senior Technical Writer – Produces Documentation
Senior Editor – Edits Documentation
Graphic Artist – Produces Printed Manuals and Other Graphic Arts

4.7 Project Management

Purpose
The Project Management Team’s purpose is to manage projects, releases and patches
through to completion. All roles in Project Management are involved in planning,
organizing, staffing, directing and controlling. Naturally, a consistent methodology must
be implemented across all projects. The team must have the ability to control the level
of detail used to manage small projects compared to large projects.

Interaction with Other Groups

Project Management customers Project Management is a customer of
! Architecture ! Project Stakeholders
! Design ! Design
! Programming
! Testing
! Documentation
! Support
! Consulting
! Training
! Sales
! Production
! Marketing

Roles
Project Planner - Reports to the project manager; responsible for maintaining project
plans and project documentation
Project Lead - Reports to the project manager; responsible for a team within a project
Project Manager – Responsible for the success of project. Has decision-making
authority for resources, budgets, issues, risks and scope of a project

The Matrix Organization for Information Page 15 of 17

Technology
 Program Manager – Responsible for the success of a related group of projects

4.8 Software Engineering Process Group

Purpose
The Software Engineering Process Group is a central force for process improvement.
The group maintains the overall view of current efforts and facilitates these efforts on a
continuing basis. Its members foster collaboration between everyone in the organization
who is involved with software process improvement.

Interaction with Other Groups

SEPG Customers SEPG Is A Customer Of
! Architecture ! Architecture
! Design ! Design
! Programming ! Programming
! Testing ! Testing
! Documentation ! Documentation

Roles
Software Process Engineer – Manages implementation and maintenance of SDLC and
PM processes
Tool Designer/Developer – Supports design, research and acquisition of tools to
support the SDLC and PM processes

The Matrix Organization for Information Page 16 of 17

Technology
4.9 New Organization Chart by Roles
Vice President - Product
Development

Director - Manager - Director - Manager - Director - Project

Director - Testing
Design Architecture Programming Documentation Management

Software Software Test Software Process

Product Strategist Infrastructure Architect Tchnical Writer Release Manager
Engineer Engineer Engineer
SS SS SS/D D
D D SS

Senior Software Senior Software

Senior Tchnical Project Planner Notes Designer
Application Architect Engineer Test Engineer
Product Analyst Writer D SS
SS/D D D
SS/D SS/D

Principal Principal SEPG

Program
Software Software Test
Senior Editor Manager
Data Architect Engineer Engineer
Research Engineer SS SS/D
SS/D D D
SS
Software Project Management
Configuration
Measurement
Architecture Manager
Engineer Graphic Artist
Product Designer SS
SS SS
D
Database
Build Engineer Documentation
Administrator
SS
Usability Engineer SS
SS
Programming System
Administrator
Design
SS

Testing

SS - Shared Service
D - Dedicated Service

Figure 4: Revised Organization Chart

5. Conclusion
Many organizations will find that a strictly functional
organization can not properly take responsibility for the A significant reason
delivery of projects. All organizations should care deeply for business units
about the success of their projects. Often, the functional losing confidence in
approach can lead to a perceived misalignment in goals and
their IT organization
priorities.
is a perceived
In many cases, organizations will formally establish “project
teams” but will not formally incorporate them into the
misalignment in
organization structure or define roles and responsibilities. The goals and priorities.
shift to a matrix organization requires attention to specific
project and organization needs as well as to culture and existing skill sets.
When organizations formalize their need for and implementation of project teams, the
switch to a matrix organization can result in real benefit and collaboration, and most
importantly, project success.

The Matrix Organization for Information Page 17 of 17

Technology