Communications of the ACM
Home/Magazine Archive/December 2000 (Vol. 43, No. 12)/Sharing Standards: Standardizing Software Projects/Full Text
Communications of the ACM
Sharing Standards: Standardizing Software Projects
Companies wishing to prosper today are finding that effective management of software engineering projects is one of the single biggest contributors to competitive advantage.
If an organization has many software engineering teams, then some standardization of methods across teams is important. Deployment of a corporate software engineering organizational standard with consistent roles and schedules across projects can lead to various benefits, including:
- Better planning, both short-term and long-term, leading to more predictable outcomes; and
- Increased staffing flexibility (decreased sensitivity to employee turnover) as well-defined roles and processes repeated across project teams facilitate reuse of experience.
These benefits might not be seen easily in the life of a given project but will be obvious across an organization and over the lives of many projects. What can be learned from the experiences of companies as to how to standardize the operation of software projects? The following are examples of how various organizations attempt to standardize.
Dell
Dell has an information technology division of approximately 2,500 employees. These people develop Dell's IT infrastructure in collaboration with the company's business units that use this infrastructure. The method of standardization at Dell began with a strict approach and evolved into a loose approach. This loose approach hindered productivity, and in 1998 a division-wide standardization of team methodology was initiated.
Dell's IT division reviewed available standards it could adopt that would be consistent with its principles. These principles are that teams should work closely with business units and should act quickly and creatively within the bounds of a well-defined, systematic approach across Dell IT. To support such teams Dell chose the Microsoft Solutions Framework (MSF).
MSF
Originally based on best practices within Microsoft product development and IT organizations, MSF (www.microsoft.com/msf/) was created in 1994 to promote consistency and effectiveness within the Microsoft Consulting Services organization. Research and customer feedback has continually contributed to the improvement of MSF. Additionally, Microsoft offers training courses in MSF and over 25,000 people have taken MSF courses.
The enforcing of consistent standards across many projects is perhaps the least well-understood problem in software management.
MSF revolves around a team with a process. The team has well-defined roles with a customer focus represented by a small number of people who interact on a peer-to-peer basis. The process is iterative and supports rapid prototyping.
Each MSF project team has six roles. These roles and their focus are:
- Product management; focuscustomer satisfaction
- Program management; focuson-time delivery
- Development; focusa responsive, compliant system
- Testing; focusa compliant, high-quality system
- User education; focusa usable, supportable system
- Logistics planning; focussmooth rollout and migration
Each role may be assumed by a handful of different people. What is important for the team is that the role discharges its responsibilities. Also, a team should be small, totaling no more than about a few dozen people.
The process model describes the phases, milestones, activities, and deliverables of a project and their relationship to the team model. The process model's underlying practices and principles include:
- Using versioned releases;
- Scheduling for an uncertain future;
- Managing trade-offs;
- Managing risk;
- Maintaining a fixed ship-date mindset;
- Breaking large projects into manageable parts;
- Performing daily builds; and
- Using bottom-up estimating.
Tying together the roles and the processes are documents delivered by roles at precise points in the iterative process. MSF provides detailed document templates. For instance, the "vision and scope" document for a project must be delivered at the beginning of a project with the input of all the roles and under the responsibility of the product manager. The "vision and scope" document template has over a dozen headings and guidance as to what should be provided under each heading.
Across Dell Teams
In early 1999, all the Dell IT project managers were trained in the use of MSF. Dell's IT policy document states that every new project must comply with MSF. However, in late 1999 a survey of the impact of MSF on division behavior showed that typical project teams were performing similarly to how they had before the introduction of MSF and that the diffusion of MSF throughout the organization had not proceeded as intended. No formal compliance organization per se existed, and there were few repercussions for not following the directive to adopt the MSF team and process model.
MSF describes in great detail how to run a project but does not say how to run the part of the organization that needs to coordinate across many MSF projects. Dell IT has, of course, a current way of running the projects and extensive documentation to support its management. This documentation constitutes an "organizational manual" that is being refined to take advantage of the impetus provided by MSF for improved performance of individual projects. To support coordination across projects, the following four management processes have been identified as useful:
- Standards;
- Training;
- Quality control; and
- Consulting.
The standards process addresses the continual refinement of MSF to suit Dell's particular situation and the development of new standards to address coordination across projects. For instance, one standard might say that whenever three or more defects have been identified in a delivered product, the project team that developed the product is penalized.
Training assesses the competencies of employees and provides training to address competency gaps.
Quality control monitors the performance of projects to determine compliance with the standards. Projects identified as noncompliant are referred to consulting.
Consulting helps projects achieve compliance. Each of these four processes is associated with a team that implements the process, and the four teams work closely with one another in a loop, starting from what is defined by the standards team, to what is taught by the training team, to what is monitored by the quality control team, to what is remedied by the consulting team.
Other Case Studies
Damgaard (www.damgaard.com) develops, sells, and services enterprise-resource planning software. Damgaard has adopted MSF as a way of managing its project teams. In the switch to MSF a few years ago, about 500 staff members were moved from the previous setup of departments defined by function into teams aligned by product. The entire development division was reorganized into MSF teams with roles and responsibilities across all disciplines represented within each team, including developers, testers, sales, and service. An important part of the project was physically putting each team into shared office space. Damgaard implemented quality control and consulting teams to look into errors and to act upon them. Statistics from this quality control and consulting activity are an integral part of Damgaard's release procedure.
RWD (www.rwd.com) assists clients with the implementation and operation of high-technology systems and employs about 1,100 people. At times this means that RWD is involved in major software development efforts for clients. RWD prides itself on its proprietary method for managing its software teams. This method includes the following components:
- Performance-based analysis of the business problem to understand the client's perspective;
- Project management to align client requirements with the resulting work product;
- An iterative software development process; and
- A process to develop and deliver training and documentation.
RWD standards contain themes not unlike those in the MSF. RWD strives to manage all of its internal software development projects in the same manner and, to this end, has a detailed organizational manual that all projects follow.
The Boeing Company (www.boeing.com) manufactures aerospace products and services and employs about 200,000 people; Boeing's software engineering projects employ thousands. However, Boeing does not use one software development method across all projects. A significant portion of Boeing's business is for various agencies of the U.S. government, such as the National Aeronautics and Space Administration and the Department of Defense. While these agencies strive to follow international standards, they continue to have many agency-specific standards for specialized systems development. Thus different software development projects within Boeing are often required to use different product-specific development standards. However, Boeing's IT division does closely follow a high-level quality standard and structured methodology emphasizing teamwork, performing to target, and training employees.
Standards Tradition
MSF is not a de jure standard. Standards arise either from official standards activity (de jure standards) or arise by the force of practice (de facto standards). For instance, the Open Systems Interconnection standard of the International Organization for Standardization (ISO) was a de jure standard, while DOS was a de facto standard.
Numerous de jure standards exist for software development. For the U.S. government, the National Bureau of Standards in 1976 wrote Guidelines for Documentation of Computer Programs and Automated Systems, and organized a software life cycle around 10 documents. About the same time, the U.S. Navy commissioned MIL-STD-1679, Weapon System Software Development. The Institute of Electrical and Electronic Engineers (IEEE) created a standard for software quality assurance plans in 1979.
The issue is not that one standard is better or worse than another, but rather, that the company choose a particular standard and consistently work to it.
While the 1970s and 1980s were a period of differentiation in software engineering standards, the 1990s were a period of consolidation. The U.S. government, including the Department of Defense, decided to minimize the development of its own standards and to rely on standards of others.
The ISO is active in the development of software engineering standards. ISO 12207 describes the major component processes of a complete software life cycle, their interfaces with one another, and the high-level relations governing their interactions. Since the Department of Defense has endorsed the concept that contractors should develop their own organizational processes conforming to generally accepted standards, ISO 12207 has become one of these standards to which suppliers of military software claim conformance.
Numerous other organizations develop standards relevant to software engineering or help organizations deal with existing standards. The British Central Computer and Telecommunications Agency (CCTA; www.ccta.gov.uk) develops guidelines for the information technology industry. CCTA develops consensus with government organizations such as the British National Audit Office and the British Central Information Technology Unit, and a wide network of public- and private-sector organizations. CCTA developed a standard for the management of software development projects, called Projects in Controlled Environments (PRINCE). The three product types specified by PRINCE with an example of each are:
- Management, such as a project initiation document;
- Technical, such as a design document; and
- Quality, such as an invitation to a quality review.
A PRINCE project employs a project board composed of an executive, a senior user, and a senior technical role. A project manager reports to the project board and directs various development teams. A project assurance team reports both to the project manager and the project board.
When a private company that develops software for its internal use looks for a software project management standard, its main concern is not whether the standard is de jure or de facto. Instead, the concern is with the appropriateness of the standard to the corporate needs and the extent to which a complete solution is available. MSF has a niche in the marketplace since it covers both broad and specific topics, and Microsoft offers a range of services, such as certification of MSF trainers, that help a company achieve success with the standard.
Other Issues
A wide range of standards about managing software projects is available. These standards focus on the software life cycle and on quality assurance for software projects. In private enterprise the emphasis is clearly on working closely with the customer. The enforcing of consistent standards across many projects is, however, perhaps the least well-understood problem in software management. How to manage many simultaneous projects depends on many issues, of which the proper choice of tools and further levels of management are prominent.
Simultaneously coordinating many complex software projects is not practical without the aid of workflow management software. Dell uses NetMosphere (www.netmosphere.com) to help track the progress of its projects; RWD uses TeamShare (www.teamshare. com) for a similar purpose. However, within each company the use of these tools is not uniform and many challenges remain to the harmonization of the workflow of people and the connection to software that will support and track this workflow.
CCTA has advanced broad strategies for corporate-wide management of software projects and emphasizes setting direction, implementing plans, and managing assets. More specifics are needed. To the extent that a software development methodology embraces various principles of operation, one might hope the management across projects would be consistent with the management within projects. For example, with MSF one might imagine generalizations of the six roles so they would account for senior management roles. Continuing this example, a company might want at the upper levels of management a product manager and a program manager. This might correspond to a marketing vice president and a chief operations officer, respectively.
For a software engineering division of a company, the most important standards are those used for the roles and processes of its software engineering teams. Some standards are developed internally by a company for its sole use, some standards are products developed and marketed by for-profit companies to other companies; other standards are the result of government funding and formal standards development organizations. The issue is not that one standard is better or worse than another, but rather, that the company choose a particular standard and consistently work to it.
While many standards exist for the operation inside any particular software project, little is standardized for the tools or management structures employed to coordinate across projects. Workflow management systems are necessary within and across projects. Command and control structures must be clear. The challenge is to connect the project team management with the rest of the corporation.
©2000 ACM 0002-0782/00/1200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.
No entries found