Topic: Improving System Development ProductivityInstructions:Need minimum 300 wordsNeed 3 APA ReferencesChapter
20
Emerging Development
Practices1
P
oor development productivity has been a perennial problem for IT (Brooks 1975;
McKeen and Smith 2003; Oman and Ayers 1988). “IT takes too long to deliver” is
a common complaint among today’s business leaders (Luftman and Zadeh 2011;
Overby 2005). Over the past three decades (or more), a considerable number of panaceas
have been proposed for helping organizations to get the systems and IT functionality
they need better, faster, and cheaper. Structured approaches to
programming and
design and the introduction of systems development life cycle methodologies were first.
Then came automated systems development tools, attempts to measure productivity
(e.g., function points), and new development approaches such as rapid application
development (RAD). More recently, organizations have sought to buy off-the-shelf
software, use middleware to integrate it, introduce enterprise resource planning s ystems
(ERPs), or adopt software-as-a-service in order to deliver more functionality at a lower
cost. Companies have also realized that the processes around systems development,
such as system p
rioritization and enterprise architecture, can have a significant impact
on development timelines and most now have procedures in place to manage these
activities. Finally, many organizations have turned to contract or outsourced staff (often
in other countries) to help them with extra resources during high-demand periods or to
provide a large group of qualified development personnel at a lower overall cost (Han
and Mithas 2014; Lacity and Willcocks 2001).
Nevertheless, over the past decade the situation has gotten worse in many ways.
Changes in technology, connectivity and collaboration, and the introduction of open
standards has meant that the IT function is sitting at the intersection of two powerful and rapidly changing forces—technological innovation and globalization—and IT
has become absolutely critical to effective business strategy. Furthermore, development
teams are becoming increasingly complex to manage, incorporating people and partners
from different companies and locations. And development activities are more challenging, involving many regulatory, architectural, business, financial, HR, security, and risk
1
This chapter is based on the authors’ previously published article, Smith, H.A., J.D. McKeen and W.A. Cram,
“Enhancing Development Productivity,” Journal of Information Technology Management, XXXIII, no. 3, September
2012. Reproduced by permission of the Association of Management.
319
M20_MCKE0260_03_GE_C20.indd 319
12/3/14 8:55 PM
320
Section IV • IT Portfolio Development and Management
management hoops that have little to do with the traditional design and c oding of the
past but that need to be orchestrated to deliver a coherent, viable service. Unfortunately,
new systems development techniques have not always kept pace with these changes.
Many that have promised, such as service-oriented architecture (SOA), software-as-aservice, and agile development, still have not displaced traditional approaches. At the
same time, the new technical and managerial practices needed to support them have
not been fully introduced. In short, improved development productivity is still long on
promises and short on delivery.
This chapter explores improving development productivity from a number of perspectives. It begins by examining the problem of IT development productivity and how
system development practices are changing. It then explores the key obstacles involved
in improving development productivity and outlines practices that are proven to work.
It concludes with recommendations for managers about how to create an improved
environment for systems development productivity.
The Problem with System Development
In the past, the focus group explained that “system development” largely meant creating
customized software applications for an individual organization. Today, it still means
custom building but development also includes selecting, implementing and integrating packaged software solutions, and increasingly, integrating smaller, reusable software components with existing legacy applications across a variety of platforms with
a variety of development tools. However, although systems development has changed
over time, many of the problems associated with it have not changed; that is, there are
still very high failure rates with development projects and they are still perceived to
take too long, cost too much, and deliver limited business value (Korzaan 2009).
Research has not been particularly helpful in providing ways to improve on any of
these fronts. There have been few studies of actual development practices to d
etermine
what works and under what circumstances and there is thus very little on which to
base guidelines for different types and sizes of development (Dyba and Dingsoyr 2009).
In short, “we need to know more about what we know and don’t know about software development” (Adams 2009). One study noted that improvement in software
development models and best practices has been a “long slog” since the 1980s and using
the traditional “waterfall” model of systems development2 has “continued to fail in
delivering acceptable measures of software development performance” (Royce 2009).
The Standish Group’s ongoing study of software development success rates shows that
in 2009 only 32 percent were considered successful (that is, on time, on budget and with
the required features and functions), while 24 percent were considered failures (i.e., they
were cancelled or never used). The remaining 44 percent either finished late, were overbudget, or had fewer than required features or functions (Levinson 2009). While these
measures have improved somewhat since 1994, progress has been agonizingly slow.
Although IT practitioners and consultants have worked hard to define a strict set
of rules to guide and govern software development, and have seen some modest gains
2
By this we mean a system development life cycle (SDLC) approach in which all requirements are first
defined, and then an application is designed, developed, tested, and implemented with few changes.
M20_MCKE0260_03_GE_C20.indd 320
12/3/14 8:55 PM
Chapter 20 • Emerging Development Practices
321
from such factors as improved governance, project management offices, and better
methodologies, many believe that “rules don’t work and haven’t since 1967” (Berinato
2001). These ongoing problems have meant that system development has long “ suffered
from way too many management fads and silver bullets du jour . . . and [left managers
prey to] consultants and sellers of ‘software oil’” (Adams 2009).
Finally, system development continues to be plagued by the difficulty of measuring
“productivity.” What exactly is a successful systems development project? Many companies define it as meeting schedules and budgets and by the functionality delivered
(Levinson 2008). Yet, these common metrics typically “do more harm than good”
(Cardin et al. 2008). While they are easy for business people to understand, they perpetuate
a “myth” that these are the only three factors that make a project successful. Furthermore,
they take no account of some major elements that are often responsible for project failure,
such as changes in requirements or scope, unreasonable deadlines, project dependencies,
and lack of business accountability (Levinson 2008). “We still have no formal productivity metrics,” said one IT manager, “and it’s not a priority for us.” Nevertheless, said
another, summarizing the challenge faced by everyone in the focus group, “we are still
expected to deliver business value with increasing speed and efficiency.”
Trends in System Development
For many years, system development has been conceptually seen as a functional,
engineering project, similar in nature to building a bridge (Chatterjee et al. 2009).
Unfortunately, efforts to develop methodologies that embody software engineering
principles designed to lead to consistent performance outcomes, while resulting in some
improvements, have not been as successful as predicted (Chatterjee et al. 2009; Royce
2009). Therefore, in the past two decades, numerous efforts have been made to address
system development productivity shortcomings in other ways, including the following:
1. Adopting new development approaches. There are a significant number of new
development approaches that their proponents believe address some or all of the
problems with the traditional waterfall development method. While a comprehensive assessment of these approaches is beyond the scope of this chapter, they can be
classified into three major types:
• Agile. Introduced in the 1990s, this approach encompasses a variety of
“anti-waterfall” methods of system development, such as spiral, incremental,
evolutionary, iterative, and RAD. They stress the need to incorporate f lexibility
into system development by breaking up a large project into smaller pieces
that can be developed in overlapping, concurrent phases to rapidly deliver
business value in a series of short increments. Speed and agility are achieved
by collapsing or compressing one or more phases of the waterfall method and
by incorporating staged delivery or incremental implementation (Jain and
Chandrasekaran 2009).
• Composition. This approach models and develops generic components
comprising data, processes, and services that can be reused in different
development efforts (Plummer and Hill 2009). Based on detailed analysis and
architecture, components (e.g., acquire customer name and address) can be
plugged into any system without being reprogrammed. Initially called “object
M20_MCKE0260_03_GE_C20.indd 321
12/3/14 8:55 PM
322
Section IV • IT Portfolio Development and Management
oriented programming” in the 1990s (McKeen and Smith 1996), and “service
oriented architecture” (SOA) more recently, composition has been difficult to
achieve because of the intensive modeling and architecting required and the
IT organizational changes require to adapt to them (Blechar and Norton 2009;
Plummer and Hill 2009). With this approach, system development becomes process orchestration, combining various software components into an “ application
container” (Blechar 2010).
• Integration. The 1990s also saw the widespread introduction of packaged software to the marketplace that could be purchased and implemented rather than
developed in-house. As a result, many companies, including most of those in
the focus group, adopted a “buy don’t build wherever p
ossible” philosophy for
their generic applications, such as accounting, human resources, or customer
relationship management. More recently, this m
arketplace has begun to evolve
so that companies can purchase software-as-a-service from the cloud, rather than
implementing it within their own organizations. Although preprogrammed,
such services or packages still require various amounts of effort to select and
then integrate them into an organization’s existing processes, platforms, and
data (Mahoney and Kitzis 2009; Plummer and Hill 2009).
However, for most companies, adopting new development approaches still involves
using them only selectively and change has been agonizingly slow as a result.
2. Enhancing the waterfall methodology. Although new development approaches
are gaining ground in organizations, the waterfall remains the predominant
system development process for large-scale, industrial strength projects (Royce
2009; Schindler 2008). The waterfall method is still considered most p
ractical for
large system development projects because the engineering principles implicit in it
involve formal coordination strategies, centralized decision m
aking, formal communication, and prescribed controls, which help to offset the challenges caused
by the increased complexity and interdependencies and reduced communications
opportunities on large projects (Xu 2009). The focus group’s presentations concurred with this assessment. “While we are trying to introduce new and more
flexible approaches to development, our senior management is not committed
to them and are resisting them,” said one manager. “We’re doing lots of experimentation with different development approaches but these are done within our
standard methodology,” said another. Improving the waterfall development process is therefore still a high priority for most companies. In recent years, organizations have attempted to improve the “maturity” of their traditional software
development processes using Capability Maturity Model Integration (CMMI) to
move them from ad hoc activities to more managed, b
etter defined, quantifiable
processes, so they yield standardized, replicable results (Chatterjee et al. 2009;
Hanford 2008). For example, one focus group company has created an enhanced
delivery framework complete with a process map, detailed activities, templates,
inputs, outputs, entry and exit criteria, a rtifacts, roles, and links to standards.
Another manager stated, “We have well-defined SDLC methodologies and standards and procedures are enforced . . . [But] we are always looking for applications
development best practices to improve them.”
M20_MCKE0260_03_GE_C20.indd 322
12/3/14 8:55 PM
Chapter 20 • Emerging Development Practices
323
3. Improved governance. It has also been accepted that there are a number of
factors other than the development process itself that will affect the quality and
the effectiveness of systems development. Today, in spite of a persistent engineering mind-set that permeates system development practices, there is also
growing acceptance that building systems can be more of an art than a science.
“Systems are a unique and complex web of intellectual property bounded only
by vision and human creativity . . . They are more similar to movie production [than bridge-building] where no laws of physics or materials apply . . . most
quality is subjective [and] anything can change” (Royce 2009). To deal with these
conditions, some organizations are beginning to adopt governance mechanisms
based on economic disciplines that accept the uncertainties involved in systems
development—especially at the beginning—and adapt and steer projects through
the risks, variances, and moving targets involved (Royce 2009). Thus, many focus
group companies have adopted different governance practices for different stages
of the development life cycle, such as staged estimates of cost and time, “gating
reviews,” and quality assessments at different life cycle phases. Other governance
mechanisms, such as those used in Sweden, also consider the social and cultural
implications involved (Chatterjee et al. 2009). Still others govern by a set of software
outcomes, including flexibility, responsiveness, operational efficiency, quality of
interaction, learning, product performance, and benefits achieved (Liu et al. 2009;
Smith et al. 2010). In the focus group, most managers stressed that compliance with
all legislation and regulations has become a further significant governance issue
for all their systems initiatives. Some also stressed the need for better governance
of the processes that “touch” and impact systems development activities, such
as quality assurance, architecture, security, and testing. In short, governance at a
variety of levels is becoming more important to ensure productivity in systems
development (Plummer and Hill 2009).
4. Changing resourcing strategies. One trend in systems development that is very
clear is the widespread use of contractors and outsourced developers to supplement
in-house development staff. A major driver behind improved governance, methodologies, standards, and componentization of software is the desire to use cheaper
development labor, often located in other countries. This globally dispersed development, however, increases the need for new internal business and technical skills.
New resourcing strategies increase the need for better business, technical and data
architecture, improved business analysis, IT strategy that is more closely linked to
business, and project managers who can coordinate and leverage the efforts of a
diverse group of internal and external, IT and business staff to deliver consistent
and effective IT products (Blechar 2010; Plummer and Hill 2009). At present, only
28 percent of CIOs believe that they have the right skills in their IT organizations to
support these changes (Mahoney and Kitzis 2009). The group agreed that development skills are changing. “Our focus is on improving project management, business
analysis and quality assurance staff,” said one manager. “We’re stressing the development of relationship management, analysis and consulting skills,” said another.
“Improved resource allocation is also essential,” said a third, “because there are only
so many staff with the necessary skills. In the past, each business unit had dedicated
resources; now they all work for the enterprise.”
M20_MCKE0260_03_GE_C20.indd 323
12/3/14 8:55 PM
324
Section IV • IT Portfolio Development and Management
Obstacles to Improving System Development Productivity
It is clear from the earlier mentioned trends that systems development is changing and
has changed to address complaints of poor productivity. However, it is also clear that
these changes are still not adequately addressing the problem. There are several reasons
why improvements in development productivity have been difficult to achieve. While
many of them may not be surprising to long-time IT managers, they bear repeating
since they pose significant barriers to success in this area.
First, there is still a need for a more holistic understanding of system development, both within IT and within the business. As already noted, development is a much
more complex and uncertain process than was first understood. Too often, our mental
models of development appear to be dated—locked into a time in the past when the
problem being addressed was straightforward and the programming effort significant.
Today, the programming is straightforward, while the problems are highly complex,
typically involving many parts of the business and many IT functions and requiring
significant business knowledge, technical skill, relationship and communications abilities, and conceptual understanding (Chakraborty et al. 2010). In an earlier look at this
subject we noted that all activities impacting system development should be considered
when trying to improve productivity. “There is a need to ensure that everything works
together to further the overall goal. It makes no sense to improve one part of the process
if it doesn’t accomplish this” (McKeen and Smith 1996). Members of the focus group
identified three primary areas where there are currently significant bottlenecks in the
development process:
•
•
•
Business involvement. This can be an obstacle to development success at several
levels. At the highest level, it is well-known that business sponsorship is essential to
ensure that the right projects are developed (Hanford 2008). While many organizations have addressed this problem through their governance processes, the focus
group stressed that many business leaders still pay only lip service to their responsibilities. This impacts the system development process in several ways. “Our
business users take forever to complete their parts, such as agreeing to a proposed
solution or signing off on key phases of a project,” said a manager. “They don’t
see how this affects our work, which can’t proceed without it.” The focus group
felt strongly that b…
Purchase answer to see full
attachment