This document is a project report submitted by Sudipta Das for their MBA in Project Management. The report explores the management of large and complex software projects. It begins with declarations and acknowledgements. The table of contents outlines the structure of the report, which includes an introduction on complexity, large projects, and software estimation. It also covers a case study, challenges in handling complex projects, tools used, and a comparison of Indian IT vendors and global companies. The executive summary provides a high-level overview of the topics to be discussed in the report such as defining complexity, the relationship between large and complex projects, measuring complexity, and issues in handling such projects.

1. A PROJECT REPORT
ON
“Management of Large and Complex Software
Projects”
By
Sudipta Das
MBA (Project Management)
(Registration No. 1402013429)
Guide
Abhishek Banerjee
A Project report submitted in partial fulfillment of the requirements
for the award of degree of Master of Business Administration in Project
Management.
1

2. DECLARATION
I hereby declare that the Project report entitled: Management of Large
and Complex Software Projects.
A Project Report on “Management of Large and Complex Software
Projects” submitted in partial fulfillment of the requirement for the
degree of Masters of Business Administration to Sikkim – Manipal
University, India, is my original work and not submitted for the award of
any other degree, diploma, fellowship, or any other similar title or prizes.
Place: Bangalore
Date: 25.01.16
Name: Sudipta Das
Registration No. 1402013429
2

3. Certificate
The Project report of Sudipta Das (Registration No. 1402013429) A
Project Report on “Management of Large and Complex Software
Projects” is approved and is acceptable in quality and form.
Internal Examiner External Examiners
(Mr. __________) (Mr. ____________)
3

4. ACKNOWLEDGEMENT
I am thankful to my project guide Abhishek Banerjee for his valuable
guidance, encouragement, useful suggestions which helped me
accomplishing my project report.
I am thankful to the respondents who have taken out time from their
busy schedule to fill up the questionnaire, both in person and through
mail.
I express my gratitude and heartfelt thanks to all those people who
provided me all the necessary information reaching at this stage,
through this acknowledgement, I would like to thanks to all those
people who has provided me all the information directly or indirectly
throughout this project report has been successfully completed.
Name: Sudipta Das
Registration No. 1402013429
4

5. TABLE OF CONTENTS
Executive Summary.....................................................................................................6
Tables and Figures.......................................................................................................9
Table 4: Comparison table of Indian IT and Global IT giant
………………………..94..............................................................................................9
Rationale of this dissertation ....................................................................................10
Deal Size and its Significance..................................................................................11
Dissertation Objectives..............................................................................................15
Dissertation Scope......................................................................................................15
Dissertation Structure................................................................................................16
Dissertation Methodology..........................................................................................17
Introduction................................................................................................................18
What is Complexity?................................................................................................19
Types of Software Complexity................................................................................19
Why is Software Complexity Important?................................................................24
Complex Modeling Structure...................................................................................25
What do we mean by Large Projects?......................................................................26
Software Estimation...................................................................................................29
Does Large Projects Always Complex and Vice Versa?.........................................34
Software Project Types and their Complexity levels..............................................37
How do we measure Complexity?.............................................................................46
Lines of Code...........................................................................................................47
Function Points measurement .................................................................................50
CASE STUDY.............................................................................................................51
Clients’ expectation from vendors for outsourcing Large and Complex projects
......................................................................................................................................55
Why do complex and large projects fail?.................................................................57
Challenges in handling these projects......................................................................57
Key Concern areas.....................................................................................................58
Tools used For Managing Complex and Large Software projects........................68
5

6. Microsoft Project......................................................................................................68
Gantt chart................................................................................................................73
TCS’s MasterCraft ..................................................................................................78
Indian IT Vendors Vs Global MNCs........................................................................94
Conclusion...................................................................................................................97
Recommendations......................................................................................................98
References...................................................................................................................99
Executive Summary
6

7. Like other industries, Software firms have three broad areas People, Process
and Technology based on which it functions. Every software firm is looking forward
to satisfying their clients to their best with their manpower, Delivery model and
Expertise. With massive presence of IT firms with their unique knowledge, expertise
and skills, there is an intense competition that clouds the IT firms in terms of revenue,
client acquisition and global presence. Competition has led IT customers/clients with
numerous options to select from. There are many parameters, which clients look for,
based on which the Software projects are being carried out like low cost delivery
model, quality, and domain knowledge. Every company has to differentiate itself on
these parameters in order to get long term relationship with the clients.
One of the major challenges of IT firm is to deliver low cost model with better
quality. Software companies are not only competing in their home turf but also
globally to satisfy their clients. The main focus of the IT firms is to generate steady
revenue over years through their large projects. As a matter of fact, major proportion
of revenue of the leading software firms comes from these large projects which have
been carried out over a period of years. For this the IT firm has to be well equipped
with their restheces, knowledge base and experience for handling large and complex
proejcts. Companies like TCS, Infosys, Wipro etc are vying for this with its easy
access to manpower which is over 15000 and Global delivery model. Asia has now
become the destiny for large and complex projects with its cost benefit. Even Global
companies like IBM, Accenture etc are increasing there manpower every year in Asia.
There is also an immense pressure from the client’s side for low cost model and many
IT firms are also looking for long term contract with their clients.
7

8. There are many consultancies which provide valuable guidelines to the clients
in selecting the IT firm for handling these large projects. These Consultancies help the
clients in identifying the right company for their projects with in depth analysis of the
client’s need.
This research will cover the latest IT outsourcing trends and the need of Indian
IT vendors to implement effective project management approach for handling large
and complex software projects. The Complexity types and level involved in various
software projects. To define and understand the complexity involved in the software
project both before and after project development phase. This research will give you a
better insight of relationship between large and complex projects and their
corresponding tools, measure and methodology.
8

9. Tables and Figures
Figure 1: Complex Model …………………………………………………………...24
Table 2: Large and Complex matrix …………………………………………………34
Figure 2: Value Pyramid …………………………………………………………….36
Figure 3: Software product Market Strategies ………………………………………37
Table 2: Functional Point Analysis ………………………………………………….49
Figure 4: Cultural building …………………………………………………………..63
Figure 5: Communication Stages ……………………………………………………64
Table 3: Gantt Chart ………………………………………………………………...74
Figure 6: Design Chart ………………………………………………………………76
Figure 7: Critical Path Analysis ……………………………………………………..77
Figure 8: Prince2 Methodology ……………………………………………………...86
Table 4: Comparison table of Indian IT and Global IT giant ………………………..94
9

10. Rationale of this dissertation
After certain hiccups the Indian IT industry has become a potential contributor
in the Global IT Outsourcing deals. India is now considered as the one of the
preferable Outsourcing destination next to US and Europe. Companies like TCS,
Infosys, Wipro etc., are now competing with global giants like IBM, HP, EDS etc.,
though we are far behind them in terms of capability and experience. We have been
handling projects like Application maintenance, Support and enhancement. We still
have to move up the value chain in handling more complex and large projects like
Infrastructure projects, Product and Asset management and business process
outsourcing.
IT management and operations plays an important role in handling these
complex and Large Software projects. Management of these projects requires some
robust tools, techniques and methodology since the risk factor is high. There could be
many issues in handling these projects like Manpower planning, training, financial
restructuring, pricing, communication etc. Bill Gates, chairman and chief software
architect of Microsoft affirms that US multinationals are off shoring more and more
larger software projects to India and that's why Indian companies are growing in
terms of volumes and revenue. We are moving up on both the size as well as
complexity of projects we take. Before dwelling more in to the pros and cons of
managing complex and large software projects we first understand the Industry trends
and the need for Indian IT Company to adopt a specialized technique for these
projects. The following facts would give us a better idea as why it is necessary for the
IT companies to acquire expertise in handling Large and Complex projects.
10

11. Deal Size and its Significance
After all, it was the first time in the history of Indian IT industry, that a
contract as big as $400 million was outsourced to India. It was several times the worth
of many Indian IT companies and equals HCL Technologies' annual export revenue
for03-04.
But was the contract for Indian companies really large in global terms? Of the
total $163 billion of IT services outsourced every year, $400 million sounds small.
Then again, why is the Indian IT community so exuberant about the deal? Which are
the factors that prevent Indian companies from clearing the screening process for
billion dollar tenders, leave alone bid for them. Will an Indian company ever bag a
billion-dollar IT outsourced contract in the near future? We answer some of these
questionshere.
The total committed deal stands at €1.8 billion ($2.2 billion), divided among
three companies Infosys, TCS and IBM. TCS has bagged $260 million while over
$140 million will go in to Infosys' pocket. This is the single largest deal for both
Infosys and TCS, India's largest IT companies. TCS and Infosys will support
application maintenance for ABN AMRO's global locations.
Another Indian company Patni has been selected as a preferred vendor for
application development. Patni will compete with IBM, Accenture, TCS and Infosys
for what is called a discretionary spend by ABN AMRO for application development.
IBM has bagged the biggest chunk that stands at €1.5 billion. It will manage the IT
infrastructure for ABN AMRO. The number of global outsourced deals worth more
than $100 million has increased from 49 in 2002 to more than 200 in 2004.
11

12. According to Gartner, the worldwide outsourcing market is slated to grow
to $429 billion in 2008. The big six of outsourcing are: IBM, ACS, Accenture, CSC,
EDS and HP. IBM leads the group with the biggest number of large outsourcing deals
in its kitty. The largest global deals in the outsourcing arena are IBM-JP Morgan ($5
billion), EDS-Bank of America ($4.5 billion), Siemens-BBC ($3.6 billion) and HP-
ABB ($3billion).
According to Datamonitor, IBM has been the biggest winner taking 21
percent of all contracts. In 2003, IBM bagged a $1.2 billion contract with Michelin
and a $1.1 billion contract with ABB. Compared with global outsourcing contracts,
Indian contracts seem very small. Apart from the ABN AMRO deal with TCS and
Infosys, other big outsourcing deals in the Indian scenario are TCS-GE Medical ($100
million)andWipro-Lattice($70million).
In 2004, Europe outperformed the United States in terms of total
outsourcing. While ITO (IT Outsourcing) formed 67 percent, BPO was 37 percent of
total outsourcing. Of the global outsourcing pie, only a meager $ 17 billion comes to
India every year. Why are Indian IT companies not able to bid for big global
contracts? Because Indian IT companies lack the ability to takeover large number of
employees and assets on their balance sheet. Large ITO (IT outsourcing) deals require
transfer of thousands of people. It requires transfer of assets like data centers, network
infrastructure. The Indian IT companies clearly lack that ability.
Large deals lower the Operating Profit Margin (OPM) on the balance sheet.
There is unwillingness on the part of Indian IT firms to operate in the high volume
area as it will dilute margins. They are focused more on profits than at growth. Also
Clients are wary of outsourcing to vendors who have annual revenues equal to that of
the contract. It heightens risk and puts a question mark on efficient delivery. Large
contracts require massive HR exercise. Employees should not feel demotivated due to
outsourcing. It's almost like a merger between two companies.
12

13. The vendor should also have a background and experience of executing large
contracts. Indian firms lack the domain expertise in critical but more lucrative
processes like infrastructure management. In the ABN AMRO deal, only a less
critical part of application maintenance and development has been outsourced to
Indian firms. Also, the revenue realization in large deals happens over a cthese of
time.
The outsourcing happens in small to bigger chunks over the given period.
Indian companies operate in the sphere of high margins and low volumes as opposed
to global giants of outsourcing. So, taking over large contracts will require complete
financial restructuring of Indian IT companies.
Globally, there has been a shift from single chunk multi-billion dollar deals
to outsourcing to multiple vendors. There has been a decline in the share of Big Six'
over the years. Mammoth contracts are becoming difficult to manage. They lower
overall profits and result in inefficiency, for example: EDS had a tough time
managing a multi-billion dollar contract to upgrade U.S. Navy's computer and
communication systems. It resulted in huge operating losses. Thus, many of the big
daddies of outsourcing are also bidding for multi-million dollar contracts rather than
huge billion dollar contracts. JPMorgan canceling its $5 billion outsourcing contract
with IBM indicates that mega deals are becoming difficult to manage by a single
vendor.
Recently, EDS and Dow Chemical also mutually terminated their
outshining contract worth $1.4 billion. Indian players jumping into the market and
providing services at cheaper rates is changing the overall market. Now, clients are
bargaining harder with global giants. They are also splitting contracts between
multiple vendors to create competition and in turn, better delivery of services. There
is potential amongst Indian IT firms to execute larger contracts. But, how many of
them are willing to compromise on profits for growth, remains a question. Why are
we so exuberant about the deal?
The implementation of application support and maintenance by TCS and
Infosys will be phased over a period of 18 months. The deal will help us utilize the
13

14. latest technology to improve the services. IBM is expected to assume management of
the majority of ABN AMRO's worldwide information technology systems including
servers, storage systems and desktops. The only exception is the IT infrastructure of
the business unit of wholesale clients, which was already outsourced to EDS in 2003.
What does the ABN Amro deal mean for the future of the Indian IT
industry? In addition to significant revenues, it will allow us to utilize the Global
Delivery Model in its entirety." TCS has 40,000 IT consultants located in 33
countries.
It is the largest deal outside the US for TCS. Infosys will have an onsite plus
offsite delivery model. The deal indicates that large Indian offshore players have a
competitive business model to deliver global multi-year contracts. It indicates a shift
towards strategic global outsourcing where customers are selecting best-of-breed
vendors to improve efficiency in the IT service delivery.
As from the above trend we could see that it is imperative for IT companies
to increase the capability and experience in implementing the best in class approach
for complex and large software projects.
Successful implementation of such large projects requires a synthesis of:
• Experienced management and leadership
• In-depth domain and functional knowledge
• A wide range of technology skills across multiple technologies and platforms
• Architectures and designs that will endure the test of time
• Organizational focus and commitment
• Active participation of all stakeholders, including vendors
14

15. Dissertation Objectives
 To understand the latest IT outsourcing trends and ascertain the need of Indian
IT vendors to implement effective project management approach for handling
large and complex software projects
 To define and understand the complexity involved in the software project both
before and after project development phase.
 To appreciate the relationship between large and Complex Software projects
 To ascertain the types of complexity involved in the large software projects
and their corresponding tools, measures, techniques and methodology.
 To compare and analyze the Indian IT vendors and MNC in handling these
projects
 To understand the issues involved in handling these projects and the ways to
tackle the issues.
Dissertation Scope
The dissertation primarily focuses on the reason behind the latest off sourcing
trends of large and complex software projects and the issues involved in handling
these projects. The dissertation also clarifies the basic understanding of complex and
large software projects. This dissertation will only study and analyze the foremost
complexity types involved in the project and their corresponding tools, measures,
techniques and methodology.
15

16. Dissertation Structure
Introduction
1. Define Complexity – What do we mean by complexity. Is it in terms of
technology or functions or industry or project type or geographical spread?
2. Define Large – Large in terms of number of modules or increasing scope etc.,
3. Does Large project always be complex or vice versa
4. Different types of Software projects and their corresponding level of
complexity
5. How do we measure Complexity in Software projects
6. Give some examples of some recent large and complex IT offshore projects –
Like Recent ABN Amro Deal, GM Deal etc., and explain the complexity
involved in it.
7. Case study of some IT company handling it and the industry practices
Analysis
1. Compare Indian IT Company with MNC. How we handle these projects
2. Why do complex and large projects fail?
3. What are the new set of challenges in handling these projects
4. What are the ways to manage these projects
5. Key concern areas pricing, man power planning, communication, quality
control , relationships etc in these projects
6. Tools and Methodology that are being used to handle large and complex
projects
16

17. Dissertation Methodology
The study has been carried out in two phases for gathering information and
analyzing the same. They are as follows:
 Secondary Research
The secondary research includes gathering information from
articles, business magazines, newspaper, books, online articles and journals.
 Primary Research
The primary research has been carried out through field visit
where the information has been gathered from eminent professionals from the
Industry who are exposed to the similar situation thereby understanding the hard core
facts for substantiating my secondary information.
17

18. Introduction
Most experts today agree that complexity is a major feature of computer
software, and will increasingly be so in the future. Some even states that computer
programs are the most complex entities among human products (Brooks, 1995). But
what is software complexity? From where does it originate? What are the apparent
effects of it?
When studying the literature about the concept software complexity one is
struck by the fact that there is not much work done about the origins and nature of
software complexity. Almost all attention has been given to which effects it has on
software projects, above all the costs and quality of the product. This is a natural
development, since the incentive to care about software complexity is derived from
the need of software project managers and engineers to control and predict project
productivity and quality, as we discussed in the earlier chapters. However, to be able
to better understand how the complexity influences other attributes of software
projects, we will explain how complexity is created and what it is made up of.
Software Complexity could be anything like Budgeting, pricing, manpower
planning etc., in need not to be a programming or technology complexity. When the
both the size and scale of the software projects increase the complexity of managing
them would also increase. We need to be well equipped with the best in class
processes and methodology for managing these projects thereby not affecting the
productivity and quality of the project.
Before we understand the practices and issues related to handling the complex
and large projects let us first define them for further clarification.
18

19. What is Complexity?
What do we mean by complex software projects? How do we quantify them?
Complexity is a measure of the resources which must be expanded in developing,
maintaining, or using a software product. Software complexity is the degree of
difficulty in analyzing, maintaining, testing, designing and modifying software
Types of Software Complexity
With this basis it could be expected that different types of complexity are
created during each stage of the product life cycle. Hence, we are suggesting a two
fold classification of complexity:
 Complexity of the problem, which is the inherent complexity, created
during the requirements phase
 Complexity of solution, which is the complexity being attached to the
complexity of the problem. This type of complexity is added during the
development stages following the requirements phase, primarily during
the designing and coding phases.
Another way to look at software complexity is to see it as the resources
needed for the project, or the efficiency of the project. With this approach, the
complexity of a problem can be defined as the amount of resources required for an
optimal solution of the problem. Then complexity of a solution can be regarded in
terms of the resources needed to implement a particular solution. These resources
have at least two aspects: time, i.e. computer time and man-hours, and space, i.e.
computer memory.
The complexity is strongly connected to the amount of resources needed in a
project is something that is stated by most of the researchers of software metrics
(Jones, 1996; Fenton & Pfleeger, 1996; Möller & Paulish, 1993; Goodman, 1993;
19

20. Grady, 1992). The notion is that a more complex problem or solution is demanding
more resources from the project, in form of man-hours, computer time, support
software etc.
A large share of the resources is used to find errors, debug, and retest; thus, an
associated measure of complexity is the number of software errors. But since the
solution that is more complex than another is more likely to need a larger amount of
effort, the notion of complexity is naturally bound to the concept of size. We think
that by examining these relationships, firstly between complexity and size and
secondly between complexity and number of errors, we can also understand how
complexity is connected to productivity and quality.
We have already recognized that there are many categories of software
complexity, but that it is hard to combine all these categories in one overall measure
of complexity. Rather, the approach is to interpret complexity in different ways, and
then try to build a model of how these different aspects of complexity is influencing
productivity and quality (we will come back to this later in the chapter). In that case,
how are we going to properly define software complexity? Based on the literature
(Fenton & Pfleeger, 1996; Zuse, 1991; Ohlsson, 1996) we would like to suggest that
software complexity is made up of the following parts:
1. Problem Complexity (which is also called computational) measures the complexity
of the underlying problem. This type of complexity can be traced back to the
requirements phase, when the problem is defined. If the problem can be described
with algorithms and functions it is also possible to compare different problems with
each other, and try to state which problem is the most complex.
2. Algorithmic complexity reflects the complexity of the algorithm implemented to
solve the problem. This is where the notion of efficiency is applied. By
experimentally comparing different algorithms we can establish which algorithm
gives the most efficient solution to the problem, and thus has the lowest degree of
added complexity. This type of complexity is measurable as soon as an algorithm of a
solution is created, usually during the design phase. However, historically algorithmic
20

21. complexity has been measured on code, where the mathematical structure is more
apparent.
3. Structural complexity measures the structure of the software used to implement the
algorithm. Practitioners and researchers have recognized for a long time that there
may be a link between the structure of the products and their quality. In other words,
the structure of requirements, design, and code may help us to understand the
difficulty we sometimes have in converting one product to another (as, for example,
implementing a design as a code), in testing a product (as in testing code or validating
requirements, for instance) or in predicting external software attributes from early
product measures.
4. Cognitive complexity measures the effort required to understand the software. It
has to do with the psychological perception or the relative difficulty of undertaking or
completing a system. However, since this aspect of complexity is more an object of
study for the social scientists and psychologists, we are not considering it in this
report. Nonetheless, it is important to notice that the human mind is a constraint for
the software process, and that it influences the attributes of the software we want to
measure, such as quality and productivity.
Algorithmic and structural complexity (together with cognitive complexity)
can be used to measure the complexity of a solution and especially the added
complexity. Problem complexity is instead directly connected to the complexity that
is generated by the originally requirements.
Therefore, it is obvious that the aspects of complexity that are measurable
during the software development process are algorithmic and structural complexity.
But measuring the problem complexity is also of interest to us when we want to
predict the effort or resources needed for a specific project. By comparing new
problems with old ones and considering the effects of the solutions to the old
problems, we are able to predict the attributes of the solution to the new problem,
such as cost, fault density, size etc.
21

22. Domain complexity is directly created by the application domain or the
problem space. If we are writing the software for launching rockets, we need some
basics in rocket science. Domain complexity cannot be really avoided.
Scale complexity is induced by size or other scaling considerations. From a
size perspective, software is now one of the most complex, if not the most complex
forms of engineering. Any piece of software today involves millions of bits
interacting precisely in tens or hundreds of physical components (multiple computers,
CPUs, graphic cards, memory, networking components, timers, sensors, actuators, to
cite a few). Most performance issues are a particular form of scale complexity, related
to the passage of time. In that area too, software engineers need to pay attention to an
unusually wide range of time scales, from nanoseconds when dealing with individual
computing components up to multiple years when dealing with software maintenance
or high availability software.
Business complexity is introduced by constraints on the business environment:
budget, team size, time-to-market, ill-defined requirements, etc. These considerations
are not generally under control of software methodologies. Yet best practices improve
the efficiency of engineers, which in turn allow them to meet higher demands.
Execution Complexity
One of the major requirements of the clients in outsourcing a project would be
an effective minimum delivery models and client management. Depending on the
project, client’s interest, technology and the level of technology involved the delivery
model is selecting.
Complex projects with different technology involved will fall under different
delivery methodology. For each of these methodologies there is some level of
complexity involved in it.
1. Onsite Delivery Model – Where the vendor undergo the software development
process in the clients country.
22

23. 2. Onsite- Offsite Delivery Model – In this model, initially 80% of the project
activities would be carried out in Onsite and 20% in Offsite. During this phase
the knowledge transferring takes place. After some time once the project being
completely elaborated the development will take place in offsite (80%)
3. Near Shore Delivery Model – Where the client opens a development center
near the clients’ presence thereby servicing from more than one or two clients
from the near by location. Example: TCS’s Center in China will cater to the
clients in the near by region
4. Network Delivery Model – The development process will take place in two to
three places and the integration is done in another location.
23

24. Why is Software Complexity Important?
Software complexity is aimed to objectively associate a number with a
program, based on the degree of presence or absence of certain characteristics of
software. It is assumed that software complexity is related with such features of
software like number of errors left in the software, effort to design, test or maintain a
software product, development time, maintenance cost, etc. The importance of
software complexity lies in the fact that knowing the complexity of a specific
software product or its module enables one to:
1. Predict the cost of testing, maintenance, etc., number of errors left in the
software , size of the final program;
2. Assess the development time, effort, cost, etc.;
3. Identify critical modules or parts of the software;
4. Compare programs, modules, programmers, etc. according to software
complexity.
24

25. Complex Modeling Structure
Figure 1: Complex Model
25

26. What do we mean by Large Projects?
Every organization has now realized the need for optimizing and automating
their business process as a result of competitive landscape that is prevalent in almost
every Industry. Organization should think fast in streamlining their processes for
creating an effective knowledge base around the system. Having said this, companies
depending on their size have decided to outsource their IT to vendors who can
manage, execute and delivery effectively.
On what basis we calculate a project as small or large:
 The size of the outsourcing company
Size of the outsourcing company matters in terms of deciding the size of
the project. The company may operate in different countries and location and also
the size of the business that they currently have. These factors decide the size of
the project in terms of scope and modules involved in it.
Example: A bank like ICICI will have presence almost in every part of
India. If we take in account the number of branches, amount of loans and accounts
being processed in a day or a week would be large than small banks.
 Number of man-months required
Project size is directly proportional to the efforts put in the project. For
estimating any project the man years is calculated for arriving at cost. Man months
also needed for effectively planning the project.
26

27.  Scope of the project
Scope of the project also decides the size. When the scope is
large the project also bound to be large. Increase in scope also increases the
number of stakeholders which will increase the size and the efforts put in the
project.
 Number of business functions
Business functions/ processes included in the project also decide
the size. For example if a company decides to implement ERP that includes
various business functions then the size of the project would be large.
 Software Project type
Different type of software project requires different process
capabilities and methodology. System Integration project would be more complex and
larger than application development and maintenance project. At the same time
Infrastructure management projects would be more complex and large in nature as
compared to System Integration
 Different types and level of technology involved
A software project that has diverse range of technology and
their integration would reflect the effort required for executing the same.
27

28.  Layers of Architecture
The increase in the number of layers would increase the effort of
the project in designing and development
 Reusability – Generic nature of the project
Reusability plays a major role in the project size. For a software
product, reusability takes in account the general requirements of the client from
different industries.
Implications of Large project:
 Multi geographical spread of operations
 High level of management control
 Experienced management and leadership
 In-depth domain and functional knowledge
 A wide range of technology skills across multiple technologies and platforms
 Effective usage of robust tools and methodology.
 Architectures and designs that will endure the test of time
 Organizational focus and commitment
 Active participation of all stakeholders, including vendors
28

29. Software Estimation
The four basic steps in software project estimation are:
1) Estimate the size of the development product. This generally ends up in either
Lines of Code
(LOC) or Function Points (FP), but there are other possible units of measure. A
discussion of the pros & cons of each is discussed in some of the material referenced
at the end of this report.
2) Estimate the effort in person-months or person-hours.
3) Estimate the schedule in calendar months.
4) Estimate the project cost in dollars (or local currency)
Estimating size
An accurate estimate of the size of the software to be built is the first step
to an effective estimate. The source(s) of information regarding the scope of the
project should, wherever possible, start with formal descriptions of the requirements -
for example, a customer’s requirements specification or request for proposal, a system
specification, a software requirements specification. If we are [re-]estimating a project
in later phases of the project’s lifecycle, design documents can be used to provide
additional detail. Don’t let the lack of a formal scope specification stop us from doing
an initial project estimate. A verbal description or a whiteboard outline is sometimes
all we have to start with. In any case, we must communicate the level of risk and
uncertainty in an estimate to all concerned and we must re-estimate the project as
soon as more scope information is determined.
29

30. Two main ways to estimate product size are:
1) By analogy. Having done a similar project in the past and knowing its size, we
estimate each major piece of the new project as a percentage of the size of a similar
piece of the previous project.
Estimate the total size of the new project by adding up the estimated sizes of each of
the pieces. An experienced estimator can produce reasonably good size estimates by
analogy if accurate size values are available for the previous project and if the new
project is sufficiently similar to the previous one.
2) By counting product features and using an algorithmic approach such as Function
Points to convert the count into an estimate of size. Macro-level “product features”
may include the number of subsystems, classes/modules, methods/functions. More
detailed “product features” may include the number of screens, dialogs, files, database
tables, reports, messages, and so on.
Estimating effort
Once we have an estimate of the size of the product, we can derive the
effort estimate. This conversion from software size to total project effort can only be
done if we have a defined software development lifecycle and development process
that we follow to specify, design, develop, and test the software. A software
development project involves far more than simply coding the software – in fact,
coding is often the smallest part of the overall effort. Writing and reviewing
documentation, implementing prototypes, designing the deliverables, and reviewing
and testing the code take up the larger portion of overall project effort. The project
effort estimate requires we to identify and estimate, and then sum up all the activities
we must perform to build a product of the estimated size.
30

31. There are two main ways to derive effort from size:
1) The best way is to use the organization’s own historical data to determine how
much effort previous projects of the estimated size have taken. This, of course,
assumes (a) the organization has been documenting actual results from previous
projects, (b) that we have at least one past project of similar size (it is even better if
we have several projects of similar size as this reinforces that we consistently need a
certain level of effort to develop projects of a given size), and (c) that we will follow a
similar development lifecycle, use a similar development methodology, use similar
tools, and use a team with similar skills and experience for the new project.
2) If we don’t have historical data from the own organization because we haven’t
started collecting it yet or because the new project is very different in one or more key
aspects, we can use a mature and generally accepted algorithmic approach such as
Barry Boehm’s COCOMO model or the Putnam Methodology to convert a size
estimate into an effort estimate. These models have been derived by studying a
significant number of completed projects from various organizations to see how their
project sizes mapped into total project effort. These “industry data” models may not
be as accurate as the own historical data, but they can give we useful ballpark effort
estimates.
Estimating schedule
The third step in estimating a software development project is to determine
the project schedule from the effort estimate. This generally involves estimating the
number of people who will work on the project, what they will work on (the Work
Breakdown Structure), when they will start working on the project and when they will
finish (this is the “staffing profile”). Once we have this information, we need to lay it
out into a calendar schedule. Again, historical data from the organization’s past
projects or industry data models can be used to predict the number of people we will
need for a project of a given size and how work can be broken down into a schedule.
31

32. If we have nothing else, a schedule estimation rule of thumb [McConnell
1996] can be used to get a rough idea of the total calendar time required:
Schedule in months = 3.0 * (effort-months) 1/3
Opinions vary as to whether 2.0 or 2.5 or even 4.0 should be used in place of the 3.0
value – only by trying it out will we see what works for we.
Estimating Cost
There are many factors to consider when estimating the total cost of a project.
These include labor, hardware and software purchases or rentals, travel for meeting or
testing purposes, telecommunications (e.g., long distance phone calls, video-
conferences, dedicated lines for testing, etc.), training courses, office space, and so on.
Exactly how we estimate total project cost will depend on how the
organization allocates costs. Some costs may not be allocated to individual projects
and may be taken care of by adding an overhead value to labor rates ($ per hour).
Often, a software development project manager will only estimate the labor cost and
identify any additional project costs not considered “overhead” by the organization.
The simplest labor cost can be obtained by multiplying the project’s effort
estimate (in hour) by a general labor rate ($ per hour). A more accurate labor cost
would result from using a specific labor rate for each staff position (e.g., Technical,
QA, Project Management, Documentation, Support, etc.). We would have to
determine what percentage of total project effort should be allocated to each position.
Again, historical data or industry data models can help.
32

33. Prerequisite for handling large Projects:
 Finely-honed project management skills and expertise, with proven
methodologies and tools, and an experienced team of consultants
 Proven track record in delivering cost-effective turnkey solutions of the
highest quality across diverse industries, across the globe, on schedule
and within the budgeted cost.
 A large pool of skilled and experienced professionals drawn from
diverse areas, ranging from systems and software technology to specific
industry domains and business practices
 World-class development centres with multi-platform competencies
 Use of automation tools during the entire development life cycle,
enabling greater productivity and assuring quality
 SEI-CMM Level 5- and ISO 9001-certified process frameworks and
methodologies
 A partnership approach to the management and execution of projects,
ensuring a mutual alignment of goals
 Transparency and involvement of the client at all stages to continuously
reinforce the partnership, mutual agreement and shared progress
towards successful completion of the project.
 Knowledge transfer to the client at all intermediate milestones
throughout the project lifecycle, resulting in greater client understanding
and a smooth rollout
33

34.  A proven and mature onsite-offshore methodology to meet the ever-
shortening time-to-market expectations
 Adoption of a pre-acceptance testing phase before final delivery to the
client site, which establishes a level of client comfort and reduces the
timeframe for onsite
Does Large Projects Always Complex and Vice Versa?
Table 2: Large and Complex matrix
Highly experienced projects
where the size is big but
understanding is more. Example
up gradation of Windows XP to
Longhorn.
Projects like large scale application
development, banking products etc.
which includes more man years and
diverse range of technology
Small scale development
projects like website designing,
with less number of modules and
integration.
Technology based projects.
Example: projects in Artificial
Intelligence might require less man
months but the level of complexity
is high
34
P
R
O
J
E
C
T
S
I
Z
E
Large
Small
Low High

35. Large and high level of complexity
 Large scope management
 Multi location delivery
 Multi System Environment
Small and high level of complexity
 High level of technology usage
 Lack of understanding of business requirements from clients
 More stakeholders would lead to confusion even if the size of the project is
small
Large and Low level of complexity
 Highly experienced management team
 Better understanding of the requirements
35
C O M P L E X I T Y L E V E L

36. Small and low level of complexity
 Less number of modules and integration
 Less number of stakeholders
 Less man months required
 Low level application development and maintenance projects
36

37. Software Project Types and their Complexity levels
Figure 2: Value Pyramid
Application Development, Maintenance, Support & Enhancement
Though certain application development projects are complex but when
compared to other project types it is less complex.
Here the complexities are:
37
Application Development, Maintenance, Support & Enhancement
System Integration and Package Implementation
Infrastructure Management & BPO
Asset/ Product
Management
V
A
L
U
E
C
H
A
I
N
C
O
M
P
L
E
X
I
T
Y

38. 1. Level of technology being used
2. Multiple location development
3. Manpower planning
System Integration and Package Implementation
System Integration projects involve in dealing with two or more systems and
their integration points. In this type of software projects, two or more systems are
integrated to provide a single set of solutions. These types of projects heavily rely on
seamless integration of the system and their understanding. Before we discuss the
level of complexity let us analyze the characteristic of System Integration projects.
Complexity of System Implementation projects:
 More man years required
 High level of system analysis needed
 High level of expertise
 Proper alignment of different product functionalities
 Testing Complexity – Need to undergo high level of Integration testing for
ensuring the reliability and accuracy of the system.
How to Manage:
 Prepare a project plan for a systems integration project
 Identify technical and managerial challenges associated with systems
integration projects
 Establish an effective systems integration team
 Select and use performance metrics
 Manage the development and implementation of a systems integration project
 Establish an effective test environment
 Work effectively with subcontractors and suppliers
 Monitor and control a systems integration project
38

39.  Close a project and document lessons learned
Infrastructure Management & BPO
Infrastructure management includes the IT asset like Data center, server etc
which combines with the people and technology for effective Information
management System. The following are the component of Infrastructure management:
• Server and storage management - complete management of the multi vendor
IT environment, from implementation to backup to recovery
• Managed web services - secure, performance-tuned management of the
Internet-connected web servers
• Networks and operations management - flexible, secure operations of the
WAN, LAN, e-commerce connectivity, and associated services
• Datacenter management - advances access, transport, and performance
monitoring services provided at the site or at the telecom-secure facilities
worldwide
• Security management - proven firewall, anti-virus, authentication, and
intrusion detection services across the enterprise
The level of complexity in these kinds of projects is high because these
are business critical processes which heed high level of consulting experience.
These projects need more cost and implementation effort.
Indian IT companies are not bidding for these 1 to 3 billion USD
because of the impact in their operating margin. They would incur more cost
and the return would be long term. In order to handle these kinds of projects
they need some financial restructuring.
39

40. Asset/ Product Management
The buzz in the Indian software services industry is about ‘moving up the
value chain’ by doing it the product way. But companies are practicing just the
reverse and setting up call centers. These are two opposite direction of value chain.
There is nothing wrong or right in either direction of value chain, as long as it makes a
business proposition. But it calls for an introspection of where we want to be as brand
‘India’. The success of Indian software companies hinges on their ability to tackle
various challenges faced through a well-planned strategic framework.
The high end of the value chain i.e. the products require high amount of
technical and marketing expertise and is a high risk, high return game. Today
Microsoft in office soft wares, Oracle in databases and Adobe in publishing software
are the strong brands and command the ‘top of the mind’ recall. None of the Indian
product can be thought of to command that recognition level. That is not only because
of size, skills and scope of the Indian companies, but also the strategy and strength
(weakness) of the IT companies. Indian companies leveraging on the ‘low cost’
proposition created a big market for themselves. But yesterday’s business wisdom
cannot be taken as maxim for tomorrow’s transforming markets, especially in
technology domains. The need of the hour is to continuously build up the capabilities
and move from ‘low cost’ model to ‘premium product’ model. Here ‘premium
product’ signifies the association of complete skill sets and resources for commanding
premium ness and demand for the product. The high profit margins earned along with
the long term brand building are the chief advantages of the product strategy. Few
Indian brands like Marshall of Ramco, Finnacle of Infosys are there but are restricted
to enterprise segment and hence are unable to build consumer level ‘brand
awareness’.
Despite rapid growth and having many cost-related and technical advantages
in software sector the share of Indian software products and services in the global
40

41. market is around 1 % and has stagnated there for quite some time. This indicates that
the global market is expanding at a much faster rate than the capability of Indian
software market to cater to. In this scenario the ‘Product Way’ offers huge
opportunities and challenges for the Indian software industry.
Challenges in software product marketing:
• Visualsoft fails to deliver on product model and to switches to solutions model
• i-flex’s Flexcube is world's second largest selling wholesale back office
banking solution
• Products account for 7 percent of TCS' revenue, and 5 percent of Infosys’
• Share of products in the India’s software exports is less than 5%
Above facts give a conflicting picture of what is the Indian software product
scenario? It surely is conflicting and confusing, if the issues pertaining to it are not
understood and further a clear strategic focus is absent. So what are challenges faced
in making a successful product?
• R&D: The development of software involves broadly the following stages:
requirement specification, prototyping, designing, coding, testing and
maintenance. While the first few stages call for highly skilled manpower, skill
requirement is relatively low in the later stages and that is where Indian
companies are operating. The challenges and opportunities lie in the higher
skills levels of requirement analysis and designing which call for domain
expertise to be clubbed with the leading edge technologies through the
research and development investments. Thus its moving from low skills based
maintenance jobs to high knowledge based development. The product
development is also leads to earning intellectual property rights and hence
offers long term earning potential.
41

42. • Marketing & distribution: The nemesis of Indian companies has been their
inability to go beyond ‘contract rate’ based competition. Today companies are
finding it increasingly important that billing rates are under continuous
pressure and it is expected to get more severe in the days to come. It is a
natural business phase of maturity that Indian software industry is entering
into. This is the time for the companies to recognize and reorganize their
strengths and invest in sales and marketing strategies. The bottom-line is that
the transition has to take from provider of commoditized contract labor
services to product / brand led solutions consultants.
• IPR protection & Licensing: Of the various options by which the
international product market can be captured, licensing has emerged as the
most preferred way. This is because it offers small but continuous returns for a
long term, protects the Intellectual Property Rights (IPR) and quicker to sell
for the small/new company. The other options of joint ventures and FDI are
difficult in the initial stages of business because of the risks and investments
involved.
• Domain expertise: Flexcube traces its history back to another Citibank
product, to which i-flex gave a complete facelift. The Citibank legacy helped
i-flex gain immense knowledge. The industry domain knowledge can make or
break the product. Here the business analyst plays a critical role in guiding the
development directions for the software coders. Apart from the business
knowledge of the industry or functions the ability to analyze exceptions and
scenarios is very important. This is required to bring in scalability and
flexibility in the system without losing the rigor.
42

43. • Technological prowess: Ultimately it’s the software product and hence the
technological prowess is indispensable. The relationship between the front-end
ease and back-end complexity is directly proportional, i.e. as the user-
friendliness increases the complexities at the back-end also increases. Also the
functionality has to be balanced against back-end complexities and front-end
ease. This brings creates a scenario of finding the optimum mix of
functionality, ease and technological prowess.
Figure 3: Software product Market Strategies
The above discussed challenges have following strategic options given as a
framework:
• Develop predictability of business
This is the ability to manage paradox. Technology is highly evolving and hence
finding the business predictability for a software product is a challenge. Also if the
business opportunity is highly predictable than the number of competitors both
existing and new will make the situation highly competitive. But the business
predictability is a risk management strategy.
43

44. For example the latest buzzword for Indian IT companies is BPO-Business
Process Outsourcing. Now how is product related to BPO? It makes a highly
profitable and predictable opportunity, by simply processing on one’s own product.
This is precisely what is done by Kale Consultants, which processes airlines revenue
accounting on its own product RevERA. Here the Business profitability has to be
linked with the technology management, forecasting and risk assessment. A detailed
analysis is required of various scenarios and its impact because of technology and
business dynamism has to be conducted.
• Productizing Services
This strategy is more about moving up the value chain by climbing the
learning curve. As most of the software companies are providing the maintenance and
development services, which give them a considerable knowledge about the industry
processes. They can leverage on these experiences to create a product. Here the
flexibility of the product is important and hence the client relationships allow for a
cushion to learn, test and implement new ideas. A successful product this way
establishes a ‘champion account’ and hence a strong reference to new prospects. It
works as a waterfall effect where one reference client gives opportunity to win new
clients.
Basically it’s a win-win situation of joint developmental efforts. The existing
services clients serve as a risk mitigation strategy in two ways. One by generating
certain minimum sales volume and secondly it reduces some developmental
costs/investments which are lost in experiments. The result is a most optimum product
which is high quality, low cost and quick to market.
• Leveraging external resources
The product success is dependent on the company’s ability to invest in R&D
and marketing, while controlling the costs. Thus the ability to leverage external
restheces for reduced time to market and lower cost structure becomes an important
strategic decision. This can be done by going for alliances or outsourcing. Company
44

45. can go for outsourcing of development work etc. when it is confident of making a
high decibel sales and marketing. This will allow the company to focus on its core
strength and get quality work from the outsourcing service providers in a cost
efficient manner. For example, if today Reliance develops a product for the petroleum
industry, its ability to market the product is unquestionable, while it can get the
product developed by third party. On the other hand alliances can be build on the
other end of capability spectrum to find the best fit for the partners. Here a Indian
company might lack the sales & marketing prowess, but has superior software
development capabilities, then a international alliance can be the best option. For
example, a company like Visualsoft should have worked upon building marketing
network through partnerships.
With the above understanding of challenges faced and the subsequent strategic moves,
the India Inc. can make a mark on the global software products market
45

46. How do we measure Complexity?
Structural Measures of Software Complexity
Types of structural measures
In the model of complexity we found that the link between software
complexity, size and productivity is not as simple and obvious as it seems. We would
like to assume, that, all other things being equal, a large module takes longer to
specify, design, code, and test than a small one. But we argued that also the structural
complexity by means of its effect on the error-proneness of the program is
determining the productivity level of the project. Thus, we must investigate
characteristics of product structure, and determine how they influence the outcomes
we seek. Now we focus primarily on code measures, but many of the concepts and
techniques that have been introduced here can also be used on other documents
produced during the product life cycle.
The notion of structural complexity can also be seen from different
viewpoints, each playing a different role. We can identify at least three different
aspects of structure
(Fenton & Pfleeger, 1996):
1. Control-flow structure
2. Data-flow structure
3. Data structure
The Control flow is concerned with the sequence in which instructions are
executed in a program. This aspect of structure takes into consideration the iterative
and looping nature of a program. Thus, whereas size counts an instruction only once,
control flows make more visible the fact that an instruction may be executed many
times as the program is actually run.
46

47. Data flow follows the trail of a data item as it is created or handled by a
program. Many times, the transactions applied to data are more complex than the
instructions that implement them; data-flow measures depict the behavior of the data
as it interacts with the program.
Data Structure is the organization of the data itself, independent of the
program. When data elements are arranged as lists, queues, stacks, or other well-
defined structures, the algorithms for creating, modifying, or deleting them are more
likely to be well-defined, too. So the structure of the data tells us a great deal about
the difficulty involved in writing programs to handle the data, and in defining test
cases for verifying that the programs are correct. Sometimes a program is complex
due to a complex data structure rather than complex control or data flow.
Lines of Code
Counting lines of code is the most traditional method for measuring software
size. It is a quick method that can be performed with automated tools. This is one
reason why counting lines of code has been so widespread among software
development companies, despite of the limitations of the measure. We have recently
talked about algorithmic complexity and that it is the track of the complexity model
that handles size and effort. Counting lines of code is however a pure quantitative
measure and it does not consider algorithmic complexity at all. This method is so
commonly known though, and is for this reason needed as a historical background for
later discussion of alternative size measures.
Since the actual counting is made on code, the possibilities for estimating
software size early in the project are often small. If management lacks information
about the size of the program, they have difficulties to estimate development costs. A
desirable feature should be to know how much one line of code costs, and how many
lines of code the specific program requires. In the economic sense lines of code are
neither goods nor services. A customer does not know how many lines of code that
exist in a software product and can therefore not buy lines of codes directly.
47

48. Another restriction for using Lines of Code is the language dependency. To be
able to compare software products with measures of lines of code they must be coded
in the same language. When developing software in a homogenous environment that
is not a problem. But today almost every software project uses a mixture of languages.
Comparison between a mixed language product and another product coded strictly in
COBOL for example is not accurate when counting lines of code. We also face the
problem of size variations that are due to individual programming style. A minor
controlled study carried out by IBM illustrated that code size varied due to the styles
of the programmers and their interpretations of what the specifications asked for
(Jones, 1996). Since there is no standard of how to measure lines of code the ability to
compare industry data is limited. Every company may have their own internal rules of
how to measure their products and projects. Questions could arise about if blank lines
count or comments. Should data declaration be included, and what happens if a
statement extends over several lines? Some guidelines have been published by
organizations like the Software Engineering Institute, but they still do not represent
any totally accepted standard.
48

49. Other serious deficiencies associated with Lines of Code
1. The lack of a national or international standard for a line of code metric that
encompasses all procedural languages.
2. Software can be produced by methods where entities such as lines of code are
totally irrelevant. Example: program generators, spreadsheets, graphic icons, reusable
modules of unknown size, and inheritance.
3. Lines of Code metrics paradoxically move backward as the level of the language
gets higher, so that the most powerful and advanced languages appear to be less
productive than the more primitive low-level languages. This is due to the equation of
productivity (Productivity = Size/Effort) which generates a lower productivity if the
size of the code decreases.
The ability to estimate size of software projects is of increasing interest for
most companies. Lines of Code fails with this approach as it can only be counted after
the application is coded. A final reason for not using LOC in studies of software
production costs is that it does not include the other deliverables of the product. As we
said in the introduction to counting lines of code, the metric do not consider
algorithmic complexity.
49

50. Function Points measurement
Function Points can be used as a stand-alone metric to monitor the application
domain at a high level, or in combination with other measures to create a variety of
valuable software process performance and quality measures. Some of these measures
are considered to be normalized and therefore allowed for comparison among industry
segments. In the software measurement practice there are a commonly accepted set of
core metrics used in combination with Function Points: level of effort, costs, defects,
and duration. Together they result in commonly accepted industry measures as shown
in Table
Table 2: Functional Point Analysis
50

51. CASE STUDY
HP – Bank of India
The Business Challenge
Bank of India (BOI) was coming under competitive pressure from both public
and private sector banks, including multinationals that were going ahead with
"technology-enabled transformation." BOI wanted to move to the next level of IT-
enablement, that would give it the agility and adaptability required to function in a
dynamic market; in other words, begin the journey to being an Adaptive Enterprise. a
Core Banking System (CBS), making a paradigm shift from 'branch' automation to
'bank' automation, with the requirements being:
• Flexible, scalable and innovative technology infrastructure that will provide the
business agility to respond to the changing market dynamics
• A customer centric infrastructure that will enable bank to substantially increase
existing customer service levels with increased ability to attract new customers
The idea was to implement a system which also works to HP's benefit was its
partnerships with leading vendors and solution providers across domains. In the case
of BOI, HP's partnership with Infosys, on whose application the Core Banking
Solution is based, and Oracle whose products were used for the data warehousing
solution tipped the scales in HP's favor.
51

52. A solution that's truly first-of-its-kind
The contract awarded to HP by BOI is a first of its kind requirement
encompassing IT enabled transformation in a fully outsourced model. As part of this
transformation project, HP will take BOI further on the
Adaptive Enterprise roadmap by:
• Implementing and managing Core Banking Solution (CBS) across 750 identified
branches in India
• Implementing and managing Data Warehousing (DWH) and Document Imaging
solution
• Supplying and maintaining technology products like servers, desktops, printers, etc.
• Providing asset refresh/obsolescence protection for IT assets across 750 branches
• Building and managing a Data centre; co-locating and managing Disaster Recovery
centre
• Integrated channels management (tele-banking, internet banking, ATM, etc)
• Setting up and running help-desk and call centre for the Bank
• Managing IT infrastructure and CBS, DWH applications across 750 BOI branches
But the Bank believed that while transaction processing work processes and
supporting systems were necessary to success, these were not the bank's core
competencies. Hence they were on the lookout for a partner who would fulfill their IT
needs, now and in the future.
52

53. Best-of-breed partnerships for best-of-breed solutions
HP and Infosys – Giving customers the best of both worlds
An integral part of the Bank of India solution was Finacle from Infosys, the
universal banking solution from Infosys that empowers banks to transform their
business by leveraging technology. The solution addresses all the requirements of
universal, retail, corporate, community and private banks. A completely web-based,
centralised, multi-lingual, multi-currency solution, Finacle offers several powerful
and differentiating features making it one of the most comprehensive, flexible and
scalable solutions in its class.
Together HP and Infosys have demonstrated new standards in banking IT. In a
benchmarking exercise carried out jointly by HP and Infosys, the performance of
Finacle was tested using HP Integrity Superdome servers. The benchmark results
achieved were the highest in the industry compared to all other core banking
solutions. Running on HP servers, Finacle:
• Achieved the highest scalability and transactions throughput per second of 11,180
Delivery Channel
Transactions per second (TPS) in online mode
• Processed an average of 19,568 Term Deposit (TD) accounts per second
• Processed an average of 11,403 Saving Bank (SB) accounts per second
53

54. The HP-Oracle Partnership – Optimized for agility
HP partnered with Oracle for the BOI data warehousing solution. The leader
in data warehousing, Oracle delivers the best performance, scalability, and
manageability available today and simplifies the maintenance of an ever-expanding
data warehouse, while offering the world's fastest performance and lowest
price/performance.
The HP Adaptive Enterprise approach and its benefits
Deploying the HP solution, which aligns BOI's IT infrastructure with its
business objectives, will give BOI an unified customer view, aid scientific decision
making and result in a faster time-to-market. By outsourcing IT operations and
management, the Bank can now focus on core business activities for competitive
advantage. Reduction in the Total Cost of Ownership (TCO) of the project also
provides a high level of predictability on future cash flows.
The financial modelling undertaken as part of the project helps the bank
conserve capital, preserve existing credit lines, get tax advantages, eliminate endof-
useful life hassles and financial asset management; cost conversion from CAPEX to
OPEX for optimal return on investment.
54

55. Clients’ expectation from vendors for outsourcing Large
and Complex projects
Long term strategic relationship
By keeping in mind the complex nature of the software and their
corresponding level of support, clients always expect a long term strategic
relationship. Strategic relationship is suggesting a right IT implementation
strategy aligning it with the corporate strategy. Clients expect both IT and
Business Consulting from the vendor. Rather than managing relationship with
many vendors companies have decided to reduce their vendor management cost
by consolidating the vendors and increasing the contractual period for a long term.
For a software product which is more complex as compared to software
solutions clients need a complete set of support functions for a long term period.
This trend has made Indian IT company to think in terms of their delivery model.
For an example TCS has a flexible network global delivery model with inherent
consulting services helps the client to maintain a strong relationship with them.
Total guidance to the project
Clients expect total guidance for the project right from the business
proposal till the maintenance phase. Guidance is in terms of communication and
making clients aware of the each and every project tasks and planning in the life
cycle. Client management plays a pivotal role in assuring them about the
deliverables and the returns that they expect out of this project.
55

56. Client’s expectation should be properly managed and communicated
through risk mitigation and change management approach. This will assure them
about the vendor’s processes and capabilities.
Best in class process and Methodology
Maturity of the processes and methods reflect the vendor capability in
handling large and complex projects. Clients expect best in class processes and
effective methodology for executing a project.
Clear Budget Constraint
Clients want a clear budgeting plan. No cost overruns. When the size and
complexity of the project grows then the budgeting may be difficult. Clients do
not expect any delivery slippage or cost overrun in the project
Better delivery, quality and client management process
Better delivery models and quality process increases the reliability of the
software solutions/ products. Since large and Complex project directly affects the
productivity, performance and quality of a product it is must for a vendor to make
client aware of theses processes and the capabilities
56

57. Why do complex and large projects fail?
 Lack of clients interest
 Lack of documentation of minutes of meeting.
 Non identification of complex parts. Large project fails for not implementing
the complex part first.
 Lack of understanding of the clients requirement
 Lack of usage of effective project management tools and methodology
 Lack of focus and commitment
 Lack of co-ordination of resources and activities
 Lack of communication with interested parties, leading to products being
delivered which are not what the Customer wanted
 Poor estimation of duration and costs, leading to projects taking more time and
costing more money than expected
 Insufficient measurable
 Inadequate planning of resources, activities, and scheduling
 Lack of control over progress so that projects do not reveal their exact status
until too late
 Lack of quality control, resulting in the delivery of products that are
unacceptable or unusable.
Challenges in handling these projects
57

58.  Manpower planning
 Improvement of the level of education for better talent pool
 Effective management of clients relationship and expectation
 Language and cultural barriers
 Improvement in productivity, quality and performance
 Management of bandwidth of control
 Multi geography execution
 Usage of effective tools and methodology
Key Concern areas
Manpower planning
58

59. The Indian Software industry has been consistently growing at a rate of over
40% per year for the last many years. Though the total business done by the Indian
software industry is only about 2% of the global software business, the industry has
firmly established itself globally. World over, India is perceived as the destination for
getting software done, and Indian programmers and software engineers now enjoy a
much deserved reputation for developing good software. The key reason for this
success is that software is perhaps the only high technology area that is manpower
intensive, and we had a ready pool of well trained manpower.
There is no doubt that India has a great potential in software, now that its
reputation is firmly established. Even if the Indian software industry does not get into
the products market, the software services business being so large (approximately half
of the total global software business), there is a tremendous scope for further increase
for the next many years. India can become the place for majority of the software
services business. If we have a goal of capturing a large portion of the software
services business in the next decade, then by current figures, the software industry
will have a turnover of about $50 billion and will employ over one million engineers!
And this is an achievable target, given the size of business and growth potential. And
this is without considering the domestic market, which is also likely to grow rapidly
in future.
However, this potential is not likely to be realized. And the reason will lie in
the poor strategic planning for this industry. In a service industry, unlike the product
industry, there is room for many players. For achieving the kind of target mentioned
above, one would expect hundreds, if not thousands, of companies of different sizes,
operating at different levels of the value chain, such that collectively most of the
market is covered. If there are only a few big players, then it is quite likely that, in
order to maximize their own profits, they might move to higher value services,
leaving out the other work. If there are many software companies, then the services
left out by the bigger players can be picked up by the other companies.
However, given the current state of the manpower situation in India,
having a wide range of companies operating at different levels of value chain and
offering different services is not likely to materialize, unless drastic measures are
59

60. taken to handle the manpower situation. It is now a well known fact in the Indian
software industry that there is an acute shortage of software engineers being produced
by the educational institutions. The big companies have responded to this shortage by
setting their own internal training programs and taking engineers from various
disciplines and training them to become software engineers.
A small company, until it becomes relatively large, cannot afford to have
the overhead of a regular training department within the company. Small companies
rely on having a core of some very good people, who carry with them a larger group
of not-so-good people by training them on the job so that they can be productive. This
model will not work, given the shortage of manpower, as getting the very good core
will be very hard there are only a few very good people who are produced every year.
Even if this core can be formed, finding the rest of the people to support this core will
get harder every year. First, given the social background which urges individuals to
minimize risk at a personal level, most graduates, given a chance, will prefer to go to
a larger, more stable company, unless the work is better elsewhere. As most of the
companies are in the service business, work wise there is not much to distinguish
between them. Hence, the smaller companies will find it increasingly difficult to
attract decent graduates. Furthermore, the people they attract are much more likely to
leave within a year or two, once they acquire the necessary experience and skills and
become more marketable. The larger companies, due to their brand name, and the
paying capacity, will be easily able to attract these people away, not to mention the
companies in the US who are always on the lookout for experienced people. In this
kind of situation, the management and leaders in a smaller company will spend all
their mental energies in just trying to get manpower and retain them, instead of
strategizing about the future growth of the company.
One can say that the strategy smaller companies can adopt is to become niche
players, offering specialized services and excelling in them and thereby attracting
business in these segments. New companies may choose this strategy in future, or
might be forced to adopt some such method to distinguish themselves from the larger
competitors. However, here again, the shortage of manpower will hit. Developing
competencies in some specialized area requires dedicated people who will stay with
the organization. With the kind of mobility the shortage of software personnel has
60

61. generated, building a dedicated team which will develop competency in some area
will not work.
Let us get a feel for the numbers involved. The top 10 companies together
currently probably employ about 15000 engineers (assuming an average size of 1500
per company). To grow by 40% per year, these top 10 companies themselves will
require in the next two years another 15000 engineers, and in two more years after
that they will require another 30000, another 60000 in two years after that. Given their
organizational reach and the financial muscle, there is little doubt that they will get
the best of the engineering graduates. As the top 40 engineering colleges in India will
produce about 10000 graduates in all disciplines put together, it is easy to see that in
the next few years not only will anyone from these top schools who wishes to join the
software industry will be taken by the top 10 companies, other competent graduates
from other places will also be taken! A smaller company, with little training
infrastructure, has to get people who are already reasonably well trained so that it
does not have to invest much in training. In other words, smaller companies will need
to have graduates in computer science, MCA, and related disciplines. And the chances
of them getting these graduates in reasonable numbers is next to impossible!
So, we will see a shakeup in the near future in the software industry. A
dozen odd companies, who can attract the graduates with high salaries and their
image, will bear the torch of the Indian software industry. The rest of the companies,
unable to get suitable manpower, which is the basic resthece for running a software
company, will barely survive, or die, or will be taken over by the larger companies.
Perhaps countries like China will move in to capture that business. And if that
happens, they will soon start giving competition to even the big players in the Indian
software industry. So, it is even in the interests of the larger companies that smaller
companies, operating in different value and services segments, exist in India. For
achieving the goal of being a majority player in the global services market, it is
imperative that along with large companies, many smaller and medium sized
companies providing specialized services at different levels of the value chain exist.
61

62. If we want to achieve the kind of target discussed above, it is necessary that
there should be room for many new companies to come up and grow and operate in
different segments. This will necessarily require that the number of graduates
available for the software industry should increase dramatically so that the smaller
companies can attract a few good graduates and a reasonable number of average
graduates who have a reasonable education and experience to do their job. The current
education infrastructure in the country is woefully inadequate to meet this kind of
demand. The private diploma based programs that have mushroomed in the last many
years do not seem to inspire confidence. As these are businesses, their main goal is to
make money through training. Hence, they exercise little control over the quality of
inputs they take, almost everyone who goes in the program graduates, as they are not
in a position to fail a student who has paid to get the diploma. Proper training, which
is not colored by business, needs of the organization providing the training, can only
is provided by established Universities and Institutes, and these will need support and
incentives to produce manpower in the numbers that are needed. Unless the
government, the industry, and the academia get together and sort out together how
this kind of growth can be supported, there is little hope for smaller companies.
The need of the hthe is creative solutions for education distance education,
internet based education, computer based training, etc. so as to best leverage the
resthece that is in shorter supply than even the software engineers competent teaching
faculty. The current approach of setting some centers like IIITs in various parts of the
country are not likely to make any significant impact as they are not likely to get any
competent faculty, and the scale being viewed by these places is still small a couple
of hundred graduates a year. Any strategy to meet this demand must employ more
creative methods like distance education, TV based education, etc. so that skilled
manpower in large numbers can be created. These things are currently possible as the
technology is there and there are a large number of engineering graduates that are
produced in the country (each year a total of about 1.5 lakhs students graduate with
some engineering degree). Retraining these graduates through newer mediums of
education, using the best teaching restheces in the country, can start producing
dividends in a short time. This coupled with starting of new institutions, which have a
longer gestation period, will have a very favorable impact.
62

63. Thus it is important for software companies to implement an effective
manpower planning exercise for avoiding the man power shortage at time fo
executing large projects.
Cultural diversity
Every IT vendor should have an effective process to help them cope with the
cultural issues in a transition to the Global Delivery Model. They have to create the
process for managing cultural diversity. The process facilitates smooth functioning of
cross-partner teams. It promotes better understanding of work culture differences, and
awareness and appreciation of different cultural backgrounds.
The organizational impact of offshore and nearshore development leaves a
footprint on process orientation, collaborative working styles and project
management. IA Company’s processes should deal effectively with all three kinds of
change.
Company should conduct extensive cross-cultural training of staff at Infosys covering:
• cultural acclimatization,
• client business and organization overview,
• technical environment and processes specific to the client,
• creating non-intrusive interactions for the client
For example, Infosys has developed a unique 4-step Communications
Approach for strategic partners, by which we help the partners and the client-side staff
who will work with Infosys to:
• Understand the offshoring process,
• Understand their offshore partner
• Collaboratively improve project management skills
• Draw up a strategy for continuous process improvement
63

64. Figure 4: Cultural building
Communication
Communication is a very important aspect of project management. According
to PMI (Project Management Institute) 90% of project management is all about
communication. This is one of the key concern areas of any software company who
64

65. handles large and complex project. When the scale of operation or the project size
increases the project management would be complex and difficult. Here the project
communication plays an important role in this. Let see some of the project
communication activities during various phases of project management.
Relationship
In long-term relationships, the key component for success of the relationship is
best laid during negotiations, which lead up to the signing of the Service Level
Agreement. Some of the common practices employed for a successful management of
65
Figure 5: Communication Stages
Initiating
Processes
Initiating
Processes
Planning
Processes
Planning
Processes
Controlli
ng
Processes
Controlli
ng
Processes
Executin
g
Processes
Executin
g
Processes
Closing
Processes
Closing
Processes
Communication
Planning
Information
Distribution
Performance
Reporting
Administrative
Closure
View Project
Communication in
the context of the
five PM process
groups.

66. outsourcing relationship have been listed below. IT companies from countries like
India, are supporting such methods to improve their client relationship management.
1. Keeping relationship between key management personnel:
If there is a good understanding and strong working relationship between the
key management personnel of both teams, then such relationships often tends to last
long. Research on outsourcing success has indicated that peer friendships and working
methods with one's counterpart in the other company has been an important factor in
long term relationships.
Also maintaining one point of contact will avoid confusions. Companies can
keep one project manager per project or per client.
2. Well-defined criteria and Quantifiable objectives:
The objectives to be achieved by outsourcing must quantifiable and must be
established as criteria right at the start of the contract. If the customer can compare the
performance with the pre-established objective, then the benefits of outsourcing
would be clear. The vendor would know where they stand in meeting customer
expectations.
Well-defined performance criteria have quantifiable objectives, service
quantities, quality, and customer satisfaction are measurable against other providers.
3. Developing special board of members:
Successful outsourcing relationships involve setting up of special executive
committees or boards that draw out the best strategies for smooth & effective
66

67. handling of outsourcing relationship. Identification, resolution and rapid escalation of
issues are a key responsibility of this team.
By developing a team of people, companies can always do strategic meetings
on any plans, issues or to resolve conflicts.
4. Incentives and Penalties:
The provider is encouraged to meet or exceed customer expectations by
establishing performance based pricing. When performance exceeds the criteria, the
incentives apply and when they fall short, the penalties are imposed.
This will increase the understandings in payment, work commitments and help
both sides in long run to understand the work code better.
5. Periodical review meetings:
For a successful outsourcing relationship, it is better to have frequent formal
review meetings. These meetings can discuss what both teams are working towards
and a high level view of the future goals and objectives. Product reviews and
deliverables can be discussed at such meetings.
Staying away from the client, without updating will lead to much frustration at
the client side. Also if there is no periodical updates, chances are more to understand
the client requirements which leads to deviation from the requirement and can be
solved later only in a troublesome phase in both sides.
6. Training vendor personnel:
The vendor personnel need to have ongoing training so that they align their
business goals to the business objectives of the customer. The issues driving the
clients needs have to be understood and the vendors' service has to relate to them.
67

68. The training could be in management, technology or anything which can
improve the client relationship.
7. Understanding the cultural differences:
This is one area where countries like India need to concentrate. As both parties
to the outsourcing relationship will have their own culture, these differences have to
be recognized and bridged. Organizing social events, education on company
background, participation in others' quality programs, etc., are some of the ways to
improve the cultural understandings and bridging this gap.
Tools used For Managing Complex and Large Software
projects
Microsoft Project
68

69. Microsoft Project has become a de facto standard in many organizations
because it is inexpensive and easy to use. As the case with any tool, the results we get
are only as good as the process we use.
This part of the dissertation focuses on using Microsoft Project for large
projects. The emphasis for this part will be on implementing project control processes
while avoiding the hidden hazards that can occur because we use software tools that
seemingly make it so easy to plan and manage projects. This part focuses on
developing the schedule baseline.
Developing the Schedule Baseline
Microsoft Project's ease of use lures many into a false sense of security.
Suddenly, anyone with Microsoft Project at their fingertips becomes an immediate
project planning and scheduling expert. Just enter tasks and start manipulating the
data. How hard can it be?
This approach quickly leads down the path of ad hoc planning. The result? A
poorly defined project where no one knows what the end result is or what are we
supposed to do. And that means costly schedule and cost overruns for a project that
doesn't meet the customer's needs.
There are two distinct times in a project's life when the right planning is the
most critical: the project proposal and developing the project's schedule baseline.
Unfortunately, both of these events occur when time is of the essence and lots of
things are happening at once.
All too often when developing the schedule baseline, managers and work
teams focus on the technical details of the product and leave the cthese of events to
just sort of happen. While we clearly need to deliver a good product, it is even more
important to get it into the customer's hands. The bottom line cost figure is the driver.
And since time equals money, this means we need a realistic schedule. The time and
69

70. energy spent up front planning the project is as important, if not more, than
determining the technical aspects of the project.
A Better Approach
The key to successfully managing a large project, especially with Microsoft
Project, is to plan the project work - the Plan for the Plan.
What is the Plan for the Plan?
It describes the project structure - the way work will be performed with a
direct correlation to the way costs will be collected. It accurately reflects the best
estimate of task durations and clearly identifies task dependencies.
What elements comprise a proper plan for the plan?
 A clear definition of project objectives including all statement of work and
documented contractual items. These should be aligned to the way work will
be accomplished. Ideally, they match a well thought out work breakdown
structure (WBS).
 Reliable time estimates for the work to be done. If possible, document the
process or source used to determine the time estimates for the activities.
 Accurate and significant task dependencies. While it is impossible to list all
relationships, thought must be given to capture the ones that are the most
critical.
 Retain notes for everything. Should things change in the future, we will know
where to look for additional details.
How do we go about developing one?
It is my experience that there is only one good way to do this. Gather all
performers and stakeholders into a room fill it with drinks and food, remove all
phones and pagers, lock the doors, and get down to talking together, arguing, and
planning. Capture all thoughts on paper. Don't use any kind of automated tool - this
70

71. will actually slow we down. White boards, flip-chart paper, even index cards and
colored yarn all work well. This needs to be a real old-fashioned get down and dirty
working session. And as painful as it may seem, the more time spent here will pay
dividends for the life of the program.
What are the inputs to the process and who participates?
The working session needs to include all the decision makers, the people who
will be doing the work, the business team, and the scheduler. We will want to:
 Solicit the steps involved to perform the work,
 Identify relationships between tasks,
 Estimate the time required, and
 Identify the necessary resources to do the work.
Document this process in a way that can be viewed by everyone. For example,
we can use large writing on flip-chart paper hung on a wall. This allows for open and
frank discussions between all the players.
During the working session, it is imperative to keep the focus on a successful
program. Typically what happens when we fill a room with engineers is that the
discussion turns too technical and the thought process goes off on a tangent. This is
where we need someone with real planning experience. While some engineering
speak is inevitable, and in fact needed in the process, don't lose focus of the task at
hand: planning the work. We have to know when, and how, to reel everyone back in
and continue the planning process.
As we plan, issues will come up that need buy-in or concurrence from most, if
not all, stakeholders. We will want to solve it right then, rather than stopping and
starting, and losing momentum. Plus, it is highly likely that someone from an another
discipline will see things that the "expert" missed.
Who is responsible?
71

72. The ultimate responsibility lies with whoever is responsible for the project.
This ownership can be delegated down the same lines as the project work, but if we
want a good performing project, we must have a good plan. And plans are only as
good as the top-level managers force them to be.
Process Tips
In the planning session, first focus solely on WHAT needs to be done and
HOW it will be accomplished. Identify the tasks that need to be done and the
relationships they have to one another. Don't think about time spans or dates yet. This
will only bring the creative thinking to a screeching halt, as the focus will change.
Only after we feel we have the work defined and relationships accurately identified
should we go back through and apply times to the tasks.
Once we have identified the what, how, relationships, and how long, we are
now ready to start using Microsoft Project. Enter all the data including relationships.
Then calculate where we schedule needs to start and finish.
More than likely we will need to make some adjustments to fit time or
resource constraints. We will need to start working the issues with the owners. I have
found the best way to work these issues is with a good clear PERT type of chart. This
allows everyone to see the big picture and how small changes to specific tasks can
impact the overall project. Microsoft Project has limited graphics in this area. We may
want to consider using an add-on software package such as PERT Chart Expert from
PM Connect (www.pmconnect.com).
Common Mistakes
There are two typical mistakes people make in the planning process.
Mistake Number 1: Not enough detail
72

73. This happens when we try to keep things at a high level or at a level consistent
with the cost collection method. Or, we may want to show the customer one level and
keep the details internal to ourselves. At this level, we don't have the information we
need to adequately manage the project. The focus is on external requirements
(reporting, customer) rather than meeting our needs to manage the project.
Mistake Number 2: Too much detail
While this is generally not the case, it can be a problem if the project structure
is not thought out in advance. The project structure needs to reflect how work will be
performed and how project costs will be collected. If we are trying to collect cost at
the lowest schedule level, this could cause problems if the amount of data is
overwhelming and we need to constantly summarize data for analysis or reporting.
Understanding what information the various project stakeholders will need as
the project gets underway also helps. Managers, finance, accounting, and team
members all need a different view of the project data.
Potential land-mine: If we want to do high level what-ifs or summarize data
for reporting purposes, using Microsoft Project can be a constraint if not thought out
in advance. First have the plan structured correctly, and then use the summary levels
and indents to roll up the data for what-if exercises or reporting. We can also use code
structures such as a work breakdown structure for this purpose.
Gantt chart
Gantt Charts are useful tools for analyzing and planning more complex projects.
They:
• Help we to plan out the tasks that need to be completed
73

74. • Give we a basis for scheduling when these tasks will be carried out
• Allow we to plan the allocation of resources needed to complete the project,
and
Help we to work out the critical path for a project where we must complete it
by a particular date.
When a project is under way, Gantt charts help we to monitor whether the
project is on schedule. If it is not, it allows us to pinpoint the remedial action
necessary to put it back on schedule.
Sequential and parallel activities:
An essential concept behind project planning (and Critical Path Analysis) is
that some activities are dependent on other activities being completed first. As a
shallow example, it is not a good idea to start building a bridge before we have
designed it!
These dependent activities need to be completed in a sequence, with each
stage being more-or-less completed before the next activity can begin. We can call
dependent activities 'sequential'.
Other activities are not dependent on completion of any other tasks. These
may be done at any time before or after a particular stage is reached. These are
nondependent or 'parallel' tasks.
Drawing a Gantt chart
To draw up a Gantt chart, follow these steps:
1. List all activities in the plan
74

75. For each task, show the earliest start date, estimated length of time it will take,
and whether it is parallel or sequential. If tasks are sequential, show which stages they
depend on.
We will end up with a task list like the one in figure 1. This example shows
the task list for a custom-written computer project. We will use this same example for
both this section and the section on Critical Path Analysis and PERT. This will allow
we to compare the results of the two approaches.
Table 3: Gantt chart
Gantt chart Example: Planning a custom-written computer project
NB: The start week shows when restheces become available. Whether a task is
parallel or sequential depends largely on context.
Task possible
start
Length Type Dependent
on...
1. High level analysis week 1 5 days sequential
2. Selection of hardware
platform
week 1 1 day sequential 1
3. Installation and
commissioning of hardware
week 3 2
weeks
parallel 2
4. Detailed analysis of core
modules
week 1 2
weeks
sequential 1
5. Detailed analysis of
supporting utilities
week 1 2
weeks
sequential 4
6. Programming of core
modules
week 4 3
weeks
sequential 4
7. Programming of supporting
modules
week 4 3
weeks
sequential 5
8. Quality assurance of core
modules
week 5 1 week sequential 6
9. Quality assurance of
supporting modules
week 5 1 week sequential 7
10.Core module training week 7 1 day parallel 6
11.Development ofweek 6 1 week parallel 5
75

76. accounting reporting
12.Development of
management reporting
week 6 1 week parallel 5
13.Development of
management analysis
week 6 2
weeks
sequential 5
14.Detailed training week 7 1 week sequential 1-13
15.Documentation week 4 2
weeks
parallel 13
2. Head up graph paper with the days or weeks through to task completion
3. Plot the tasks onto the graph paper
Next draw up a rough draft of the Gantt Chart. Plot each task on the graph
paper, showing it starting on the earliest possible date. Draw it as a bar, with the
length of the bar being the length of the task. Above the task bars, mark the time taken
to complete them. Do not worry about task scheduling yet. All we are doing is setting
up the first draft of the analysis.
This will produce an untidy diagram like the one below:
Figure 6: Design Chart
76

77. 4. Schedule Activities
Now take the draft Gantt Chart, and use it to schedule actions. Schedule them
in such a way that sequential actions are carried out in the required sequence. Ensure
that dependent activities do not start until the activities they depend on have been
completed. Where possible, schedule parallel tasks so that they do not interfere with
sequential actions on the critical path. While scheduling, ensure that we make best use
of the restheces we have available, and do not over-commit resthece. Also allow some
slack time in the schedule for holdups, overruns, quality rejections, failures in
delivery, etc.
5. Presenting the Analysis
77

78. The final stage in this process is to prepare a final version of the Gantt
chart. This should combine the draft analysis (see above) with wer scheduling and
analysis of restheces. This chart will show when we anticipate that jobs should start
and finish.
A redrawn and scheduled version of the example project is shown below:
Figure 7: Critical Path Analysis
TCS’s MasterCraft
78

79. TCS has launched MasterCraft, a comprehensive software development tool
for the execution and management of large software development projects efficiently.
MasterCraft can automate the process of generation of code for large software
development projects running into millions of lines of code. This software automates
the design and construction functions in the software development process involving
generation of code. This enhances productivity by a factor of 4 to 5 compared to
manual coding, according to TCS. It is useful in complex application development
projects and makes the client free of obsolescent platforms. It is aimed at large
software companies, IT departments, insurance, finance and core sector companies
that need to cope with technology changes.
MasterCraft works across multiple platforms and technologies. It is
compatible over different hardware, operating system and database. It can work in C+
+, Java, Tuxedo, CICS, IBM mainframes, Windows NT, Linux and Solaris.
The global market is estimated to be about $ 5-8 billion for this type of
software and has about five large players. TCS terms it as the world's only industrial
strength component based object oriented development environment. A typical
installation of MasterCraft costs about $150,000.
TCS has been using this software in its projects over the last four to five years
and has now decided to package and sell it in the open market. TCS's CEO S.
Ramadurai explained that this move was to let even the competition use this product,
and gain a crucial market share first, rather than have to use the competitors' products
later.
Key Benefits
79

80. Faster development, better focus, platform-independence
MasterCraft adds significant value in every stage of the application
development, from design to construction, down to testing and deployment.
Applications developed with MasterCraft can be delivered significantly faster
than through conventional methods, with more consistency and quality, in a platform-
independent manner.
The benefits are proven, in development of complex applications for cross-
border insurance, securities trading and banking requirements in different parts of the
globe.
Actual time savings in development of large applications have been up to
50%.
Application developers and customers also benefit in other important ways:
• Development teams spread across geographies work on different aspects of
applications with better focus, communication and consistency.
• Components can be designed, built, tested and delivered in both a standalone and
integrated manner.
• Customers get platform-independent applications that can be maintained and
modified with great ease. Code generation is independent of the development
platform.
• Changes in business needs do not call for manual changing of code. Changes are
reflected as changes in models and generation of platform-targeted, efficient code is
left to MasterCraft.
80

81. As an integrated suite that covers the entire software development lifecycle,
MasterCraft Enterprise saves the time, money and effort involved in using separate
tools for different phases of application development
81

82. MasterCraft's Component Modeler (MasterCraft-CM)
MasterCraft's Component Modeler (MasterCraft-CM) provides a modeling
framework and repository for the entire software life cycle.
For the analysis phase, it offers visual modeling facilities using Unified
Modeling Language. MasterCraft-CM also provides meta-modeling capability:
Modelers can use pre-defined meta-models, extend them or define a new meta-model.
Rules can be written to validate models.
The multi-user repository is based on a client/server architecture with
Windows 95 clients and a UNIX server.
Other key features of MasterCraft-CM are:
 An ODBC compliant database that currently supports Oracle and Access
databases
 A configurable diagrammer
 A powerful browser, which allows the user to navigate/view the relationships
and properties of objects
 Comprehensive version management to manage different configurations of
models
 Scripting facility to access data in the repository and generate reports or code
from the models
 Facilities to export/import data in an industry standard CDIF format
 Security features to define users and passwords for configurations or
components
82

83.  A facility to store long binary/text data so that large text files as well as
graphical data can be stored in the repository
 Web publishing features to store models and reports as HTML files which can
be published on the intranet/internet
83

84. PRINCE2
Introduction
PRINCE was established in 1989 by CCTA (the Central Computer and
Telecommunications Agency), since renamed the OGC (the Office of Government
Commerce). The method was originally based on PROMPT, a project management
method created by Simpact Systems Ltd in 1975. PROMPT was adopted by CCTA in
1979 as the standard to be used for all Government information system projects.
When PRINCE was launched in 1989, it effectively superseded PROMPT within
Government projects. PRINCE remains in the public domain and copyright is retained
by the Crown. PRINCE is a registered trademark of OGC.
Why use a project management method?
Project failures are all too common - some make the headlines, the vast
majorities are quickly forgotten. The reasons for failure are wide and varied. Some
common causes are...
 Lack of co-ordination of resources and activities
 Lack of communication with interested parties, leading to products being
delivered which are not what the Customer wanted
 Poor estimation of duration and costs, leading to projects taking more time and
costing more money than expected
 Insufficient measurable
 Inadequate planning of resources, activities, and scheduling
 Lack of control over progress so that projects do not reveal their exact status
until too late
 Lack of quality control, resulting in the delivery of products that are
unacceptable or unusable.
84

85. Without a project management method, those who commission a project, those
who manage it and those who work on it will have different ideas about how things
should be organised and when the different aspects of the project will be completed.
Those involved will not be clear about how much responsibility, authority and
accountability they have and, as a result, there will often be confusion surrounding the
project. Without a project management method, projects are rarely completed on time
and within acceptable cost - this is especially true of large projects. A good project
management method will guide the project through a controlled, well-managed,
visible set of activities to achieve the desired results. PRINCE adopts the principles of
good project management to avoid the problems identified above and so helps to
achieve successful projects. These principles are...
 A project is a finite process with a definite start and end
 Projects always need to be managed in order to be successful
• For genuine commitment to the project, all parties must be clear about why
the project is needed, what it is intended to achieve, how the outcome is to be
achieved, and what their responsibilities are in that achievement.
What is PRINCE?
PRINCE (PRojects IN Controlled Environments) is a structured method for
85

86. effective project management. It is a de facto standard used extensively by the UK
Government and is widely recognized and used in the private sector, both in the UK
and internationally. PRINCE, the method, is in the public domain, offering non-
proprietarily best-practice guidance on project management. PRINCE is, however, a
registered trademark of OGC.
The key features of PRINCE are...
 Its focus on business justification
 A defined organization structure for the project management team
 Its product-based planning approach
 Its emphasis on dividing the project into manageable and controllable stages
 Its flexibility to be applied at a level appropriate to the project.
PRINCE2 is a process-based approach for project management providing an
easily tailored, and scaleable method for the management of all types of projects.
Each process is defined with its key inputs and outputs together with the specific
objectives to be achieved and activities to be carried out.
Figure 8: Prince2 Methodology
86

87. Methodology
Directing a Project (DP)
Directing a Project runs from the start-up of the project until its closure. This
process is aimed at the Project Board. The Project Board manages by exception,
87

88. monitors via reports and controls through a number of decision points.
The key processes for the Project Board break into four main areas:
 Initiation (starting the project off on the right foot)
 Stage boundaries (commitment of more resources after checking results so far)
 Ad hoc direction (monitoring progress, providing advice and guidance,
reacting to exception situations)
 Project closure (confirming the project outcome and controlled close).
This process does not cover the day-to-day activities of the Project Manager.
Starting up a Project (SU)
This is the first process in PRINCE. It is a pre-project process, designed to
ensure that the pre-requisites for initiating the project are in place. The process
expects the existence of a Project Mandate which defines in high level terms the
reason for the project and what outcome is sought. Starting up a Project should be
very short.
The work of the process is built around the production of three elements:
 Ensuring that the information required for the project team is available
 Designing and appointing the Project Management Team
 Creating the Initiation Stage Plan.
Initiating a Project (IP)
The objectives of Initiating a Project are to:
 Agree whether or not there is sufficient justification to proceed with the
project
 Establish a stable management basis on which to proceed
88

89.  Document and confirm that an acceptable Business Case exists for the project
 Ensure a firm and accepted foundation to the project prior to commencement
of the work
 Agree to the commitment of resources for the first stage of the project
 Enable and encourage the Project Board to take ownership of the project
 Provide the baseline for the decision-making processes required during the
project's life
 Ensure that the investment of time and effort required by the project is made
wisely, taking account of the risks to the project.
Managing Stage Boundaries (SB)
This process provides the Project Board with key decision points on whether
to continue with the project or not. The objectives of the process are to:
 Assure the Project Board that all deliverables planned in the current Stage Plan
have been completed as defined
 Provide the information needed for the Project Board to assess the continuing
viability of the project

 Provide the Project Board with information needed to approve the current
stage's completion and authorize the start of the next stage, together with its
delegated tolerance level
 Record any measurements or lessons which can help later stages of this project
and/or other projects.
Controlling a Stage (CS)
This process describes the monitoring and control activities of the
89

90. Project Manager involved in ensuring that a stage stays on course and reacts to
unexpected events. The process forms the core of the Project Manager's effort on
the project, being the process which handles day-to-day management of the
project. Throughout a stage there will be a cycle consisting of:
 Authorizing work to be done
 Gathering progress information about that work
 Watching for changes
 Reviewing the situation
 Reporting
 Taking any necessary corrective action.
This process covers these activities, together with the on-going work of risk
management and change control.
Managing Product Delivery (MP)
The objective of this process is to ensure that planned products are created and
delivered by:
 Making certain that work on products allocated to the team is effectively
authorized and agreed e accepting and checking Work Packages
 Ensuring that work conforms to the requirements of interfaces identified in the
Work Package
 Ensuring that the work is done
 Assessing work progress and forecasts regularly
 Ensuring that completed products meet quality criteria
90

91.  Obtaining approval for the completed products.
Closing a Project (CP)
The purpose of this process is to execute a controlled close to the project. The
process covers the Project Manager's work to wrap up the project either at its end or at
premature close. Most of the work is to prepare input to the Project Board to obtain its
confirmation that the project may close.
The objectives of Closing a Project are, therefore, to:
 Check the extent to which the objectives or aims set out in the Project
Initiation Document (PID) have been met
 Confirm the extent of the fulfilment of the Project Initiation Document (PID)
and the Customer's satisfaction with the deliverables
 Obtain formal acceptance of the deliverables
 Ensure to what extent all expected products have been handed over and
accepted by the Customer
 Confirm that maintenance and operation arrangements are in place (where
appropriate)
 Make any recommendations for follow-on actions
 Capture lessons resulting from the project and complete the Lessons Learned
Report
 Prepare an End Project Report
 Notify the host organization of the intention to disband the project
organization and resources.
Planning (PL)
Planning is a repeatable process, and plays an important role in other
processes, main ones being:
 Planning an Initiation Stage (SL16)
91

92.  Planning a Project (IP2)
 Planning a Stage (SB1)
 Producing an Exception Plan (SB6).
PRINCE provides a product-based start to the planning activity. It also
provides planning framework which can be applied to any type of project. This
involves:
 Establishing what products are needed
 Determining the sequence in which each product should be produced
 Defining the form and content of each product
 Resolving what activities are necessary for their creation and delivery.
Benefits of using PRINCE...
PRINCE provides benefits to the managers and directors of a project and to an
organization, through the controllable use of resources and the ability to manage
business and project risk more effectively.
PRINCE embodies established and proven best practice in project
management. It is widely recognized and understood, providing a common language
for all participants in a project. PRINCE encourages formal recognition of
92

93. responsibilities within a project and focuses on what a project is to deliver, why, when
and for whom. PRINCE provides projects with:
 A controlled and organized start, middle and end
 Regular reviews of progress against plan and against the Business Case
flexible decision points
 Automatic management control of any deviations from the plan
 The involvement of management and stakeholders at the right time and place
during the project
 Good communication channels between the project, project management, and
the rest of the organization.
Managers using PRINCE are able to...
 Establish terms of reference as a pre-requisite to the start of a project
 Use a defined structure for delegation, authority and communication
 Divide the project into manageable stages for more accurate planning
 Ensure resources commitment from management is part of any approval to
proceed
 Provide regular but brief management reports
 Keep meetings with management and stakeholders to a minimum but at the
vital points in the project.
 Those who will be directly involved with using the results of a project are able
to...
 Participate in all the decision-making on a project
 If desired, be fully involved in day-to-day progress
 Provide quality checks throughout the project and ensure their requirements
are being adequately satisfied.
93

94. For senior management PRINCE uses the 'management by exception' concept. They
are kept fully informed of the project status without having to attend regular, time-
consuming meetings.
Indian IT Vendors Vs Global MNCs
Table 4: Comparison table of Indian IT and Global IT giants
Indian IT Global MNCs
Not good in Communication Very Good in Communication
No Benchmark between Performers and
Non - performers
Benchmark between Performers and Non
– performers
Average Client Relationship
Management
Good Client Relationship Management
Narrow range of services End-to-end
Primarily US focused Global Outlook
Relationship with IT managers CIO/CEO level relationships
Limited brand recall Globally reputed brands
Looked upon as organization of Global talent pool with
Not very good presenters Good presenters
Not good in Infrastructure as compared to
MNCs
Very good in Infrastructure
Indian engineers diverse background
94

95. Indian IT Company’s Opportunities
Taking on the MNCs
There are many innovative measures adopted by MNCs which Indian software houses
might need to emulate in order to compete effectively. Here’s what some of the MNC
firms did right:
Accenture: It started providing system integration within the communication
and hi-tech areas. By standardising methodologies (Method One) and launching a
network of alliances (SAP), it was able to expand into other verticals like utilities and
energy. Deals on the lines of Accenture’s acquisition of ITT’s two divisions helped
the company expand the scope of its service lines.
Accenture also formed Avande with Microsoft to offer solutions on
Microsoft’s Enterprise Platform and Windows 2000. Microsoft contributes $385
million in cash to Avande. Under its programme called Network Alliances, Accenture
has an ongoing relationship with Ariba (e-marketplace solution), HP (imaging
solutions) and Siebel (CRM). The company has made over 70 venture investments
amounting to $200 million in firms like Blue Martini and SeeBeyond.
EDS: This giant invented outsourcing using IBM mainframes for Frito Lay.
Initially EDS worked with government clients (US Navy, US Federal Government)
and automotive companies (General Motors). Then it acquired A T Kearny and others
to move up the value chain and offer consulting services. The acquisitions also gave
the company an entry into the private sector. It has made 10 acquisitions in the last
three years.
95

96. CSC: This Company has conducted over 20 acquisitions in last three years. In
2001, acquisition revenues were $2.8 billion (IT Services, Combitech and Mynd). It
has also expanded geographically BHP IT in Australia and KPMG in France.
Global consortia:
EDS, IBM Global Services and PWC are working together on a 10-year $3
billion deal for UK’s social security system. This joint strategy can be adopted by
leading Indian vendors to collectively bid for a large project. However, Indian players
do not seem to be ready for such an arrangement.
Emulating the MNCs
There are two ways of looking at the presence of MNCs in the country they
can either be perceived as a serious threat to the local players, or more rationally,
Indian vendors can benchmark the best practices adopted by these MNCs and even
seek joint venture/sub-contracting opportunities. Some MNCs like CSC, who prefer to
sub-contract projects, may look at giving more projects to Indian players. CSC is sub-
contracting work to around five Indian players at present. Even Tier One companies
like TCS, Wipro and Infosys can explore joint venture or sub-contracting
arrangements with the global Big Five.
Interestingly, analysts believe that TCS may soon join the league of the global
Big Five owing to the depth of services offered by the company. Wipro and Infosys
have already started moving to a more comprehensive spectrum of service offerings.
Both of them have recently forayed into the BPO space too.
In conclusion, the Indian software industry is undergoing a decisive phase in
its evolution today, and it would be a wise step for the industry to take lessons from
the Big Five. Almost all of them have used acquisitions to outgrow others and
96

97. enhance their service lines as well as scope of offerings. Are the CEOs and managing
directors taking notes?
Conclusion
Indian IT companies have realized the potential of global delivery model and
are ramping up their operations globally. But not every software firms can manage
and execute the large and complex projects. According this study the company
requires matured process and methodology, robust tools and techniques, domain
expertise and large scale development centers cutting across the globe for handling
these projects. There are around 4 to 5 software companies which are capable of
handling these projects. But still we have to move up the value chain and grab more
complex projects like System Integration and Infrastructure management. This can be
done through strategic alliances among the Indian firms who can jointly provide the
services.
We also understood the relationship between large and complex software
projects. Most of the projects that are being carried out by Indian IT vendors are
application development and maintenance which is less complex and critical as
compared to other projects. But clients now expect more complex range of services.
Client expectation was also dealt in this research where every client has there own
way of evaluating the vendors. There are third party consultants who could provide
detailed analysis of companies who could handle large and complex projects.
It is important for the companies to move from business support processes to
business critical processes by identifying the new of challenges like scale of
operation, manpower planning, process capabilities etc. in executing large and
complex process.
97

98. Recommendations
Indian IT companies should be truly global in executing the projects. They
should take in account the cultural and language barriers while emerging as a global
company. Following are the recommendations that are prepared through both primary
and secondary research.
 Better manpower planning. First we should create the talent pool which is
prerequisite for executing any project.
 In depth domain knowledge
 Rich Technology expertise
 Active participation of all stake holders through proper communication
planning
 Experienced team of consultants
 Quality focus with efficient delivery model.
98

99. References
1. Management of
Large software development efforts by Robert w
Zmund
2. Managing Software Projects by Frank tsui
3. Managing and Modelling Complex projects by Terry m Williams
4. Managing agile projects by Kevin aguanno
5. Software Complexity and Project Performance Thesis by Sofia
Nystedt and Claes Sandros
6. www.sei.com
7. www.nasscom.com
8. www.pmi.org
9. www.microsoft.com
99