Professional Documents
Culture Documents
________________________________________________________________________
A PROJECT REPORT ON
Submitted By
ASHOK C KAMPLI
(REGD.NO:04XQCM 6039)
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 2
________________________________________________________________________
DECLARATION
I hereby declare that this project report titled “Analysis of schedule risk in software
development projects” is a record of independent work carried out by me, towards the
Institute of Management. This has not been submitted in part or full towards any other
degree.
PLACE: BANGALORE
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 3
________________________________________________________________________
Principal’s Certificate
This to certify that the project report titled “Analysis of schedule risk in software
development projects” has been prepared by Mr. Ashok C Kampli bearing the
Date: (principal)
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 4
________________________________________________________________________
Guide’s Certificate
This is to certify that the Project Report entitled “Analysis of schedule risk in software
academic year 2005-06 in a partial fulfillment of the requirement for the award of MBA
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 5
________________________________________________________________________
ACKNOWLEDGEMENT
Finally, I express my sincere gratitude to all my friends and well wishers who helped me
to do this project.
Mr.Ashok C Kampli
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 6
________________________________________________________________________
Table of Contents
Abstract ………………………………………………………………
Chapter 1: Introduction……………………………………………….. 5
1.1 Background……………………………………………………….. 5
1.2 Statement of the problem…………………………………………..9
1.3 Objectives of the study ....................................................................9
1.4 Need and significance of the study..................................................10
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 7
________________________________________________________________________
Chapter 5: Data Analysis and Interpretation
5.1 Average number of projects undertaken.........................................35
5.2 Average time spent by the respondents on a typical project ..........35
5.3 Average team size of the respondents ............................................35
5.4 Project Completion .........................................................................36
5.5 Product delivered with all the initial requirements.........................36
5.6 Proportion of features added later ..................................................37
5.7 Managing large teams.....................................................................38
5.8 Problems faced in managing teams ................................................39
5.9 Ways of overcoming team management problem..........................40
5.10 Increase in delivery time...............................................................41
5.11 Usage of time tracking tools.........................................................42
5.12 Other Measures employed to ensure on time delivery of project.43
5.13 Factors responsible for schedule risk...........................................44
Annexure
Questionnaire ......................................................................................60
Select bibliography .............................................................................63
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 8
________________________________________________________________________
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 9
________________________________________________________________________
Abstract
Software is created with programming languages and related utilities, which may come in
several forms. For a software project to be successful it is essential that the project is
completed on time and within budget, with all features and functions originally specified.
However due to various reasons these software projects fail some even get canceled before
they ever get completed. Because of this, the projects can be categorized into Successful
projects, challenged projects and Failed projects. The failure is caused mainly because of
cost overrun or time overrun or because the product was not delivered with all the
requirements as per initial specification. The cost of these failures and overruns are just the
tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily
be in the trillions of dollars. Hence it is important that detailed work be done on these to
overcome the huge costs they incur.
This research work is focused on analyzing the factors that cause software project time
overruns and to provide recommendation to overcome or mitigate the effect of some of the
identified factors on software project. The project employs systematic, formal and
descriptive research techniques. This study is based on the data collected through structured
questionnaire and in-depth, unstructured and informal interview with key personnel. The
sampling technique used is snowball sample technique. Since the research topic is highly
qualitative in nature, we are prompted to use simple percentages so as to make the data
more succinct and amenable for easy interpretation. The most important findings of the
research work were the main factors that have been identified as critical to overcome
software project time overruns. These are incomplete and changing requirements and
specifications, unrealistic time frames, too many/complicated standards, technology
incompetence and unclear objectives. The crucial recommendations provided after
collection of data through secondary sources and primary source, i.e., field investigation
dealt with
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 10
________________________________________________________________________
Introduction
1.1 Background
A project can be defined as a plan or proposal; a scheme or an undertaking requiring
concerted effort. Softwares are the programs, routines, and symbolic languages that control
the functioning of the hardware and direct its operation. They are instructions for the
computer. A series of instructions that performs a particular task is called a
"program." The two major categories of software are "system software" and "application
software." System software is made up of control programs such as the operating system
and database management system (DBMS). Application software is any program that
processes data for the user (inventory, payroll, spreadsheet, word processor, etc.). A
common misconception is that software is data. It is not. Software tells the hardware how
to process the data. Software can also be defined as written programs or procedures or rules
and associated documentation pertaining to the operation of a computer system and that are
stored in read/write memory.
Unlike a building, software can’t be seen, touched, felt or visualized and it's hard for the
layman to get a conceptual grip of its size or cost or how long it might take to build. Hence
software projects can be defined as an undertaking to develop computer programs routines,
and symbolic languages that control the functioning of the hardware and direct its
operation.
Software creation
Software is created with programming languages and related utilities, which may come in
several forms:
Single programs like script interpreters, packages containing a compiler, linker, and other
tools; and
Large suites (often called Integrated Development Environments) that include editors,
debuggers, and other tools for multiple languages.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 11
________________________________________________________________________
Software creation requires concerted effort from the software development teams. A
software project team ideally consists of a team leader, software developers and software
testers. However for a software project to be successful it is essential that the project is
completed on time and on budget, with all features and functions originally specified.
There are a couple of metrics for project success/failure. Some are binary, some are
quantitative, and some are qualitative. Many may be influenced by outside factors. Some
are not direct indicators, but probably have a strong correlation. Some of them are:
1. Actual development time vs. projected development time.
2. Actual cost vs projected cost
3. Project deployed/introduced, or cancelled?
4. Revenue, profit, or productivity gains realized, vs projected
5. Customer/user satisfaction
6. Affect on reputation of company/department/project team
7. Were project staff rewarded (promoted, given bonuses), punished (sacked, demoted,
given paycuts), or neither?
The Standish Group’s research titled CHAOS Report 1995 shows a staggering 31.1% of
projects will be canceled before they ever get completed. Further results indicate 52.7% of
projects will cost 189% of their original estimates. The average time overrun is 222% of
the original time estimate. For large companies, the average is 230%; for medium
companies, the average is 202%; and for small companies, the average is 239%.The cost of
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 12
________________________________________________________________________
these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity
costs are not measurable, but could easily be in the trillions of dollars. On the
success side, the average is only 16.2% for software projects that are completed on-time
and on-budget.
The Standish Group’s latest research entitled Extreme Chaos 2000 shows decided
improvement in IT project management. The project success rates as per this report, while
modest are up again across the board, while cost and time overruns are uniformly down.
Time overruns have significantly decreased from 222% over the original time estimates in
1994 down to 63% in this latest study. Cost overruns have gone from 189% over the
original cost estimates in 1994 down to 45% in the 2000 study. In 1994 required features
comprised 61% of the final product. This latest report shows 67% of the required features
and functions. This notable increase end-user satisfaction in terms of time cost and features.
However, Nirvana is still a long way off. Standish categorizes projects into three resolution
types:
Successful: The project is completed on time and on budget, with all features and functions
originally specified.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 13
________________________________________________________________________
Challenged: The project is completed and operational, but over budget, late, and with
fewer features and functions than initially specified.
Failed: The project is canceled before completion, or never implemented. As per the study,
only 28% of the software projects succeeded, 49% were challenged and the rest failed.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 14
________________________________________________________________________
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 15
________________________________________________________________________
essential to find out the scenario prevailing today. The significance of this study lies in the
amount of money that software companies are spending on project failures. The cost of
these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity
costs are not measurable, but could easily be in the trillions of dollars. Furthermore such
failures and overruns hamper the image of the company in today’s competitive market and
reduce the level of customer satisfaction. Hence it is essential to find out the success rate of
software projects in today’s date, establish how much cost and time overruns are happening
even today and what can be done to prevent or minimize such overruns. However due to
time and resource constraints, this study is focused mainly on analyzing the various reasons
that cause software project time overruns and to provide recommendation to overcome or
mitigate some of these reasons.
Industry Profile
2.1 Information Technology Industry in India
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 16
________________________________________________________________________
The vision of IT policy is to use IT as a tool for raising the living standards of the common
man and enriching their lives. Though, urban India has a high internet density, the
government also wants PC and Internet penetration in the rural India. In information
technology (IT), India has built up valuable brand equity in the global markets. In IT-
enabled services (ITES), India has emerged as the most preferred destination for business
process outsourcing (BPO), a key driver of growth for the software industry and the
services sector. India's most prized resource in today's knowledge economy is its readily
available technical work force. India has the second largest English-speaking scientific
professionals in the world, second only to the U.S. According the data from ministry of
communication and information technology, the ITES-BPO industry has grown by about
54 per cent with export earnings of US$ 3.6 billion during 2003-04. Output of the Indian
electronics and IT industry have grown by 18.2 per cent to Rs.1,14,650 crore in 2003-04.
The share of software services in electronics and IT sector has gone up from 38.7 per cent
in 1998-99 to 61.8 percent in 2003-04. Export markets continue to dominate the domestic
segment. The size of the domestic market in software relative to the export markets for
Indian software, which was 45.2 percent in 1998- 99, after declining rapidly to 29.8 percent
in 2001-02, fell only to 29.1 percent and 27.7 per cent in the two subsequent years. Value
of software and services export is estimated to have increased by 30 percent to US$12.5
billion in 2003-04. The annual growth rate of India's software exports has been consistently
over 50 percent since 1991. No other Indian industry has performed so well against the
global competition. According to a recent study conducted by NASSCOM, the chamber of
commerce and "voice" of the IT software and services industry in India: Indian Software
and Services Exports earned revenues of USD 17.2 billion, registering growth of 34.5 % in
FY 2004-05 Total software and services revenue were USD 22 billion in 2004-05.
Domestic market revenue grew up by 24% in FY 04-05
Indian Software and Services exports industry is forecasted to register strong growth of
around 30-32% in FY 05-06.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 17
________________________________________________________________________
With the formation of a ministry for IT, Government of India has taken a major step
towards promoting the domestic industry and achieving the full potential of the Indian IT
entrepreneurs. Constraints have been comprehensively identified and steps taken to
overcome them and also to provide incentives. In order to broaden the internet base, the
Department OF Information technology has also announced a programme to establish State
Wide Area Network (SWAN) up to the block level to provide connectivity for e-
governance. The Department has also set up Community Information Centers (CICs) in
hilly, far-flung areas of the North-East and Jammu and Kashmir to facilitate the spread of
benefit of information and communication technology. It is also proposed to set up CICs in
other hilly, far-flung areas of the country like Uttaranchal, Andaman & Nicobar and
Lakshadweep. A number of steps have been taken to meet the challenge of zero duty
regime in 2005 under the Information Technology Agreement (ITA-1). Tariffs on raw
materials, parts, other inputs and capital goods have been rationalized to make domestic
manufacturing viable and competitive.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 18
________________________________________________________________________
Review of Literature
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 19
________________________________________________________________________
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 20
________________________________________________________________________
percent of the features of any given application are actually needed. And a major reason for
software failure is feature overload—when a programmer adds a feature that interferes with
an essential process. Fixing that disconnect in turn creates another disconnect, and so it
goes. Tom DePauw, manager of IT at Cater-pillar Financial Services in Nashville, Tenn., is
using Agile Development to build Cat Finance Express, a massive Web-based system that
integrates three older software systems used for helping customers finance heavy
equipment purchases. "When the project started, Caterpillar Inc. [the parent company]
wanted to see the book," DePauw says, referring to the requirements document. "I held up
this single sheet of paper with a diagram on it and said, 'This is it".
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 21
________________________________________________________________________
Non-IT execs should coordinate with the technical project manager, test iterations to make
sure they're meeting user needs, and act as liaison between executives and IT. With
business involved full time, "It's hard for us to say after three months of iterations that we
didn't really know how it was going," says Chris Colleran, CTO of a Salt Lake City market
research outfit called SpreeRide. Colleran is using Agile Development to set up his
company's website and some back-end applications and has business executives full time
on the project. "Emotionally it's hard to commit businesspeople to the development
process, but it's only counterintuitive because of the way it has always been," he says. "If
you think about it, the perfect developer would be half a businessperson and half a
programmer."
There's great news on the project management front, according to The Standish Group,
West Yarmouth, Mass., a research firm that focuses on mission-critical project
management applications. Its most recent findings indicate researchers and project
managers alike are learning how to become more successful at IT project management.
According to results of Standish's 1994 CHAOS study, a research report published
annually since that year, only 28,000 application development projects met the criteria for
success—completed on time, on budget, and with all the features and functions originally
specified. Last year's results show that 78,000 U.S. projects were successful.
The reasons for the increase in successful projects vary. First, the average cost of a project
has been more than cut in half. Better tools have been created to monitor and control
progress, and more highly skilled project managers are using improved management
processes. The fact that there are processes is significant in itself. Most of these new
projects are well within The Standish Group'sc riteria established in "Recipe for Success,
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 22
________________________________________________________________________
1998," which limits project duration to six months and project staff to six people. This
article is based on information from the company's latest paper, "Extreme CHAOS 2001".
The Road to success
Success rates are up across the board, while cost and schedule overruns are declining. The
CHAOS research timeline is evidence of steady improvement in IT project management. In
1994, only 16% of application development projects met the criteria for success—
completed on time, on budget, and with all features/functions originally specified. In 2000,
28% of projects were in the successful column. Standish categorizes projects into three
resolution types:
Successful: The project is completed on time and on budget, with all features and functions
originally specified.
Challenged: The project is completed and operational, but over budget, late, and with
fewer features and functions than initially specified.
Failed: The project is canceled before completion, or never implemented. Tracking U.S.
project outcomes showed that in 1994, 28,000 projects were successful, while in 2000, the
number rose to 78,000— almost a threefold increase. Conversely, failed projects amounted
to 54,000 in the 1994 study vs. 65,000 in the 2000 study. This was an 18% increase, while
overall project growth exceeded 60%. Challenged projects grew at a rate of 62%, to equal
137,000 over the 1994 number of 93,000.Cost overruns in 1994 equaled 189% over the
original estimate. This was reduced from 69% in the 1998 study and down to 45% in the
2000 study. Time overruns dropped from 222% in 1994 to 63% in 2000. Another piece of
good news is that in 1994 only 61% of the required features were delivered on challenged
projects, compared with 67% in the 2000 study. Overall, the outlook is good. Project
success rates are up, and overruns are down. More importantly, although the number of
projects is expected to double in 2001, the rate of failure is expected to decline
substantially. What ensures a project's success? The original CHAOS study, conducted in
1994, identified 10 success factors. Standish has updated the CHAOS Ten for 2000.
Although no project requires all 10 factors to be successful, the more factors present in the
project strategy, the higher the confidence level. These factors are:
1 Executive support
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 23
________________________________________________________________________
Traditionally, executive support occupied the No. 2 spot; however, it is now the No. 1
factor in project failure. Executive support influences a project's process and progress.
Lack of executive input can jeopardize a project.
2. User involvements
Lack of user involvement traditionally has been the No. 1 reason for project failure.
Conversely, it has been the leading contributor to project success. Even when delivered on
time and on budget, a project can fail if it doesn't meet user needs or expectations.
However, this year user involvement has moved to the No. 2 position. Despite how that
may sound, user involvement hasn't decreased in importance; it's just that IT professionals
have, in effect, solved this major problem.
5. Minimized scope
Wrapping up the top five is minimized scope. Time is the enemy of all projects, and since
scope affects time, or project duration, they are linked. Clearly then, minimizing scope
increases a project's chances of success. Minimized scope has replaced small milestones.
While these two factors are similar, the act of minimizing scope leads to greater success
than does creating small milestones. Concentrating on the top five will result in 70 success
points.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 24
________________________________________________________________________
Requirements are in a state of constant flux, but infrastructure needs stability. The Standish
Group's research shows that 70% of application code is infrastructure. Some of this code is
unique to the application; nonetheless, much of this code could be purchased from an
infrastructure vendor. By using standard infrastructure, the application development team
can concentrate on business rules rather than on technology. Many application
development projects fail not in stand-alone application development, but in existing
application integration. Standard infrastructures can shortcut application integration.
8. Formal methodologies
This provides a realistic picture of the project and resources committed to it. And it results
in steps and procedures the team can reproduce and reuse. It also enables the team to
maximize consistency. And it incorporates lessons learned into active projects. The process
encourages a go or no-go decision checkpoint. It also helps the project team proceed with a
higher level of confidence, or halt or alter steps to fit changing requirements. CHAOS
research shows that 46% of successful projects use a formal project management
methodology, compared with 30% of challenged and failed projects. So, this factor should
increase success rates by about 16%.
9. Reliable estimates
Systematic project estimating must be approached realistically, because estimating is just
plain hard. Then add to that the difficulty of developing, purchasing, and integrating
components into existing and packaged applications, and outside services. IT managers
must use all their collective knowledge and experience to come up with estimates that
reflect the true effort required.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 25
________________________________________________________________________
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 26
________________________________________________________________________
Restarts
One of the major causes of both cost and time overruns is restarts. For every 100 projects
that start, there are 94 restarts. This does not mean that 94 of 100 will have one restart;
some projects can have several restarts. For example, the California Department of Motor
Vehicles project, a failure scenario summarized later in this article, had many restarts.
Cost Overruns
Equally telling were the results for cost overruns, time overruns, and failure of the
applications to provide expected features. For combined Type 2 and Type 3 projects,
almost a third experienced cost overruns of 150 to 200%. The average across all companies
is 189% of the original cost estimate. The average cost overrun is 178% for large
companies, 182% for medium companies, and 214% for small companies. Cost Overruns
% of Responses
Under 20% 15.5%
21 - 50% 31.5%
51 - 100% 29.6%
101 - 200% 10.2%
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 27
________________________________________________________________________
201 - 400% 8.8%
Over 400% 4.4%
Time Overruns
For the same combined challenged and impaired projects, over one-third also experienced
time overruns of 200 to 300%. The average overrun is 222% of the original time estimate.
For large companies, the average is 230%; for medium companies, the average is 202%;
and for small companies, the average is 239%. Time Overruns % of Responses
Under 20% 13.9%
21 - 50% 18.3%
51 - 100% 20.0%
101 - 200% 35.5%
201 - 400% 11.2%
Over 400% 1.1%
Content Deficiencies
For challenged projects, more than a quarter were completed with only 25% to 49% of
originally-specified features and functions. On average, only 61% of originally specified
features and functions were available on these projects. Large companies have the worst
record with only 42% of the features and functions in the end product. For medium
companies, the percentage is 65%. And for small companies, the percentage is 74%.
% of Features/Functions % of Responses
Less Than 25% 4.6%
25 - 49% 27.2%
50 - 74% 21.8%
75 - 99% 39.1%
100% 7.3%
Currently, the 365 companies have a combined 3,682 applications under development.
Only 431 or 12% of these projects are on-time and on-budget.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 28
________________________________________________________________________
Survey Scope
232 survey respondents spanning multiple industries including government, Information
Technology, communications, financial, utilities, and healthcare. A total of 36 % of the
companies surveyed had, or were in the process of, implementing an ERP system.
Key Findings
51% viewed their ERP implementation as unsuccessful
46 % of the participants noted that while their organization had an ERP
System in place, or was implementing a system, they did not feel their
organization understood how to use the system to improve the way they
conduct business.
56 % of survey respondents noted their organization has a program
management office (PMO) in place, and of these respondents, only 36 % felt
their ERP implementation was unsuccessful
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 29
________________________________________________________________________
Survey Scope
Out of 1,450 questionnaires sent, 176 were analyzed. Of these, 61 % reported details on a
failed IT project.
Key Findings
Over 61% of the projects that were analyzed were deemed to have failed by the
respondents. More than three quarters blew their schedules by 30% or more; more than half
exceeded their budgets by a substantial margin. Considering that an estimated $25 billion is
spent on IT application development in Canada annually, the survey data clearly indicate
that unbudgeted IT project expenditures must run into the billions of dollars.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 30
________________________________________________________________________
Key Findings
The Standish Group research shows a staggering 31.1% of projects will be cancelled before
they ever get completed. Further results indicate 52.7% of projects will cost over 189% of
their original estimates. The cost of these failures and overruns are just the tip of the
proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the
trillions of dollars in the United States alone. Based on this research, The Standish Group
estimates that in 1995 American companies and government agencies will spend $81
billion for canceled software projects. These same organizations will pay an additional $59
billion for software projects that will be completed, but will exceed their original time
estimates. The Standish Group estimates that almost 80,000 projects were cancelled in
1995. Risk is always a factor when pushing the technology envelope, but many of these
projects were as mundane as a driver’s license database, a new accounting package, or an
order entry system.
On the success side, the average is only 16.2% for software projects that are completed on-
time and on-budget. In the larger companies, the news is even worse: only 9% of their
projects come in on-time and on-budget. And, even when these projects are completed,
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 31
________________________________________________________________________
many are no more than a mere shadow of their original specification requirements. Projects
completed by the largest American companies have only approximately 42% of the
originally-proposed features and functions. Smaller companies do much better. A total of
78.4% of their software projects will get deployed with at least 74.2% of their original
features and functions. This data may seem disheartening, and in fact it is, 48% of the IT
executives in our research sample feel that there are more failures currently than just five
years ago.
Data were collected by interviewing researchers and consultants using a semi structured
interview schedule. Some preparation was required by them. Each interview lasted, on
average, around 1.5 to 2 hours, though some lasted considerably longer.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 32
________________________________________________________________________
Key Findings
The IT project success rate quoted revolves around 20-30% based on its most optimistic
interviews. Bottom line, at best,7 out of 10 IT projects “fail” in some respect.
CASE STUDIES
California DMV
In 1987, the California Department of Motor Vehicles (DMV) embarked on a major project
to revitalize their drivers’ license and registration application process. By 1993, after $45
million dollars had already been spent, the project was canceled. According to a special
report issued by DMV, the primary reason for redeveloping this application was the
adoption new technology. They publicly stated: "The specific objective of the 1987 project
was to use modern technology to support the DMV mission and sustain its growth by
strategically positioning the DMV data processing environment to rapidly respond to
change." Also, according to the DMV special report "The phasing was changed several
times, but the DMV technical community was never truly confident in its viability...." The
project had no monetary payback, was not supported by executive management, had no
user involvement, had poor planning, poor design specifications and unclear objectives. It
also did not have the support of the state's information management staff. The DMV
project was not rocket science. There are much harder applications than driver licenses and
registrations. But because of internal state politics, unclear objectives, and poor planning,
the project was doomed from the start.
American Airlines
Early in 1994, American Airlines settled their lawsuit with Budget Rent-A-Car, Marriott
Corp. and Hilton Hotels after the $165 million CONFIRM car rental and hotel reservation
system project collapsed into chaos. This project failed because there were too many cooks
and the soup spoiled. Executive management not only supported the project, they were
active project managers. Of course, for a project this size to fail, it must have had many
flaws. Other major causes included an incomplete statement of requirements, lack of user
involvement, and constant changing of requirements and specifications.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 33
________________________________________________________________________
Hyatt Hotels
While Marriott and Hilton Hotels were checking out of their failed reservation system,
Hyatt was checking in. Today, you can dial from a cellular airplane telephone at 35,000
feet, check into your Hyatt hotel room, schedule the courtesy bus to pick you up, and have
your keys waiting for you at the express desk. This new reservation system was ahead of
schedule, under budget, with extra features -- for a mere $15 million of cold cash. They
used modern, open systems software with an Informix database and the TUXEDO
transaction monitor, on Unix-based hardware. Hyatt had all the right ingredients for
success: user involvement, executive management support, a clear statement of
requirements, proper planning, and small project milestones.
Banco Itamarati
A year after a strategic redirection, Banco Itamarati, a privately-held Brazilian bank,
produced an annual net profit growth of 51% and moved from 47th to 15th place in the
Brazilian banking industry. Three fundamental reasons account for Banco Itamarati's
success. First, they had a clear vision with documented specific objectives. Second, their
top-down level of involvement allowed Banco Itamarati to stay on course. And finally, the
bank produced incremental, measurable results throughout the planning/implementation
period. Banco Itamarati's clear business goal is to be one of Brazil's top five private-hlyeld
banks by the year 2000. Their objectives include maintaining a close relationship with their
customers to improve and maintain an understanding of their needs, offering competitive
financial solutions, guaranteeing customer satisfaction, and finally producing balanced
results for the Itamarati Group. Banco Itamarati's objectives were incorporated into a
strategic plan that clearly identified measurable results and individual ownership. Their
strategic plan made technology a key component of the business strategy. Itamarati used
Itautec's GRIP OLTP monitor as a basic tool for integrating software components.
According to Henrique Costabile, Director of Organization Development, "We are one of
the first banks to implement client-server architecture that maximizes the potential of this
architecture." Executive leadership, a well communicated plan, and a skilled diverse team
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 34
________________________________________________________________________
provided the foundation for Banco Itamarati to achieve their long-term goal, potentially
ahead of schedule.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 35
________________________________________________________________________
The literature review has been very informative as it has thrown light on the research and
articles that have been written on software project time overruns. Moreover it has helped in
identifying the degree of research that has been already done on the subject. It has
narrowed the scope of repetition and has formed the basis of secondary data for this study.
The following are the conclusions drawn from each of the articles used for literature
review:
How to Be Agile
This article talks about the various factors that can result in project success. These are slash
the budget; if it doesn't work, kill it; keep requirements to a minimum; build on success, not
hope; keep your development teams small; and assign non-it executives to software
projects.
Failure Statistics
The project success rates for large software companies were the least when compared to
that of the medium and small software companies. The major reason for the failures being
project restarts that cause both cost and time overruns. Again the cost and time overruns
were more for the large companies than the medium and small companies.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 36
________________________________________________________________________
Failure Rate
The statistics presented in this article all converge to establish that:
An IT project is more likely to be unsuccessful than successful
About 1 out of 5 IT projects is likely to bring full satisfaction
The larger the project the more likely the failure
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 37
________________________________________________________________________
Research Methodology
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 38
________________________________________________________________________
The sampling frame for the purpose of our study consists of all the software professionals
in India who are currently employed in the role of project leads or team leads or software
developers and testers with experience of 4 years or more.
The composition of the study sample consisted of Software project leads, team leads and
developers and testers with 4 or more than 4 years of experience. The respondents whom
we have approached are 52 in number.
Respondents have been selected from across a cross section of software product and
services companies. They have been selected from 19 companies in total belonging to
large, medium as well as small sized companies. Out of total number of respondents, only
one respondent did not give any response for the organization name. A company wise cross
section of respondents is depicted in the graph below.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 39
________________________________________________________________________
Most of the respondents had an experience of more than 4 years in the software field with
64% belonging to the category of 4 years to 8 years, 13% belonging to the category of
more than 8 years and 23% belonging to the category of less than 4 years. These figures are
depicted in the chart shown below.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 40
________________________________________________________________________
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 41
________________________________________________________________________
Interpretation
On an average 7 projects were undertaken by the respondents. The number of projects
ranged between 1 and 40. This has been shown in the graph above.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 42
________________________________________________________________________
Interpretation
On an average 10 person months were spent by the respondents on a project. The time
taken ranged between 3 and 36 person months. Out of 52 respondents 4 did not provide any
answer to this query. This has been shown in the graph above.
Interpretation
The team size of the respondents varied between 2 and 30 members with an average of 9
member team. The above graph depicts the same.
5.4 Project Completion
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 43
________________________________________________________________________
Interpretation
65% of the respondents said that the projects mostly completed on time. Only 12% said
that the projects always completed on time while 6% said that the projects were never
completed on time.
Interpretation
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 44
________________________________________________________________________
Majority of the respondents agree that the products that they delivered met all the
requirements as per the initial specifications. 63% said yes to the query while 35% negated
the query and 1 respondent did not respond to the query.
Interpretation
63% of the respondents said that only 10-30% of the features were added later to the
product. 29% said that less than 10% of features were added later while 8% said that 30-
50% of the features were added later. None of the respondents said that more than 50% of
the features were added later.
5.7 Managing large teams
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 45
________________________________________________________________________
Interpretation
A majority of respondents consider managing large teams as “Not so easy”. Only 8%
consider it as “Easy” and 4% consider it as “Very difficult”.
5.8 Problems faced in managing teams
Interpretation
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 46
________________________________________________________________________
44% of the respondents find communication as a major problem in handling teams. The
next major problem faced is lack of experience of the team members followed by friction
between members and lack of management support. The other problems identified by the
respondents were:
1. People not taking end-to-end ownership
2. Making them believe in what they are doing and explain them the need of following
some processes
3. Consistency in Competence and Commitment of the team members
4. Skill of every team members is not at same level, so many times some are more
overloaded than others
5. Team members not co-located (global team), Cultural differences
6. Co-ordination of various interfaces among various components
7. Co-ordination and resource sharing
8. Timely reporting of issues in the project
9. Balancing Team’s aspiration and Customer expectation
10. Managements support to set realistic targets and convince customer of the same
11. Member’s personal problems, immaturity, attitude, attrition
5.9 Ways of overcoming team management problem
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 47
________________________________________________________________________
Interpretation
31% of the respondents opted for more training courses as a viable option to overcome the
problems faced in managing teams while 29% opted for more project reviews and 19%
opted for smaller teams. 21% of the respondents provided other solutions to over come the
problems faced in managing teams. This include the following
1. Motivation and making sure that each employee blends with the organizational goals and
the processes it follows.
2. Groom team for Company and also Manager Style.
3. Define the processes very clearly during the planning stages and keep the team updated
about the same.
4. Explain the significance of the various steps and processes followed in the project to the
project team. This will help the team members answer the question: “Why are we doing
some specific activities?”
5. Management Support on Administrative & Infrastructure
6. More time should be given in design and requirements phase.
7. Meetings, Constructive feedback, non-penalizing reactions on issues reported, encourage
honesty
8. Leads & Project Managers undergo soft skills training and develop strategies for
excellence in the changing environment using innovation, displaying creative leadership
and building stronger teams
9. Managements support to set realistic targets and convince customer of the same.
10. To have back up plans ready always by anticipating problem areas.
11. Team building exercises, Team lunches to reduce friction between team members and
improve communication between team members
12. Have some senior folks, effective training and mentoring
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 48
________________________________________________________________________
Interpretation
None of the projects had time overruns of more than 3 months. 52% of the projects
overshot the time by less than 1 month and 48% overshot time b 1-3 months.
Interpretation
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 49
________________________________________________________________________
67% of the respondents use time tracking tools while the rest don’t use any sort of time
tracking tools. Most of the tools used were in-house developed and the others consisted
mainly of M/S Office Project, Excel Sheets, Lotus Notes, Rational Portfolio Manager,
CONCERTO and Outlook Calendar.
Interpretation
Besides using time tracking tools, 31 of the respondents use Checks and Reviews, 30% use
Regular meeting, 25% use Careful planning, 8% Allocates extra resources, 1% reduces
functionality to ensure that the projects are delivered on time. Other measures employed
include the following:
1. Allocate rightly skilled resources,
2. Identify and track Milestones
3. Proactively identify the possible risks and take the necessary mitigation steps
4. Good next-level leadership, empowerment, open-communication
5. Buffer management
6. Proper estimation before hand
7. Push back on some non priority requirement (Negotiate soft with customer),
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 50
________________________________________________________________________
8. Proactive Risk identification and mitigation/management,
9. Proactive Customer reporting
10. Proper allocation of work
11. Backup resources
Interpretation
37% of the respondents feel that lack of user input is to some extent responsible for
project time overrun while 36% feel that this factor is certainly responsible. Only 4%
feel that lack of user input is not responsible for project time over run.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 51
________________________________________________________________________
Interpretation
This factor is considered by the majority of the respondents i.e. 48% of the total, as
certainly responsible for project time overruns followed by 31% of respondents who feel
that this factor is responsible to a great extent for project time overrun. 17% and 4% voted
for responsible to some extent and not responsible respectively. Hence this factor turns out
to be a major area of concern.
5.13.3 Changing requirements and specifications
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 52
________________________________________________________________________
Interpretation
46% of the respondents consider changing requirements and specifications responsible to a
great extent for project time overrun and 31% feel that this factor is certainly responsible.
Only 4% feel that this factor is not responsible for project time overrun while 19% feel that
it is responsible to some extent. Overall this factor can also be considered as a major area
of concern.
5.13.4 Lack of executive support
Interpretation
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 53
________________________________________________________________________
Lack of executive support is considered by 52% of respondents as responsible to some
extent for project time overruns and 29% feel that it is not responsible. Only 13% and 6%
feel that it is responsible to great extent and certainly responsible, respectively.
Interpretation
41% of respondents feel that technology incompetence of the team members is to some
extent responsible for project time overrun, 31% feel that it is to a great extent
responsible,15% feel that it is certainly responsible and 13% feel that it is not responsible
for project time over run.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 54
________________________________________________________________________
Interpretation
33% of respondents feel that lack of resources is to great extent responsible for project time
overrun, 29% feel that it is certainly responsible, 21% feel that it is responsible to some
extent and 17% feel that it is not responsible for project time over run. Again, this factor
can be considered as an important factor to take care of to ensure on time delivery of
projects.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 55
________________________________________________________________________
Interpretation
34% of the respondents feel that this factor is certainly responsible for project time overrun
while 25% feel that it is responsible to a great extent. Only 10% feel that it is not
responsible and 31% feel that it is responsible to some extent. Overall, since majority of
respondents feel that it is certainly responsible, this factor is critical to avoid project time
overrun.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 56
________________________________________________________________________
Interpretation
38% of the respondents feel that unclear objectives are responsible to some extent in
causing project time overrun. 27% opted for “Certainly”, 25% opted for “To a great extent”
and 10% opted for “Not responsible”.
5.13.9 Unrealistic time frames
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 57
________________________________________________________________________
Interpretation
Majority of the respondents feel that this factor is responsible for project time overruns.
42% voted for responsible “To a great ex tent”, 29% voted for “Certainly” responsible,
19% voted for responsible “To some extent” and only 10% voted for “Not responsible”.
5.13.10 New technology
Interpretation
Half of the respondents feel that this factor is to some extent responsible while 19% feel
that it is not responsible. Only 25% and 6% feel that it is responsible to great extent and
certainly responsible, respectively.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 58
________________________________________________________________________
Interpretation
A major portion of the respondents consider this factor as very important. 36% feel that it is
certainly responsible for project time overrun, 21% feel that it is responsible to a great
extent, 35% feel that it is responsible to some extent and only8% feel that this factor is not
responsible for project time overrun.
5.13.12 Too many or complicated standards
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 59
________________________________________________________________________
Interpretation
This factor has net been give much importance by the respondents. 44% feel that too
many or too complicated standards are to only some extent responsible for project time
overrun,27% feel that it is not at all responsible, 17% feel that it is responsible to a great
extent while only 12% feel that it is certainly responsible for project time overrun.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 60
________________________________________________________________________
Summary of findings
6.1 Summary of findings
On an average 7 projects were undertaken by the respondents.
On an average 10 person months were spent by the respondents on a project. The time
taken ranged between 3 and 36 person months.
On an average the respondents worked in 9 member teams.
Majority of the respondents said that the projects mostly completed on time, signifying
that the project failure due to time overrun has decreased still further from that in the year
2000.
Majority of the respondents agree that the products that they delivered met all the
requirements as per the initial specifications and hence project failure due to the inability to
meet all the requirements as per initial specification has also reduced from the same in the
year 2000.
Majority of the respondents said that only 10%-30% of the features were added later to
the product. Hence we can probably say that the time and effort, both in human effort and
in cost, spent on adding new features to the released product have significantly decreased.
A majority of respondents consider managing large teams as not so easy. Thus we can
safely say that having large teams working on a project could be a hindrance to the
successful completion of the project.
Communication was considered by most of the respondents as a major problem in
managing the teams. The next most popular problem in handling teams seems to be lack of
experience of the team members.
More training courses for the team members and more project reviews were considered
by the respondents as the most effective ways to overcome the problems faced in managing
project teams. Among various other ways that can help make the team management easier,
significant emphasis was put on the need for clarification and detailed explanation of the
objective of the project and the need for each process and step undertaken to complete the
project.
As per the respondents’ replies, delivery time of the project exceeded by at the most 3
months. This is again a significant improvement for the findings in the year 2000.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 61
________________________________________________________________________
Majority of the respondents said that they used time tracking or accounting tools to
ensure that the project met the deadlines. Most of the tools used were in-house developed.
Among the other tools used M/S Office Project, Excel Sheets and Lotus Notes were the
most favored ones. However, those that do not use any time tracking or accounting tool
constitute a significant proportion. Hence some work needs to be done in this sphere to
ensure that such tools are used to effectively manage the software projects.
Checks and reviews and regular meetings were the most used measures adopted to
ensure that the projects met their deadlines. Other measures used include proper allocation
of resources, both human and technical resources and Buffer management.
Among the various factors that cause project time overrun, incomplete requirements
and specifications is considered to be certainly responsible for such overrun by the
respondents. Changing requirements and specifications and unrealistic time frames are
considered as to a great extent responsible for project time overrun. Factors like lack of
executive support, technology incompetence, unclear objectives, new technology and too
many or too complicated standards are considered to be responsible to some extent for
project time overrun. Other factors received mixed responses for the respondents. Hence
we can safely arrange these factors in decreasing order of responsibility as follows:
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 62
________________________________________________________________________
Recommendations
7.1 Recommendations
Software project teams should be smaller so that the team members can be easily
managed and there is no problem in communication between the members.
Whenever any changes are made to the project such that the features of the product
deviate from the initial specifications, a thorough re-planning should be done and extra
resources should be employed (or taken away as the case might be) so that the project
itself is on schedule. The end user should also be intimated about the changes made and
should be made aware of the consequences of such changes made. This will help in
reducing the time spent on making further changes to the product once it is released.
Extra effort should be made to ensure that all the team members are aware of the
happenings in the team. Effective communication channels should be established. Each
member of the team should be informed about the changes in the project. This will help in
better understanding and clarification of the project.
Every team should have a good balance between its experienced and inexperienced
members. Experienced members can guide the inexperienced members. This will help in
reducing the development time that would be consumed if the team is made up of only
inexperienced members who will learn and then perform. On the other hand if all the
members in the team are experienced, there are chances of increased friction between the
members. Hence a good balance has to be maintained.
More training courses should be arranged for the team members as well as the team
leaders and project managers. The training should be imparted in the technical field as well
as in the soft skills field. Training should be designed such that the trainees can get
information about the new technologies that can be used in their work.
Effective, regular and frequent project reviews should be performed so that all the team
members are aware of the happenings in the team. Such reviews will also help in tracking
the timely progress of the project.
Time tracking or accounting tool should be used to track the project progress. Some
recommended tools most widely used are M/S Office Project, Excel Sheets and Lotus
Notes.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 63
________________________________________________________________________
While planning the project schedule, sufficient buffer and back up should be allocated
to account for team members going on leave due to ill health, personal emergencies etc and
also for training. Often, time spent on training is not taken into consideration while
planning the project schedule. This should be accounted for in the schedule.
More effort and time should be spent in the project design and specification gathering
stages so that the specifications and requirements are complete and absolutely no or very
little changes are required to be made during the actual development stage. For this, co-
operation from the client is a must. Hence client partnering should be established such that
the client developer relationship is based on trust, credibility and relevance.
The organizational climate also plays an important role in the performance of its
employees. It represents the employees’ perceptions of the way thing are done in the
organization. The climate that is created in the organization can make a difference between
the winning and losing in the market place. The various elements that make up the
organizational climate are clarity in mission and direction, improvement in standards,
responsibility, autonomy, flexibility, rewards, recognition, team commitment, etc.
Team members should be encouraged to develop adaptability and creative problem
solving techniques.
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 64
________________________________________________________________________
Annexure
Questionnaire
Objective: To analyze the schedule risks that affects the software development
projects
2. Designation:
8. Was the product delivered with all the features/requirements as per initial
Specifications?
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 65
________________________________________________________________________
Yes No
11. What problems do you face in organizing, coordinating and monitoring your team?
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 66
________________________________________________________________________
Yes No
16. What other measures do you take to ensure that projects meet delivery
deadlines?
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 67
________________________________________________________________________
17. To what extent do you consider the following factors responsible for project
time overruns?
Incomplete requirements
and specifications
Changing requirements
and
specifications
Lack of executive
support
Technology
incompetence
Lack of resources
Unrealistic expectations
Unclear objectives
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 68
________________________________________________________________________
Unrealistic time frames
New technology
Lack of planning
Too many/complicated
standards
18. Will the business case be reviewed and revalidated at each scheduled gate and
whenever there is a significant change to the project or the business function?
Yes No
19. Have contingency plans for potential problems at these gates been developed in
advance?
Yes No
Yes No
21. Is an option to cancel the project at scheduled gates specified in the contract?
Yes No
22. Is there a change management process in place to ensure that changes are analyzed quickly
to determine their impact (risk, cost and time) and that this information is brought to the
attention of the appropriate level of management as soon as possible?
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 69
________________________________________________________________________
Yes No
23. Are there oversight reviews by a senior steering committee planned at each gate?
Yes No
________________________________________________________________________
M.P.Birla institute of Management, Bangalore
Analysis of schedule risks in software development projects 70
________________________________________________________________________
Bibliography
Books
1. “Business Research Methods” by Donald R. Cooper and Pamela S. Schindler, by
Tata McGraw-Hill Publication
3. “IT Systems Management” by Rich Schiesser, Prentice Hall of India Pvt. Ltd.
Websites surfed
1. www.google.com
2. www.mamma.com
3. www.agilealliance.org
4. www.softwaremag.com/archive/2001feb/collaborativeMgt.html
5. www.standishgroup.com
6. www.carolla.com
7. www.it-cortex.com
8. www.russellmartin.com
________________________________________________________________________
M.P.Birla institute of Management, Bangalore