Organizing for Successful Software Development
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many CIOs recognize that the organizational structure of their software development group has an impact on the success of their application development efforts. Unfortunately, there is not always the same level of consensus between CIOs on what the correct organizational structure should be. This article describes organizational structures for small, medium, and large software development organizations and examines the importance of these structures to successful software development. We also discuss centralized versus decentralized organization and the use of virtual project teams.
The Dimensions of an Organization
An organization is defined by much more than boxes containing job titles and names connected by lines representing a reporting structure. In addition to structure, there are multiple dimensions to an organization:
People. Each individual in an organization has certain skills, and these skills are typically measured against formal or informal performance metrics leading to rewards (compensation) as incentives for future performance. The people in an organization establish its culture—those behavior patterns and values that are generally recognized as being adopted.
Process. The procedures and methodologies used by people in the organization. Almost all organizations define their own internal economies through processes for budgeting, priority settings, and project approval.
Technology. The specific skills and tools that people in the organization use to carry out the business functions of the organization.
The Importance of Organizational Structure
Of the different people, process, and technology dimensions of an organization, structure is by far the most fundamental. Without a sound structure, people in the organization lose their culture and compete for individual rewards rather than for the good of the organization. Without structure, processes have no home, and internal economies collapse because of conflicting objectives. Without structure, technology is pursued as a research interest rather than for the good of the organization. While these concepts hold true for any information technology organization, they're especially applicable to software development organizations, no matter what their size.
Many a software startup begins life with no more than a couple of developers working out of a garage. Not much organizational structure is required at this point in a company's history, but organizational structure still exists. For instance, in 1977, when Bill Gates and Paul Allen formed their partnership and officially named it Microsoft, the company had minimal organizational structure. Fewer than a dozen employees worked at Microsoft's first office in Albuquerque, New Mexico, and everyone knew who was in charge. No complicated organizational charts were needed to figure out everyone's reporting structure. At the same time, all employees knew their role in the company and what they were trying to accomplish. This was because any organizational structure that was needed could be informally communicated between each of the employees.
At the other end of the spectrum are IT departments of Fortune 500 companies, large independent software vendors, and commercial system integrators. An entry-level programmer at Microsoft today probably needs several different organizational charts to show the reporting structure among 20,000+ employees and up to Bill Gates. Having organization charts alone, unfortunately, is no guarantee of a healthy corporate structure. In any large organization, there are many dimensions to measuring the success of the corporation's structure. While no organizational model fits all development departments, certain traits stand out among companies that routinely produce successful software products.
Streamlining Bureaucracy
One of the side effects suffered by many development organizations as they grow is increased bureaucracy. Although we focus on people and process issues here, the aim is to help streamline bureaucracies, not develop new ones. For instance, at some companies, a standard operating procedure is that, with few exceptions, no document shall ever require more than two approvals: one from the person who authored the document and one from the final approver. In addition to empowering employees, this strategy makes it very simple to place blame when an incorrect decision is made. It also removes the possibility of two superiors rejecting a document and sending it back to the original author with conflicting modifications.