Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Sample Organizational Structures
The next four sections describe organization schemes commonly found in software development departments:
- Project-centered organization
- Department-centered organization
- Matrix organization
- Product line organization
While none of the these structures is perfect for every software development group, each offers useful ideas for coming up with your own organization scheme.
Project-Centered Organizations
Organizations centered on project teams are typically found in smaller or newly formed groups. A project-centered organization approach is suitable for groups of about 5–40 people supporting 1–8 projects of small to medium duration, perhaps up to a year each. In such an organization, each group is primarily self-sufficient and is staffed by enough skilled developers to address every stage of the development lifecycle. This in turn means that most individuals will have responsibility for some facet of development other than just programming, such as requirements, architecture, configuration management, or testing.
As development organizations grow larger, project-centered organizations become less desirable. The number of projects may grow to outstrip the needed specialty skills, so you can't provide a developer with the needed skills for each project. Another problem is that specialist knowledge—and even general skills—tend not to be shared between individual projects that are operating in their own microcosms. As organizations outgrow project-centered structures, they often reorganize into department-centered organizations.
Department-Centered Organizations
Department-centered development organizations start to become practical as a group grows above 25 developers or 5 projects. At these staffing levels, there are sufficient people to form multiple departments centered on particular software skills or lifecycle areas. For instance, a 40-person group might have the following departments:
- System and database administrators
- User interface programmers
- Application programmers
- Configuration management, testing, and quality assurance
A common mistake in department-centered organizations is to break software architects into a separate department or group. This can lead to elitism, which is counterproductive for the following reasons:
It separates the architects from the developers who do the actual implementation. Architects quickly become out of touch with the latest development methodologies being used.
While not every developer wants to be an architect, every developer likes to have some say in the design. If developers are separated from architects, the developers may have a built-in incentive to prove that the architect's design was wrong, by not working their hardest to implement it. When this happens, the architect will most likely blame the problem on developer incompetence rather than any architectural flaws. The whole iterative development process becomes harder to implement smoothly.
Matrix Organization
When your development organization grows to several hundred people or more, consider a matrix organization. Matrix organizations are sometimes used in companies with a large number of software developers working on a broad array of software projects. One side of the matrix is organized along skill sets; the other side is organized across projects. In a matrix organization, every developer has two managers. One manager is from the department or skill set matrix and one manager is from the project matrix. A developer typically stays in a single department for as long as his or her particular skill is needed in that area, and then returns to his or her department for another assignment. Employees might be assigned to multiple projects, and some projects might not require employees from every department.
Individual departments are responsible for hiring and training developers and supplying them to projects as needed. Department managers work with project managers to properly forecast requirements and equitably assign developers to projects with regard to the best interests of the corporation.
A matrix organization obviously requires a certain minimum size to sustain the overhead of two management chains. One challenge with such an organization is to develop the right number and mix of departments. Another challenge is to sustain developer loyalty to projects when their long-term management lies in the department organization. Because of these issues, a product line organization may be a better choice.
Product Line Organizations
In a product line organization, developers are organized into projects based on business product lines as opposed to skill set departments. A product line organization is responsible for staffing the skill sets required for its project mix. For instance, one product line might have requirements analysts, OS experts, some web developers, and configuration management. Another product line might have requirements analysts, real-time coding experts, and configuration management. This works if product line organizations are sufficiently large that enough developers exist to staff duplicated functions throughout departments. The downside is that software projects will often require different sets of skill levels at different times in the software lifecycle. Each product line must always have sufficient resources to staff for peak periods while worrying about the lulls in between.