Figure 11-1 maps roles and responsibilities to a default line-of-business organization.
This structure can be tailored to specific circumstances.
The main features of the default organization are as follows:
• Responsibility for process definition and maintenance is specific to a cohesive line of business, where process commonality makes sense. For example, the process for developing avionics software is different from the process used to develop office applications.
• Responsibility for process automation is an organizational role and is equal in importance to the process definition role. Projects achieve process commonality primarily through the environment support of common tools.
• Organizational roles may be fulfilled by a single individual or several different teams, depending on the scale of the organization. A 20-person software product company may require only a single person to fulfill all the roles, while a 10,000-person telecommunications company may require hundreds of people to achieve an effective software organization.
Software Engineering Process Authority
The Software Engineering Process Authority (SEPA) facilitates the exchange of information and process guidance both to and from project practitioners. This role is accountable to the organization general manager for maintaining a current assessment of the organization's process maturity and its plan for future process improvements. The SEPA must help initiate and periodically assess project processes. Catalyzing the capture and dissemination of software best practices can be accomplished only when the SEPA understands both the desired improvement and the project context. The SEPA is a necessary role in any organization. It takes on responsibility and accountability for the process definition and its maintenance (modification, improvement, technology insertion). The SEPA could be a single individual, the general manager, or even a team of representatives. The SEPA must truly be an authority, competent and powerful, not a staff position rendered impotent by ineffective bureaucracy.
The Project Review Authority (PRA) is the single individual responsible for ensuring that a software project complies with all organizational and business unit software policies, practices, and standards. A software project manager is responsible for meeting the requirements of a contract or some other project compliance standard, and is also accountable to the PRA. The PRA reviews both the project's conformance to contractual obligations and the project's organizational policy obligations. The customer monitors contract requirements, contract milestones, contract deliverables, monthly management reviews, progress, quality, cost, schedule, and risk. The PRA reviews customer commitments as well as adherence to organizational policies, organizational deliverables, financial performance, and other risks and accomplishments.
The Software Engineering Environment Authority (SEEA) is responsible for automating the organization's process, maintaining the organization's standard environment, training projects to use the environment, and maintaining organization-wide reusable assets. The SEEA role is necessary to achieve a significant return on investment for a common process. Tools, techniques, and training can be amortized effectively across multiple projects only if someone in the organization (the SEEA) is responsible for supporting and administering a standard environment. In many cases, the environment may be augmented, customized, or modified, but the existence of an 80% default solution for each project is critical to achieving institutionalization of the organization's process and a good ROI on capital tool investments.
An organization's infrastructure provides human resources support, project-independent research and development, and other capital software engineering assets. The infrastructure for any given software line of business can range from trivial to highly entrenched bureaucracies. The typical components of the organizational infrastructure are as follows:
• Project administration: time accounting system; contracts, pricing, terms and conditions; corporate information systems integration
• Engineering skill centers: custom tools repository and maintenance, bid and proposal support, independent research and development
• Professional development: internal training boot camp, personnel recruiting, personnel skills database maintenance, literature and assets library, technical publications
An organizational service center promotes a standard environment funded by the line of business and maintained as a capital asset for projects within the organization. The SEEA is a companion group to the SEPA. The SEPA is responsible for process definition and improvement, and the SEEA is responsible for process automation.
It is important that organization managers treat software development environments just as hardware development environments are treated—namely, as capital equipment. There is resistance to this approach in most small-scale or immature organizations, where specific process development and tooling are included as direct project expenses. For most mature software organizations, the process and tooling should be organizational assets, just as they are in other engineering disciplines. As such, they should be funded with capital resources. Financing models can include absorption into overhead or general and administrative costs, or project billing based on usage. In today's software industry, characterized by ingrained accounting methods, project-funded tooling, and software licensing methods, relatively few organizations have transitioned to such a capital investment model for their software environments. These organizations tend to be mature, large-scale software developers that have achieved stable process definitions and have established long-term partnerships with software tool vendors.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.