Analysis of Software project time overrun
1 M. P. Birla Institute of Management
Analysis of factors that cause
Software Project Time Overrun A dissertation submitted in partial fulfillment of the
requirements for the award of
MBA Degree of Bangalore University.
Submitted By
Sudip Kumar Basu Regd. No.: 05XQCM6096
Under the guidance of
Prof. Jai Raj Nair
M.P.BIRLA INSTITUTE OF MANAGEMENT
(ASSOCIATE BHARTIYA VIDYA BHAVAN.)
BANGALORE-560001
2005-2007
Analysis of Software project time overrun
2 M. P. Birla Institute of Management
DECLARATION
I hereby declare that the research work embodied in the dissertation
entitled, “Analysis of factors that cause Software Project Time
Overrun”, has been carried out by me under the guidance and supervision
of Prof. Jai Raj Nair, Assistant Professor, M. P. Birla Institute of
Management, Bangalore.
I also declare that this dissertation has not been submitted to any
University/Institution elsewhere for the award of any Degree/Diploma.
Place: Bangalore ( Sudip Kumar Basu)
Date: Regd. No.: 05XQCM6096
Analysis of Software project time overrun
3 M. P. Birla Institute of Management
CERTIFICATE
I hereby certify that the research work embodied in the dissertation
entitled, “Analysis of factors that cause Software Project Time
Overruns” has been undertaken and completed by Mr. Sudip Kumar Basu
under my guidance and supervision.
I also certify that she has fulfilled all the requirements under the
covenant governing the submission of dissertation to the Bangalore
University for the award of MBA degree.
Place: Bangalore
Date: (Prof. Jai Raj Nair)
Internal Guide
MPBIM, Bangalore
Analysis of Software project time overrun
4 M. P. Birla Institute of Management
CERTIFICATE
I hereby certify that this dissertation titled “Analysis of factors that cause
Software Project Time Overruns” is an offshoot of the research work
undertaken and completed by Mr. Sudip Kumar Basu, under the guidance
of Prof. Jai Raj Nair, Assistant Professor, M. P. Birla Institute of
Management, Bangalore.
Place: Bangalore
Date: ( N. S. Malavalli)
Principal,
M.P.Birla Institute of Mgmt
Analysis of Software project time overrun
5 M. P. Birla Institute of Management
ACKNOWLEDGEMENT
I express my immense gratitude to Professor Jai Raj Nair, Assistant
Professor, M.P.Birla Institute of Management, Bangalore. He has been my
mentor and guide and his continuous encouragement and valuable
suggestions helped me at every stage of this project. I am grateful to Dr.
N.S. Malavalli, Principal, Directors and the staff of M.P.Birla Institute of
Management for their comments and encouragement at various phases of
this project.
I also extend my gratitude to all the 52 respondents from 19 software
companies across India for their prompt and timely help and guidance in
completing the project.
Place : Bangalore ( Sudip Kumar Basu)
Date : Regd. No.: 05XQCM6096
Analysis of Software project time overrun
6 M. P. Birla Institute of Management
Table of Contents
Executive Summery ...............................................................................1
Chapter 1: Introduction
1.1 Background.......................................................................................3
1.2 Statement of the problem..................................................................7
1.3 Objectives of the study ....................................................................7
1.4 Need and significance of the study...................................................8
Chapter 2: Industry Profile
2.1 Information Technology Industry in India .....................................10
2.2 Major steps taken for promotion of IT industry..............................11
Chapter 3: Review of Literature
3.1 Purpose of literature review............................................................13
3.2 Methodology of literature review...................................................13
3.3 Findings from literature review......................................................32
Chapter 4: Research Methodology
4.1 Scope of the Study .........................................................................35
4.2 Type of research ............................................................................35
4.3 Data Collection ..............................................................................35
4.4 Sampling technique .......................................................................35
4.5 Sample population .........................................................................35
4.6 Sampling frame..............................................................................36
4.7 Sample Size....................................................................................36
4.8 Sample Description........................................................................36
4.9 Instrumentation Techniques ..........................................................37
4.10 Tools for data analysis .................................................................37
Analysis of Software project time overrun
7 M. P. Birla Institute of Management
4.11 Limitations of the Study ..............................................................37
Chapter 5: Data Analysis and Interpretation
5.1 Average number of projects undertaken........................................39
5.2 Average time spent by the respondents on a typical project .........39
5.3 Average team size of the respondents ...........................................40
5.4 Project Completion ........................................................................40
5.5 Product delivered with all the initial requirements.........................41
5.6 Proportion of features added later ..................................................41
5.7 Managing large teams.....................................................................42
5.8 Problems faced in managing teams ...............................................42
5.9 Ways of overcoming team management problem..........................43
5.10 Increase in delivery time..............................................................45
5.11 Usage of time tracking tools.........................................................45
5.12 Other Measures employed to ensure time delivery of project …46
5.13 Factors responsible for project time overrun...............................47
Chapter 6: Summary of findings
6.1 Summary of findings ....................................................................55
Chapter 7: Recommendations
7.1 Recommendations..........................................................................59
Annexure
Questionnaire .................................................................................62
8. Select bibliography .......................................................................64
Analysis of Software project time overrun
8 M. P. Birla Institute of Management
Sr.No. Graph description Page No.
1 Projects show steady improvement 5
2 Category of software projects 6
3 Company wise cross section of respondents 36
4 Years of experience 37
5 Average number of projects undertaken 39
6 Average time spent by the respondents on a typical project 39
7 Average team size of the respondents 40
8 Project Completion 40
9 Product delivered with all the initial requirements 41
10 Proportion of features added later 41
11 Managing large teams 42
12 Problems faced in managing teams 42
13 Ways of overcoming team management problem 43
14 Increase in delivery time 45
15 Usage of time tracking tools 45
16 Other Measures employed to ensure on time delivery of project 46
17 Lack of user input 47
18 Incomplete requirements and specifications 48
19 Changing requirements and specifications 48
20 Lack of executive support 49
21 Technology incompetence 49
22 Lack of resources 50
23 Unrealistic expectations 51
24 Unclear objectives 51
25 Unrealistic time frames 52
26 New technology 52
27 Lack of planning 53
28 Too many or complicated standards 53
Analysis of Software project time overrun
9 M. P. Birla Institute of Management
Executive Summery 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
Analysis of Software project time overrun
10 M. P. Birla Institute of Management
Chapter 1
Introduction
Analysis of Software project time overrun
11 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
12 M. P. Birla Institute of Management
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?
Past research findings
In 1986, Alfred Spector, president of Transarc Corporation, co-authored a paper
comparing bridge building to software development. The premise: Bridges are normally
built on-time, on-budget, and do not fall down. On the other hand, software never comes
in on-time or on-budget. In addition, it always breaks down. But there is another
difference between software failures and bridge failures, beside 3,000 years of
experience. When a bridge falls down, it is investigated and a report is written on the
cause of the failure. This is not so in the computer industry where failures are covered up,
ignored, and/or rationalized. As a result, the same mistakes are repeated over and over
again.
Analysis of Software project time overrun
13 M. P. Birla Institute of Management
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 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.
Analysis of Software project time overrun
14 M. P. Birla Institute of Management
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.
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.
Category of software projects The study established that the reason for most of the project failures was not lack of
money or technology, most failed for lack of skilled project management and executive
support.
The study further establishes that lack of executive support has replaced user involvement
as the number one cause of project failure. Without a staunch project champion with a
solid business vision, projects can drift into a technological or political abyss. Project
stakeholders must create business value by improving customer services, communicating
a clear business plan and delivering competitive advantage.
Analysis of Software project time overrun
15 M. P. Birla Institute of Management
1.2 Statement of the problem The above background shows that there exists a research gap. The above mentioned data
pertains to the year 2000. No fresh data on the failure rates of various software projects is
available neither has much work been done to analyze the various reasons that cause
these failures.
In view of this fact, this research work is aimed to analyze 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. However it should be borne in mind
that product success is not equal to project success. One project might be regarded by
management as a failed project. It might be several months late, and over-budget, and
with some initial quality problems. But the product could be a hit with customers, and
could be key moneymaker for the company. The reverse could be seen a number of times
- the project might be regarded as a success, delivered in acceptable time and cost etc, but
the product of the project might not realize the benefits. It is otherwise known as "The
operation was a success but the patient died".
This research work is aimed at analyzing the project success/failure and not product
success/failure.
1.3 Objectives of the study The main objectives of this study are as follows:
i. To analyze the various reasons for software project time overruns that cause project
failures.
ii. To provide recommendations to overcome the identified failure factors.
Analysis of Software project time overrun
16 M. P. Birla Institute of Management
1.4 Need and significance of the study As per the Standish Group’s study of 2000, only 28% of the software projects succeeded,
49% was challenged and the rest failed. But that was the scenario 5 years back. It is
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.
Analysis of Software project time overrun
17 M. P. Birla Institute of Management
Chapter 2 Industry Profile
Analysis of Software project time overrun
18 M. P. Birla Institute of Management
2.1 Information Technology Industry in India 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
Analysis of Software project time overrun
19 M. P. Birla Institute of Management
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.
2.2 Major steps taken for promotion of IT industry 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.
Analysis of Software project time overrun
20 M. P. Birla Institute of Management
Chapter 3 Review of Literature
Analysis of Software project time overrun
21 M. P. Birla Institute of Management
3.1 Purpose of literature review Literature is reviewed to explore the historical and current scenario of software projects
and as a whole to understand the software project management. Over and above, the
purpose of the literature review is to understand in totality the foundation of the research
problem, understand the data that has been gathered in the field of study and to make new
findings on the problem statement. The abstracts in the following pages are some of the
key literature reviewed in this project.
3.2 Methodology of literature review Different sources used in order to collect information or data are
· Internet
· Magazines and Journals
· Publications
· Articles
This encompasses different facets of information sources concerning the identification of
various reasons behind software project time overruns. It started with search in Computer
and IT magazines, textbooks and lot of other relevant magazines and journals.
Information on software project time overruns was mostly available on the websites; lots
of articles and presentations on the web sites were analyzed and used in the research for
better understanding of the topic. (A list of websites has been provided in the annexure.)
Analysis of Software project time overrun
22 M. P. Birla Institute of Management
Title: How to Be Agile Website: www.agilealliance.org Slash the budget.
Small budgets force developers to focus on the essential. Small budgets also make it
easier to kill failing projects. For example, imagine a project that has already cost $20
million. Imagine it's going down the tubes. With that much skin in the game, it's tempting
for the CIO to invest another $10 million in an attempt to rescue it rather than take a huge
loss. All too often, he ends up with a bigger one.
Jim Johnson, chairman of The Standish Group, says he forced the CIO of one Fortune
500 company to set a $100,000 ceiling on all software projects. No exceptions without
approval from the CIO and CEO. Johnson claims the company's project success rate went
from 0 percent to 50 percent.
If it doesn't work, kill it.
Bring marketing, program and project management, and IT executives together at the
beginning of a project and as it progresses to evaluate every piece of code in
development. Is it doing what the business wants? Is it working? Any code that isn't
should be mercy killed.
This is called triage, and it's "the perfect place to kill a software project," says Pat
Morgan, senior program manager at Compaq's Enterprise Storage Group. He holds
monthly triage sessions and says they can be brutal. "At one [meeting], engineering
talked about a cool process they were working on to transfer data between GUIs. No one
in the room needed it. We killed it right there. In our environment, you can burn a couple
of million dollars in a month only to realize what you're doing isn't useful."
Keep requirements to a minimum.
Don't start with everything you want the software to do; start only with what it absolutely
must do. And don't worry about writing all your needs down, because requirements
change.
Analysis of Software project time overrun
23 M. P. Birla Institute of Management
Every software project traditionally starts with a requirements document that will often
have hundreds or thousands of elements. But The Standish Group estimates that only 7
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 FinancExpress, 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.'"
Build on success, not hope.
As often as once a week, and not less than once a month, complete a piece of software.
Then have your business deciders test and approve it. That doesn't mean the software is
shipped or deployed, but it must work and it must be bug-free. This is the Agile concept's
most radical departure from traditional development. In some software projects, no one
shows working code for years.
Ken Moskowitz, CIO of New York City-based Standard & Poor's, dictates weekly builds
of his company's software. Every week, the pieces being worked on are compiled and
tested.
"We've had a great deal of success with it," Moskowitz says of this rigid weekly
schedule. "I don't want things thrown across the transom. I don't want 'Here, I think I
need this. Go and build it, and we'll see if it was what I really needed in the first place.'"
Analysis of Software project time overrun
24 M. P. Birla Institute of Management
Keep your development teams small.
The fewer the developers, the better. Developers should team code.
Proponents of Agile Development swear that team coding is more efficient and produces
stronger code than solo efforts. But even Fowler admits that this is one of the harder
tenets of Agile Development to accept. Who is teamed and why? How do you budget
their time? Expect a learning curve.
Caterpillar's Agile project encompasses 200 distinct financial screens and contains 1.5
million lines of code.
Assign non-IT executives to software projects.
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."
Analysis of Software project time overrun
25 M. P. Birla Institute of Management
Title: Project Management: The Criteria for Success
Authors: Jim Johnson, Karen D. Boucher, Kyle Connors,
and James Robinson
Magazine: Software Magazine (February/March 2001) 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's criteria established in
"Recipe for Success, 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:
Analysis of Software project time overrun
26 M. P. Birla Institute of Management
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
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.
Analysis of Software project time overrun
27 M. P. Birla Institute of Management
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.
3 Experienced project managers
Ninety-seven percent of successful projects have an experienced project manager at the
helm.
4 Clear business objectives
This factor has moved down one spot because evidence shows that experienced project
managers increase success rates.
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.
6 Standard software infrastructures
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
Analysis of Software project time overrun
28 M. P. Birla Institute of Management
in stand-alone application development, but in existing application integration. Standard
infrastructures can shortcut application integration.
7 Firm basic requirements
The word "basic" refers to base-level requirements. Creating minimal, obtainable base
requirements and then developing those features will reduce the effect of change.
Delivering minimal features allows users and executive sponsors to see quick results. As
a result, project managers are better prepared to articulate the needs and priorities of the
next project phase.
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.
10 Other criteria
In last place is a collection of other factors. These factors include small milestones,
proper planning, competent staff, and ownership. In the past, each of these factors was
given its own category.
Analysis of Software project time overrun
29 M. P. Birla Institute of Management
The CHAOS Ten success factors continue to be valuable for assessing project potential.
While nothing can guarantee project success, adhering to the CHAOS Ten will increase
your odds of putting together a winning project.
The Standish Group predicts that most projects started and resolved this year will be
micro projects : ones lasting no more than four months and run by four people. CHAOS
research shows minimization as a key factor in successful projects. The micro project is
the ultimate in minimization. Many last only three to four weeks.
Don't confuse micro projects with milestones — micro projects live and die on usable
deliverables.
The Web and standard infrastructure have made the microproject a viable entity. New
application versions can be brought up quickly, and bugs can be found, corrected online,
and benefits realized immediately. There's no need for release dates, shipping codes, or
drawn-out user training. One of Standish's Fortune 500 clients mandated microprojects.
The company's president must approve any project estimated to cost more than $100,000.
However, the advent of the microproject has made it harder to manage resources, and has
turned code version management into a nightmare. While microprojects are deliverables
by themselves, they rarely stand alone. Therefore, changes in one project can affect the
collection of objects, individual programs, interfaces, and databases. These entities could
be in the thousands, while teams and developers span time zones.
To address these issues requires an asset-based change management tool.
An asset-based tool that supports configuration management over multiple technologies
and programming styles is just the ante. The tool must support versions and relationships
of source files, directories, test cases, and configurations. The tool must also be able to
communicate the project to the development community to prevent duplication and make
developers aware of the project's use and reuse. It should control concurrent and parallel
versions and use roles-based access control.
This type of tool can go a long way in maintaining and developing successful
applications.
Analysis of Software project time overrun
30 M. P. Birla Institute of Management
Title: FAILURE STATISTICS
Website: www.standishgroup.com The Standish Group segmented the results by large, medium and small companies. A
large company is any company with greater than $500 million dollars in revenue per
year, a medium company is defined as having $200 million to $500 million in yearly
revenue, and a small company is from $100 million to $200 million.
The figures for failure were equally disheartening in companies of all sizes. Only 9% of
projects in large companies were successful. At 16.2% and 28% respectively, medium
and small companies were somewhat more successful. A whopping 61.5% of all large
company projects were challenged compared to 46.7% for medium companies and 50.4%
for small companies. The most projects, 37.1%, were impaired and subsequently
canceled in medium companies, compared to 29.5% in large companies and 21.6% in
small companies.
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.
Analysis of Software project time overrun
31 M. P. Birla Institute of Management
Cost Overruns % of Responses
Under 20% 15.5%
21 - 50% 31.5%
51 - 100% 29.6%
101 - 200% 10.2%
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.
Analysis of Software project time overrun
32 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
33 M. P. Birla Institute of Management
Title: Failure Rate
Website: www.it-cortex.com/Stat_Failure_Rate.htm The following surveys provide statistical data over the rate of failure of IT projects.
The Robbins-Gioia Survey (2001) Robbins-Gioia, LLC, a provider of management consulting services located in
Alexandria - Virginia, made a study over the perception by enterprises of their
implementation of an E.R.P. (Enterprise Resource Planning) package.
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
Comments on the Robins-Gioia Survey
Project failure is not defined by objective criteria but by the perception of the
respondents. The advantage of a perception is that it naturally integrates multiple aspects.
Its obvious disadvantage is that it is inevitably partial: if the respondent has taken an
active role in the project it will inevitably embellish the reality, whereas if the project has
been "forced down his throat" he might cast a grimmer look at the project outcome.
The Conference Board Survey (2001) Survey Scope
That survey interviewed executives at 117 companies that attempted ERP
implementations
Analysis of Software project time overrun
34 M. P. Birla Institute of Management
Key Findings
34 % were very “satisfied.”
58% were somewhat satisfied
8% were unhappy with what they got
40% of the projects failed to achieve their business case within one year of going
live.
The companies that did achieve benefits said that achievement took six months
longer than expected.
Implementation costs were found to average 25 % over budget,
Supports costs were underestimated for the year following implementation by an
average of 20 %.
The KPMG Canada Survey (1997) In April 1997, KPMG Canada sent a survey questionnaire focusing on IT project
management issues to Canada's leading 1,450 public and private sector organizations.
The main purpose was to outline the reasons behind the failure of Information
Technology projects.
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.
Analysis of Software project time overrun
35 M. P. Birla Institute of Management
The Chaos Report (1995) The Chaos Report is the first survey made by the Standish Group. This report is the
landmark study of IT project failure. It is cited by everybody writing a paper or making a
presentation were a reference is made of IT project failure.
Scope of the Study
The respondents to the Standish Group survey were IT executive managers. The sample
includes large, medium, and small companies across major industry segments: banking,
securities, manufacturing, retail, wholesale, heath care, insurance, services, and local,
state, and federal organizations. The total sample size was 365 respondents representing
8,380 applications. In addition, The Standish Group conducted focus groups and personal
interviews to provide qualitative context for the survey results.
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 costover
189% of their original estimates. The cost of these failures and overruns are just he 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,
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
Analysis of Software project time overrun
36 M. P. Birla Institute of Management
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.
The OASIG Study (1995) This study has been undertaken under the auspices of OASIG, a Special Interest Group
in the UK concerned with the Organizational Aspects of Information Technology.
Scope of the Study
Information was collected in 1995 in the United Kingdom from a sample of 45 experts
employed primarily by Universities or Consultancies. On average they have each over 20
years personal experience representing a cumulative knowledge base of over 900 years.
They drew their opinion from a sample of approximately 14,000 user organizations. 31 of
these interviewees (69%) include consultancy work as a major component of their work,
and 27 (60%) include research; many do both. Their professional areas of expertise cover
the domains of management, business, and social science. A small number of those
interviewed have a background in engineering.
Data were collected by interviewing researchers and consultants using a semistructured
interview schedule. Some preparation was required by them. Each interview lasted, on
average, around 1.5 to 2 hours, though some lasted considerably longer.
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.
Analysis of Software project time overrun
37 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
38 M. P. Birla Institute of Management
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 atabase 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 privately –held
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 a client-server architecture that maximizes the potential of
Analysis of Software project time overrun
39 M. P. Birla Institute of Management
this architecture." Executive leadership, a well communicated plan & skilled diverse team
provided the foundation for Banco Itamarati to achieve their long-term goal, potentially
ahead of schedule.
CASE STUDY CONCLUSIONS The study of each project included adding up success points on the "success potential"
chart.
Success Criteria Points DMV CONFIRM HYATT ITAMARATI
1. User Involvement 19 NO ( 0) NO ( 0) YES(19) YES (19)
2. Executive Management
Support 16 NO ( 0) YES (16) YES(16) YES (16)
3. Clear Statement of
Requirements 15 NO ( 0) NO ( 0) YES(15) NO ( 0)
4. Proper Planning 11 NO ( 0) NO ( 0) YES(11) YES (11)
5. Realistic Expectations 10 YES(10) YES (10) YES(10) YES (10)
6. Smaller Project Milestones 9 NO ( 0) NO ( 0) YES ( 9) YES ( 9)
7. Competent Staff 8 NO ( 0) NO ( 0) YES ( 8) YES ( 8)
8. Ownership 6 NO ( 0) NO ( 0) YES ( 6) YES ( 6)
9. Clear Vision & Objectives 3 NO ( 0) NO ( 0) YES ( 3) YES ( 3)
10. Hard-Working, Focused
Staff 3 NO ( 0) YES ( 3) YES ( 3) YES ( 3)
TOTAL 100 10 29 100 85
With only 10 success points, the DMV project had virtually no chance of success. With
100 success points, Hyatt's reservation project had all the right ingredients for success.
With only 29 success points, the CONFIRM project had little chance of success. With 85,
Itamarati, while not as assured as Hyatt, started with a high success probability.
Analysis of Software project time overrun
40 M. P. Birla Institute of Management
3.3 Findings from literature review 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.
Project management: the criteria for success
As compared to the projects in 1994, the projects in 2000 were more successful in terms
of completion within budget, on time and with features originally required. The article
further goes on to tell that there are 10 factors that contribute to a projects success.
Although no project requires all 10 factors to be successful, the more factors present in
the project strategy, the higher is the confidence level. These factors are executive
support, user involvements, experienced project manager, clear business objectives, and
minimized scope, standard software infrastructure, firm basic requirements, formal
methodology, reliable estimates and others.
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.
Analysis of Software project time overrun
41 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
42 M. P. Birla Institute of Management
Chapter 4 Research Methodology
Analysis of Software project time overrun
43 M. P. Birla Institute of Management
4.1 Scope of the Study This study is restricted to the software projects only. The study does not analyze the
product success nor does it foray into any other types of project.
4.2 Type of research The project employs systematic, formal and descriptive research techniques. This is
primarily a qualitative research. This study is based on the data collected through
structured questionnaire and in-depth, unstructured and informal interview with key
personnel.
4.3 Data Collection Data sources consisted of primary and secondary. Sources of primary data include the
Software project leads, team leads and developers and testers with 4 or more than 4 years
of experience.
A structured questionnaire was developed and administered to generate the primary data.
Sources of secondary data included the information provided by various text books,
magazines and internet. Internet has been a major secondary source for the extraction of
the expert’s opinion.
4.4 Sampling technique The sampling techniques used are snowball sample technique and stratified sample
technique. The respondents for the study have been selected based on the years of
experience and expertise for the given role. Using these selected respondents furthers
contacts were established and then converted into respondents.
4.5 Sample population The sample population for the purpose of our study consists of all the software
professionals.
Analysis of Software project time overrun
44 M. P. Birla Institute of Management
4.6 Sampling frame 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.
4.7 Sample Size 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.
4.8 Sample Description 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.
Analysis of Software project time overrun
45 M. P. Birla Institute of Management
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.
4.9 Instrumentation Techniques Structured Questionnaire: The primary data has been collected through structured
Questionnaires, which were administered to the respondents. One set of Questionnaire
has been developed to identify the factors that cause project time overruns. (Annex 1A).
4.10 Tools for data analysis Since our research topic is highly qualitative in nature, we are prompted to use simple
percentages so as to enable the data to be more succinct and amenable for easy
interpretation. We believe that simple treatment of data will be more useful in drawing
inferences from the data.
4.11 Limitations of the Study Research investigation is beset with time and resource constraints. Research is limited to
respondents in India across only 19 companies of large, medium and small size and hence
the limitation of generalization becomes obvious.
Analysis of Software project time overrun
46 M. P. Birla Institute of Management
Chapter 5
Data Analysis and
Interpretation
Analysis of Software project time overrun
47 M. P. Birla Institute of Management
5.1 Average number of projects undertaken Source: Field Investigation
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.
5.2 Average time spent by the respondents on a typical project
Source: Field Investigation
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.
Analysis of Software project time overrun
48 M. P. Birla Institute of Management
5.3 Average team size of the respondents
Source: Field Investigation
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
Source: Field Investigation
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.
Analysis of Software project time overrun
49 M. P. Birla Institute of Management
5.5 Product delivered with all the initial requirements
Source: Field Investigation
Interpretation
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.
5.6 Proportion of features added later
Source: Field Investigation
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-
Analysis of Software project time overrun
50 M. P. Birla Institute of Management
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
Source: Field Investigation
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
Source: Field Investigation
Analysis of Software project time overrun
51 M. P. Birla Institute of Management
Interpretation
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
Analysis of Software project time overrun
52 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
53 M. P. Birla Institute of Management
5.10 Increase in delivery time
Source: Field Investigation
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.
5.11 Usage of time tracking tools
Source: Field Investigation
Analysis of Software project time overrun
54 M. P. Birla Institute of Management
Interpretation
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.
5.12 Other Measures employed to ensure on time delivery of
Project
Source: Field Investigation
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).
Analysis of Software project time overrun
55 M. P. Birla Institute of Management
8. Proactive Risk identification and mitigation/management.
9. Proactive Customer reporting.
10. Proper allocation of work.
11. Backup resources.
5.13 Factors responsible for project time overrun The following charts depict the respondent’s attitude towards various factors that can be
held responsible for project time overrun. Each factor is measured over a scale of four:
Certainly Responsible, Responsible to a Great Extent, Responsible to Some Extent and
Not Responsible.
5.13.1 Lack of user input
Source: Field Investigation
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.
Analysis of Software project time overrun
56 M. P. Birla Institute of Management
5.13.2 Incomplete requirements and specifications
Source: Field Investigation
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
Source: Field Investigation
Analysis of Software project time overrun
57 M. P. Birla Institute of Management
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
Source: Field Investigation
Interpretation
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.
5.13.5 Technology incompetence
Source: Field Investigation
Analysis of Software project time overrun
58 M. P. Birla Institute of Management
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.
5.13.6 Lack of resources
Source: Field Investigation
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.
Analysis of Software project time overrun
59 M. P. Birla Institute of Management
5.13.7 Unrealistic expectations
Source: Field Investigation
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.
5.13.8 Unclear objectives
Source: Field Investigation
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”.
Analysis of Software project time overrun
60 M. P. Birla Institute of Management
5.13.9 Unrealistic time frames
Source: Field Investigation
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
Source: Field Investigation
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.
Analysis of Software project time overrun
61 M. P. Birla Institute of Management
5.13.11 Lack of planning
Source: Field Investigation 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
Source: Field Investigation
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,
Analysis of Software project time overrun
62 M. P. Birla Institute of Management
Chapter 6 Summary of findings
Analysis of Software project time overrun
63 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
64 M. P. Birla Institute of Management
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.
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:
Analysis of Software project time overrun
65 M. P. Birla Institute of Management
Factors responsible for project time overrun in decreasing order of Responsibility
1 Incomplete requirements and specifications 2 Changing requirements and specifications 3 Unrealistic time frames 4 Lack of executive support 5 New technology 6 Too many/complicated standards 7 Technology incompetence 8 Unclear objectives 9 Lack of user input
10 Lack of planning 11 Unrealistic expectations 12 Lack of resources
Analysis of Software project time overrun
66 M. P. Birla Institute of Management
Chapter 7 Recommendations
Analysis of Software project time overrun
67 M. P. Birla Institute of Management
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.
Analysis of Software project time overrun
68 M. P. Birla Institute of Management
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.
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.
Analysis of Software project time overrun
70 M. P. Birla Institute of Management
Questionnaire
Objective: To analyze the reasons behind software project time
overruns
1. Name of the organization:
2. Designation:
3. Years of Experience: < 4 years 4-8 years > 8 years
4. Number of Projects undertaken:
5. Average time spent on a typical project (in person months):
6. What was the average team size? _____________
7. Did the project get completed on time?
Always Mostly Sometimes Never
8. Was the product delivered with all the features/requirements as per initial
specifications?
Yes No
9. What proportion of features/requirements was added later?
<10% 10%-30% 30%-50% >50%
10. Do you consider managing a large team as
Easy Not so easy Difficult Very difficult
11. What problems do you face in organizing, coordinating and monitoring your
team?
Communication Lack of experience Friction between members
Lack of management support Others
Specify others ______________________________
12. What can be done to overcome the above problem?
More training courses Smaller teams More project reviews
Others Specify others ______________________________
Analysis of Software project time overrun
71 M. P. Birla Institute of Management
13. Delivery times were exceeded by
<1 month 1-3 months 3-6 months >6 months
14. Do you use any time tracking/accounting tools?
Yes No
15. If yes, which? ______________________________
16. What other measures do you take to ensure that projects meet delivery deadlines?
Regular meetings Checks and reviews Careful planning
Allocate extra resources Reduce functionality Others
Specify others ______________________________
17. To what extent do you consider the following factors responsible for project time
overruns?
Factor Certainly responsible
To a great extent
To some extent
Not Responsible
Lack of user input Incomplete requirements and specifications Changing requirements specifications Lack of executive support Technology incompetence
Lack of resources
Unrealistic expectations
Unclear objectives
Unrealistic time frames
New technology
Lack of planning Too many/complicated standards
Analysis of Software project time overrun
72 M. P. Birla Institute of Management
Select bibliography
Books
1. “Business Research Methods” by Donald R. Cooper and Pamela S. Schindler, by
Tata McGraw-Hill Publication
2. “Systems Analysis and Design Methods” by Jeffery L. Whitten, Lonnie D.
3. Bentley and Kevin C. Dittman by Tata McGraw-Hill Publication.
4. “IT Systems Management” by Rich Schiesser, Prentice Hall of India Pvt. Ltd.
Magazines and Journals 1. P C Quest, June 2005.
2. Software Magazine (February/March 2001).
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