NEWS AT SEI

Most 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. After more than 15 years of working with

executive management teams, I've identified a pattern of factors that are

essential to managing and guiding the technology collaboration, and particularly

the formation of software strategy to improve the software engineering

enterprise.

In this column, the first of two columns on this subject, I will consider why

technology collaborations are essential to sustaining competitive advantages in

software engineering development, and why technology transition and

collaboration planning require the support of good strategy formulation and

planning. In my column in the next issue of SEI Interactive, I will explore in detail

the eight key factors that I consider essential to managing and guiding the

technology collaboration activity.

Software drives value

Who would dispute the astonishing value of software to the competitive strategy of the

firm? Whether your firm produces aircraft, phones, Web-based systems, satellites, or

semiconductors, software is what drives a major portion of your "value proposition" in

the market. Software impacts all corners of the business operation, from manufacturing

and design to distribution and customer service. Software is what makes you unique.

Software has the power to differentiate you in the market, to create a powerful and

compelling identity among alternative products or services. The performance of software

creates superior functions, drives feature performance, and achieves value. In many

cases, software creates the product and interface value that your customers want, need,

and will return to in the future. Whether your customers are looking for software that is

fast, accurate, reliable, safe, or effective, your software capability has everything to do

with delivering the lasting value proposition to your customers.

Software is so important that every company should have an evolving and continuous

software strategy, a "master plan" that replaces management's old Ouija board and

voodoo dolls for making decisions about software engineering. Yet, in my 15-plus years

of experience working with corporate management teams, I have found that most

organizations do not have a software strategy. In fact, few software groups have created a

SEI Interactive, 06/99 page 2

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

basic plan of action that outlines vital issues, such as team roles and responsibilities,

training activities, improvement planning, management issues, or key performance goals.

Without a software strategy that encompasses the key functional areas of software

performance, we cannot conduct meaningful evaluations or decision analyses regarding

software technology collaborations. The software strategies are the "blueprints" that

guide our technology collaborations, and keep our decisions on track to achieve business

value from our software performance.

I'd like to offer an approach that focuses on strategy development as a basis for

improving how we collaborate to achieve software innovations. The value of software

innovation is not bankable until that innovation succeeds in application. To be of value, it

has to work in the real world, not just in the lab. Also, such innovation must be enhanced

and accelerated, typically by technology collaborations with partner organizations with

credible expertise and the supporting resources that are necessary for investigating and

evaluating new software engineering technologies. Further, successful technology

collaborations for software do not happen by luck and fortune alone; those successes are

the result of careful development of software strategy and planning. Lastly, I am

presenting eight key factors that are essential to developing an effective strategy in

support of software technology collaborations.

The importance of technology collaborations

My primary goal at the SEI is to identify and develop corporate partners for technology

collaborations that advance the formation, introduction, and adoption of new technologies

for software engineering. This requires careful team development of our internal

technologists from various SEI functions, in concert with the executives, managers, and

software practitioners of candidate partner companies. Each collaboration must have

consensus and alignment of management, business impact, financial resources, staff

capacity, and an appropriate technical domain. The transition of new technologies into

technical practice is not a trivial matter, and requires the acceptance and support of

numerous vital players from each collaboration partner. Companies do not conduct

technical collaborations, or joint ventures, without careful analysis of the key issues,

including

· review of the business plan, financials, schedule, operational impact, and resources

· technical domain, project selection, staff credentials, and project control/tracking

· acceptance and sponsorship by management, and sustained executive endorsement

SEI Interactive, 06/99 page 3

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

· expected business value and impact upon final system performance for the user or

customer

· legal/contractual issues, performance criteria, intellectual property, and liability

· new technology insertion and organizational, cultural, and change management

dynamics

Clearly, forming collaborations between organizations is a substantial business venture

that merits qualified business and technology management and planning. These

collaborations-with potentially enormous payoffs-do not happen based on a few phone

calls and some technical exchange meetings. The value of each collaboration is based on

key stages: analyzing critical success factors, developing the software strategy, and

forming the detailed plans for each collaboration.

I have often invested 6 to 10 months working with our internal technical teams and our

client organizations to formulate tailored work agreements by which to conduct each

technology collaboration. Getting agreement on introducing new technology into

software operations is a long, detailed, conflicting, and arduous task. Companies don't

like to do anything to their software unless and until everyone in each department

understands what will be done, to whom, and why. Otherwise, it simply makes a lot of

people very nervous, and failure is inevitable. Like good civil engineering, successful

construction execution is always a function of the quality and detail of the planning. In

short, great blueprints are necessary to produce great architecture. That's the role of

technology collaborations.

From lab to market

Great technology alone rarely makes the leap from lab to market unless strong business

and operational management and planning guides the process. Innovation may happen by

itself in a contained lab, but the value of that innovation is zero until the transition to

practice is made complete by successful application. Good ideas need commercial

partners to help demonstrate the level of value and viability, and to further enhance,

evolve, and increase the target efficacy of the proposed new technology. It is the

technology collaboration that creates a defined and structured process between

organizations that seek to transition new technology from concept to practice. In every

instance where a technical practice or process has been improved with a collaboration

partner, there has been a well-managed and directed collaboration strategy and plan to

support the difficult transition period.

SEI Interactive, 06/99 page 4

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

For the SEI's purposes of improving the practice of software engineering, the core

function of each collaboration is the transition of new technology from one collaborator

to the other. The purposes may include proof-of-concept analyses for embryonic-level

technical practices, or even basic R&D with a specific technical or industry domain.

Another purpose may be to conduct a trial run or to pilot early-stage technology with

multiple collaborators to gather data and generate a trend analysis. Yet another purpose of

technology transition may be to introduce a viable commercial technology into a new

industry to further demonstrate the technology's robustness across new product and

application domains. The vital challenge of each collaboration is to successfully guide

and manage all aspects of the business and technical relationship of both parties.

Collaborations between or among organizations to improve the software engineering

function require a strategy. Collaborating without a clearly developed software strategy is

like building a house without a set of blueprints: it is a deception of activity without

meaningful results. Strategy is the blueprint to keep you on course to ensure that each

collaboration will yield the desired results of maximum technical and business value. To

simply say you're in collaboration is insufficient for achieving technology transfer

between organizations. Many organizations have tried this approach, and many have

failed. In considering the development, introduction, and adoption of new software

technologies, we expect a long-term effort (greater than one year), the participation of

numerous subject experts, a review by senior management, and a minimum investment of

typically $50,000.1

These collaborations are, after all, intended to explore the vague uncertainties of new

emerging technical competencies that are-at this early stage-unproven and unknown,

and that lack reliable economic analysis. The prize of first entry to market, however, is

potentially enormous for technical innovations in software engineering. Clearly,

collaborations at this level and scope of effort require a well-defined strategy to protect

and guide the core goals and principles of the effort over the long run. In my experience,

the best results stem from those organizations that develop an internal software strategy,

which begins by answering the following questions:

1 In my experience, the collaboration of 2 or more organizations with intent to form, introduce, and

adopt new technologies for software engineering requires a 3-month negotiation/agreement phase and

a minimum 6- to 12-month implementation phase, often followed by a 1-month post-mortem phase.

Level of effort requires participation by key executives, senior and middle managers, project leaders,

contract staff, legal, accounting, and software engineering subject experts and technical staff. Case

evidence varies widely, and we do not publish proprietary contract information, but collaborations of

this scope and level of effort routinely require, at a minimum, a $50,000 budget allocation to ensure

reasonable implementation and success of initial goals.

SEI Interactive, 06/99 page 5

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

· Why are you conducting this collaboration?

· What aspect of your software do you expect to impact or improve?

· What resources and sponsorship have been negotiated to support this effort?

· What is the expected "business value" to be realized from this investment in new

technology?

· What is the expected impact of not conducting this collaboration?

Creating a software strategy is a challenge for software organizations. In working with

numerous corporate firms, I have rarely found such items as business plans, improvement

programs, training routines, and technical effort analyses combined into a software

strategy. Yet, it is a very useful and productive endeavor for any software organization,

and it is a requirement for guiding and sustaining a technical collaboration. Strategy

formulation is also the task of the software group, not consultants or corporate

management. Those who own the implementation role should develop strategy.

Strategy provides the guiding principles necessary to calculate your core business and

critical resources for achieving business goals among competitors in complex markets.

Strategy is vital to performing your operations in a sustained environment of change and

uncertainty; to ensuring continuous improvement while operating at peak production; to

balancing those attributes that are essential to your ability to achieve your core business

goals. Strategy may include many considerations, including finance, technology,

management roles, design, manufacturing, customers, distribution, pricing-those

attributes that impact your ability to achieve your core business goals. Above all, strategy

requires all interested parties to come to the negotiating table and achieve consensus and

alignment.

We may never agree on which considerations are exactly necessary to develop a software

strategy. The fact is that 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? While every

company's software strategy should address those factors unique to its own business,

software, and technical requirements, I've identified a pattern of factors that have

repeatedly proven absolutely essential to software strategies that drive successful

technology collaborations. These factors, and their goals, are listed below.

SEI Interactive, 06/99 page 6

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

Factor Goal

Technical issues Define and understand the primary

software technical issues of your

organization.

Primary business drivers Understand the key factors that drive your

business and industry.

Improvement history Understand which improvement programs

have succeeded in the past, which have

failed, and why.

Performance goals Understand how your organization defines

and manages performance goals for

software engineering.

Executive owner Understand the role of senior executive

management in new software technology

collaborations.

Management team Understand how management is structured

in relation to your firm's software

development operations.

Software engineering Understand your firm's software

engineering capabilities, technical

processes and methods, and overall

engineering conditions, resources,

platforms, and operations.

Customers Understand how the software organization

delivers value to the customer.

By using these key factors as a baseline analysis, organizations can formulate effective

strategy in support of complex technology collaborations. In the next issue of SEI

Interactive, I will examine each of these key factors in detail.

SEI Interactive, 06/99 page 7

http://interactive.sei.cmu.edu/Columns/Business/1999/June/Business.jun99.htm

About the author

Mike Mattison is a senior member of the Technical Staff at the Software Engineering

Institute (SEI). 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 the SEI that has

produced successful software collaborations with Fortune 500 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. You can reach Mike at

mvm@sei.cmu.edu.

The views expressed in this article are the author's only and do not represent directly or

imply any official position or view of the Software Engineering Institute or Carnegie

Mellon University. This article is intended to stimulate further discussion about this topic.

The Software Engineering Institute (SEI) is a federally funded research and development center sponsored

by the U.S. Department of Defense and operated by Carnegie Mellon University.

SM IDEAL, Interim Profile, Personal Software Process, PSP, SCE, Team Software Process, and TSP

are service marks of Carnegie Mellon University.

® Capability Maturity Model, Capability Maturity Modeling, CERT Coordination Center, CERT,

and CMM are registered in the U.S. Patent and Trademark Office.