NEWS AT SEI
This library item is related to the following area(s) of work:
Process ImprovementThis article was originally published in News at SEI on: September 1, 1999
Many companies today are involved in various forms of partnerships, alliances, and collaborations. "Technology collaborations" are formed specifically to improve the software development organization, in whatever capacity, whether it involves technical methods, processes, or practices. In all cases, these collaborations are difficult to manage, control, and track to productive closure. To help guide the collaboration process, it is necessary to first develop your organization's software strategy. In this, the second of two columns on the subject, I will explore in detail the eight key factors that I consider essential to developing an effective software strategy as the basis for managing and guiding the technology collaboration activity.
Companies and their markets have many variant business drivers and operating conditions, and a "universal strategy" cannot be expected to address software engineering issues across all conditions. But which attributes, or key factors, are vital to managing the technology collaboration process? How can we better understand which factors are the vital core to building an effective software strategy? By using the following eight key factors as a baseline analysis, organizations can formulate an effective strategy in support of complex technology collaborations.
Organizations must define and understand their primary software technical issues. This assumes that software is an essential component of your ability to produce and deliver value to your customers. Generally, this requires your team to analyze all key factors that impact your technical capacity or abilities to develop software. Here are some questions to consider in capturing this in your strategy:
Your organization must understand the key factors that drive your business. Software is not developed in a vacuum; it is a major element of competitive advantage. The best performing firms have already closely aligned their software development capability to the core business of the firm. For instance, embedded software that is developed based on accurate market research can result in feature-rich products that customers value. Manufacturing systems don't just coordinate plant-floor mechanical production, but now also gather key data into management reports and analyze that data in ways that facilitate rapid decision making and course corrections.
Clearly, a software strategy that is disconnected from the core business drivers will fail. In the final analysis, the software strategy must consider the primary business drivers of the industry, and perhaps the customer markets. Often these drivers will have the greatest impact on your success, and perhaps on your customers' success. For instance, firms that rely on critical manufacturing cycles (e.g., automotive and office-equipment firms) may be driven by product schedule, and cycle time may be the business driver for the embedded software. Thus, a strategy of software process discipline becomes vital to developing schedule-release integrity. Another example is firms that rely on critical safety or reliability (e.g., firms in the airline or currency-trading industries) in which large-scale, mission-critical systems are subject to extreme quality and safety compliance as the business driver. In such cases, a strategy of architecture product configurations may improve technical control over software upgrades, technology insertion, and system performance enhancements.
In the SEI's Strategy Workshop, we ask executives and managers to make a list of their primary business drivers. These might include factors such as manufacturing schedule, user quality requirements, government safety regulations, cost, or feature expansion. One commonly occurring problem is that management teams have different interpretations of SEI Interactive, September 1999 http://interactive.sei.cmu.edu page 3 business drivers, but also have divergent expectations for how software should contribute to their business goals. (For more information on the SEI's Strategy Workshops, please contact me at mvm@sei.cmu.edu or 412-268-3628.) Some questions to consider are:
Nothing is as ineffective as launching an improvement program that already failed in the past. Too often, organizations do not evaluate their improvement history as part of their efforts to create successful change programs. Before you launch any form of software improvement effort, know your organization's history of improvement. Search for advice from a variety of professionals in your company, and learn what has been tried in the past, what worked, and what failed. Your software strategy should demonstrate an understanding of the firm's history of improvement, the culture of improvement decision making, and how resources are allocated in your organization for software improvements. Understand how software improvements have been historically managed, and define the resulting impacts upon your software operations and business. Who defines new software technology programs or improvements, the technical organization or management? How well have change efforts been accepted across your organization, and then implemented? Do you track performance and outcomes of your improvement programs? It helps to consider how your firm attends to related activities. These may include using incentives for change, managing data or information to support the need for change, developing executive buy-in before proceeding, and negotiating resource decisions to support new improvements. Some questions to consider in capturing this in your strategy are: · What has been the most successful improvement effort for your software development organization? What has been the least successful? · Who is responsible for software, and what is the relation of the responsible party to other business units-for example the design, production, marketing units? · Have past efforts produced changes in the organization, structure, teams, process, or training? · What is the history of Total Quality Management (TQM) in the software organization? · Can you provide a brief explanation for how training supports continuous improvements or new programs for software engineering? · What is the greatest barrier to creating positive changes in the design, development, and implementation of your software improvement programs?
How does your organization define, manage, and improve software performance? This area of software strategy is among the most difficult to manage, but may produce the greatest near-term gains for your organization. Certainly a strategy cannot be achieved if there is no consensus for performance goals and outcomes. For instance, a strategy to increase sales by 50 percent is not attainable if production performance is already at 96 percent capacity. Understanding performance goals is especially important for evaluating and designing technology collaborations that are intended to impact the software engineering operation.
We have observed numerous firms that have invested in various new technologies without first achieving agreement about their software performance goals. If you presume that new technology will improve some aspect of your software capability, it is essential to define software performance in order to gauge the impact of any new technology. The matter of software performance nearly always produces some volatile exchanges among managers. The fact is, many organizations have not defined "performance" for their software organization. By contrast, manufacturing performance and marketing performance are typically defined by goals, dates, percentage deltas, volumes, and other SEI Interactive, September 1999 http://interactive.sei.cmu.edu page 5 reliable metrics which, when combined, yield some desired performance indication on a routine basis. A more difficult analysis is to define how your software performance relates to your business performance. For example, as automotive sub-assemblies (e.g., anti-lock brakes, engines, and interior electronics) become increasingly software intensive, manufacturers will want to demonstrate how increased feature-performance (derived from software) relates to business metrics such as increased unit sales, new vehicle contracts, and improved customer satisfaction. Questions to consider include:
In every company we know of, senior executives are concerned with efforts that will exceed one year in length, consume numerous company professionals, and require budgets in excess of $50,000. Your software strategy must outline the role and involvement of key senior executives. These executives are required as "sponsors" for the technology collaboration. These executive sponsors often assume long-term roles that take time and effort to ensure high-level awareness, buy-in, understanding, and approvals for the ongoing collaboration. Some software groups operate with great autonomy, making technical and business decisions without significant executive oversight. Other firms require executive involvement and support to ensure successful outcomes to SEI Interactive, September 1999 http://interactive.sei.cmu.edu page 6 changes in the software organization. In either case, your software strategy must define executive-level sponsorship for the collaboration. Some questions to consider are:
How is management structured in relation to your firm's software development operations? In nearly all cases, successful collaborations are the result of widespread support across management teams. For example, the software strategy for the cell phone division of a telecommunications firm references managers from the marketing, product development, manufacturing, and packaging groups. As software becomes increasingly critical to the core business of the firm, it is important to involve key members of the management team in developing and endorsing the software strategy. This is especially useful when new collaboration opportunities emerge, as the collaboration may depend upon proactive support-and perhaps resources-from those managers who stand to benefit from improved software performance and features. Consider whether your software teams are centralized or distributed across your operations. Does your firm have a CIO who directs software strategy, or do you have several distinct areas that own their own software functions? In many cases, we have seen the value of mapping out how management controls the software assets of the firm. This helps the organization develop a strategy that includes key managers, and aids in the analysis of critical areas for change or improvement. Some questions to consider in capturing this in your strategy are:
What are your firm's software engineering capabilities, technical processes and methods, and overall engineering conditions, resources, platforms, and operations? The selection and design of effective technology collaborations requires a comprehensive analysis and understanding of your software engineering capabilities. We are often surprised by the lack of internal evaluation by corporate software groups of their engineering resources and capabilities. Internal evaluations are necessary to formulate defensible strategies and plans for technology improvements. Clearly, your capacity to engage new software technologies is a function of how well you understand your existing capabilities and competencies. This is precisely the purpose of the software strategy: to lay down a solid foundation of principles and actions, and to balance those attributes that are essential to advancing our ability to achieve the core goals of building great software. In evaluating your software engineering capabilities, also consider factors such as technical training, resource allocation, and measurement. These also may have an impact on your software engineering capabilities. Some questions to consider in capturing this in your strategy are:
In forming your software strategy, it is essential to capture the role of the customer in relation to the software development organization. We find that firms often focus resources upon the software technology, processes, and sciences of development- without taking into consideration end users or customers. This is the failure of cultures that are highly technology intensive, and often leads to product or system functionality that fails to deliver the core values that customers require. Consider financial services firms, whose business is intangibles such as brokerage and banking services. We have coached customer-service teams to gather customer and user information about their monthly statements, and to use this market feedback in software strategy development. In other cases, we have worked with companies that have involved customers in product teams and co-development projects, to ensure that software development meets customers' growing or changing needs. This requires organizations to alter their internal software operations to accommodate greater involvement by customers. In short, great software often results where strategy is closely aligned to customers and end users. Some questions to consider in capturing this in your strategy are:
Technology collaborations are essential to sustaining competitive advantages in software engineering development, but technology transition and collaboration planning require the support of good strategy formulation and planning. While every company's software strategy should address those factors unique to its own business, software, and technical requirements, the above eight factors have repeatedly proven absolutely essential to software strategies that drive successful technology collaborations.
Mike Mattison is a senior member of the technical staff at the Software Engineering Institute. Mike is currently managing a portfolio of technology collaborations with Fortune 500 client partners. The goal of his work is to accelerate the technical development and commercial transition of new software capabilities and methods into applied practice. He has directed a technology partnering strategy for SEI that has produced successful software collaborations with Fortune 300 corporations in the aerospace, automotive, banking, telecommunications, defense, and software industries. Mike is presently researching critical software performance in extreme high-reliability domains. His area of interest is the impact of software management performance on sustainable competitive advantage in commercial industries.
For more information