The current issue and full text archive of this journal is available on Emerald Insight at:

www.emeraldinsight.com/0953-4814.htm

Project Health
Introduction of a new metric Index
“Project Health Index” (PHI) to
successfully manage IT projects
Jayaraman Rajagopalan 385
Department of Operations and Supply Chain Management,
Received 24 December 2016
SP Jain Institute of Management and Research, Mumbai, India, and Revised 29 April 2017
Praveen Kumar Srivastava 30 May 2017
13 July 2017
SP Jain Institute of Management and Research, Mumbai, India Accepted 13 September 2017

Abstract
Purpose – The purpose of this paper is to develop a new comprehensive metric to successfully plan and
execute IT projects. The development will be based on a study of all the variables that go into making a
successful IT project.
Design/methodology/approach – A questionnaire, containing qualitative and quantitative response
questions, to gather data from practicing project managers is designed and used in an IT company.
Cronbach’s alpha is used to analyze the data and multiple regression is used to find the equation relating
project success to project management success.
Findings – A comprehensive variable called Project Health Index (PHI) has been identified. Using this
variable, one can predict whether a project is likely to succeed or not. This comprehensive, composite variable
is calculated by using 17 other project-related metrics identified from the responses to the questionnaire.
Research limitations/implications – The PHI has been calculated for the company studied. However,
more studies need to be performed before it can be established that the PHI can also be used in other
companies and projects. What has been established and validated is that PHI can be used in the studied
company and that the methodology to calculate PHI is valid.
Practical implications – The PHI can be used as a predictive variable, i.e. one that can be used to take
corrective and preventive actions to make a project successful. The PHI can also be used to allocate resources,
prioritize the allocation and improve project management during the course of project execution.
Social implications – By implementing projects efficiently, resource utilisation increases and leads to waste
avoidance. Improved sustainability is the end result.
Originality/value – The work is original. The contents and the conclusions drawn, as well as the use of the
PHI will enable IT companies to implement projects efficiently, reduce cost and enhance profit.
Keywords Interviews, Questionnaire, Best practices, Nine knowledge areas of PMI, Project Health Index,
Project Management Institute (PMI), Three bands
Paper type Research paper

1. Introduction
According to Forrester Research, global spending on information technology (IT) was
expected to rise to 6.2 percent, i.e. US$2.22 trillion in 2014, and the growth was likely to
quicken in 2015 by 8.1 percent (Kanaracus, 2014). India, being a major IT hub, was expected to
contribute to the underpinnings of this growth. NASSCOM, the national trade association of
Indian IT and information technology enabled services (ITES) industry expected the domestic
IT sector to grow from 12 to 14 percent, while IT exports were likely to reach US$86 billion in
2014-2015 by adopting new technologies and entering into new geographies (Bhoola, 2015).
IT companies around the world deploy project management practices, such as discussions
with customers to understand their requirements, design systems and software configurations;
develop applications software using computer languages like Java and C+; test the developed
Journal of Organizational Change
applications in-house and also with the clients; and then deliver the output. Additional services Management
which are performed after the system has been installed can also be part of the project. Vol. 31 No. 2, 2018
pp. 385-409
These services can include operations of the system, refinement of the developed product, © Emerald Publishing Limited
0953-4814
correcting any errors found and soliciting customer feedback. In order to carry out these DOI 10.1108/JOCM-12-2016-0301
JOCM activities, IT companies recruit, train, deploy teams, provide hardware resources like buildings,
31,2 power connections, uninterrupted power supply devices for uninterrupted and stable power
supply, supervise the work, co-ordinate the team interfaces, provide in-house testing facilities
and take care of other team requirements. They also deploy marketing teams to solicit and
obtain orders; define the requirements to the software teams; act as an interface with the clients
to seek and clarify issues arising periodically during project execution.
386
2. Purpose and basis of this research
In the IT industry, a “successful project” is the one which not merely delivers on time and
under budget, but also ensures the ease of operation by the client, ease of maintenance of the
software and meets the expectations of the customer in his environment on an on-going
basis. Needless to say, every IT company desires that all its projects are successful.
The design and delivery of products and services of an IT company is a much
researched and developed subject. For example, the “waterfall” model has been replaced
with “scrum.” Using lean and waste reduction methodologies, many efficiency
improvements have been achieved. While these methods are useful at the aggregate
level, the knowledge of the details which make up for the aggregate, such as, deployment
of a highly skilled, trained and competent workforce, team work, accurate scoping and
scope management and use of appropriate “best practices,” well-designed processes and
continuous improvement, will provide an IT company with the abilities to deliver
“successful projects.” The business excellence (BE) literature emphasizes that the trio of
“enablers-processes-results” is the modern way to run successful companies (Baldrige
Model for Performance Excellence, 1987, and European Foundation for Quality
Management, 1989). Therefore, our research was designed to identify the “enablers,”
the factors, as aforementioned, which make for successful project management in the IT
company that we studied. Doing so will enable the company to sharpen its project
management practices and compete on the basis of customer delight.
In our research, we have adopted a unique method using a newly defined composite
variable called “Project Health Index” (PHI). The PHI serves multiple purposes and could be
developed into a very powerful tool for refining project management practices in an IT
company and, in the larger context, for all projects. First, the composition of the PHI will
indicate the relative importance of the various project management factors. Second, the value
of PHI will indicate whether a given project will be successful or not. Third, the value helps
compare different projects on the factors that govern successful project management which
can then be used for “post-project completion” analysis. Many companies use the results of
such analyses to make improvements. Other reason for innovating this methodology was to
develop a “user friendly and actionable” decision tool. In a binary method, such as 0/1, there is
no middle ground. While this is appropriate for technological fields, such as electronics, this
may not be suitable for industrial situations, especially manual-oriented project management
situations. A PHI-like tool gives some flexibility in the final value and also in the selection of
the decision variables which make-up the PHI.
In order to provide a basis for calculating the PHI, we describe a case study
using a questionnaire and structured interviews followed by analyses performed in a
Tier-2 IT company in India. We demonstrate how PHI can be calculated and how it
can be used for a successful IT project management. We have used the nine knowledge
areas framework of the PMI to substantiate the validity of using a decision variable such
as PHI, showing how the direction in which PHI moves based on the values of the
variables comprising the PHI is completely aligned with the way the PMI framework
would expect. We discuss the attributes and the usefulness of PHI as a comprehensive
decision variable. We finally offer suggestions for ways in which this work can be
extended and enhanced in the future.
3. IT project risk management literature survey Project Health
A large number of IT projects fail and are never brought to completion. According to a Index
comprehensive report by (The) Standish Group (1999) that presents data on 23,000 IT projects
from 1994 to 1998, 31 percent of IT projects failed in 1994, 40 percent were unsuccessful in
1996 and 28 percent were canceled in 1998 (quoted from Chulkov and Desai, 2005; Jake, 2008,
Standish Group Report, 1995). The report estimates the cost of canceled IT projects in 1998
alone to reach $75 billion. The failure rate of large IT projects with budgets exceeding 387
$1 million was found to be almost 50 percent higher than for the projects with budgets below
$350,000 (Gartner Study and Gartner Report, 2012). The reasons why IT projects fail are
reported in Gartner Study and Gartner Report (2012) study and are shown in Figure 1.
Several researchers have identified the factors that affect the success of software projects
(Ropponen and Lyytinen, 2000; Palitha et al., 2002; Keil et al., 2004; Baccarini et al., 2004;
Athreye, 2005; Bannerman, 2008; Aundhe and Mathew, 2009; Raghu Raman et al., 2007;
Chui-Ha Ng et al., 2013). Pictorially, the effect of impact and probability of risks that arise in
a software project can be visualized, as shown in Figure 2.
For software projects, the risk profiles will depend on the importance of the project to the
client. For example, the SAP type of projects, due to their comparatively higher degree of
complexity arising from their multiple connectivities, greater efforts to customize, longer
gestation periods to install, and difficulty in integrating with company operations, have to
be handled with greater care. Similarly, software projects which develop application
software to run supervisory control and data acquisition devices and automated production
facilities like a pharma tablet production line, a biscuit manufacturing line, a coupled
tandem cold rolling mill are fraught with high risks due to the sensitivity of the technologies
involved, scale of operations, high-speed working of the lines, the large volumes of output
and flexibility expected from these operations. Dey et al. (2007) mentioned that the success of
software development depends on the following criteria: functionality, quality and
timeliness. They also aver that very little work has been done in order to involve all the
concerned stakeholders in managing risk and integrating the risk management process with
a holistic project management approach.
Boehm (1991) identified ten types of risks and several types of cost drivers in software
projects. Together, these give an idea of how risks and costs in a software project are
intertwined. The top ten risk items are as follows: personnel shortfall, unrealistic schedules

Percentage of respondents
100 7
8 6
90 11
12
17
80
12
70 Other reasons
16
60 24 Poor quality
22
14 Canceled after launch
50
High cost variance
40 Substantially late
24 28
23
30 Functionality issues

20
22 24 22
10
Figure 1.
0
Small IT projects Medium IT projects Large IT projects Reasons why IT
projects fail
Source: Gartner Study and Gartner Report (June 2012)
JOCM Residential High cost, large, high
31,2 complexes in new technology/unproven
areas, cinemas, low /new technology
to medium cost projects, projects to
projects, projects produce new products
financed by a group (e.g. integrated
High
of individuals/ steel plant, oil
388 Probability of risk organisations refinery, off shore oil
(e.g. new airports, rig, telecom), IT
retail stores) projects

Repeat projects Low ROI, long

(example, roads, gestation period, low
flyovers, railway product margin
Low line, government projects (e.g.
funded projects for coal mines, iron ore
public purposes such mines, sea ports)
as water pipelines)

Figure 2. Low High

Relationship between
impact and Impact of risk
probability of projects
Source: Author

and budgets, developing the wrong user interface, gold plating, continuing stream of
requirements changes, shortfalls in externally furnished components, shortfalls in
externally performed tasks, real-time performance shortfalls and straining computer
science capabilities. It is not surprising that the first item of risk that Boehm has identified is
related to personnel, which is the key in IT projects. However, Bannerman (2008) cautioned,
quoting from several studies, that risk identification exercises do not always throw up the
same results. For example, Ropponen (1999) re-ranked Boehm’s (1991) list of risk factors in a
different cultural context at a different time and found significantly different rankings. Only
three of the ten were ranked the same and Boehm’s highest ranked item was placed seventh
in the Ropponen’s list (Bannerman, 2008).
Overall, studies in risk identification and mitigation do not emphasize the critical role
played by team work and motivation levels in a project or the methods used – especially
“best practices“ – that need to be used to promote team work. Such best practices can be
either derived from the literature based on the data and knowledge collected by various IT
companies or can be found from the specific project practices in an IT company executing
IT projects. We postulate that it is better to identify such best practices from each
company’s experience and culture rather than pick them up from databases.

4. Review of IT project management literature

For a good description of the structure of the Indian software industry, the reader may access
the works of Ilavarasan (2007), Chandra et al. (2006) and George Chacko (2004a, b). These papers
contain data on the main parameters of the Indian IT industry including the competencies
required for project management. Project management skills are a pre-requisite for IT
companies to survive in a competitive market where offshoring often puts a lot of pressure on
the prices quoted to clients. It is well known that there are many Indian IT companies which are
in this business, servicing clients mainly in the USA, Europe, Middle East and East Asia.
 The academic literature is replete with the studies on what makes for successful project Project Health
management. For example, Toor (2008) identified the following factors to be addressed by Index
project managers: bridge disconnects and retain talent, value “uncommon productive
thoughts” and create best practices, seed synergy and team work, build winning structures
while forming teams, generate employee awareness, hone employee skills, analyze
situations and co-create strategies effectively, develop hybrid skills and make employees
responsibly accountable. 389
He opined that putting best practices into action in a project is an important part of
success. “No matter how good we think our departmental processes are, there’s always room
for improvement. Identify tasks that need improvement. Do not implement best practices just
because they look good. There is a cost involved in implementing superior practices. Verify
the need by measuring the worth. Measure return on investment and resources”.
The results of our work described in this paper are in agreement with these conclusions,
we also found that merely deploying best practices is not always useful, one must find
appropriate enough reasons to use the best practice. One of our key objectives was to
identify the appropriate best practices. The data resulting from our questionnaire responses
have accomplished this objective.
Amongst the several factors that Lacity and Rottman (2009) identified as critical for
project success, many were related to people issues. For example, the knowledge level, the
knowledge of the software developers about the client’s business models and requirements,
the ability of the team members to come up to speed as required by the client are the more
important ones. Productivity is a key driver as the demands from clients as well as the initial
underestimations of cost and time by many software developers make ramp up of
productivity essential. This is especially true for offshore outsourcing, as added factors,
such as time differences, cultural differences, frequent client-supplier interactions, add to
challenges. Difficulty in knowledge transfer (KT) is another key issue.
Writing in the McKinsey Insights and Publications, Bloch et al. (2012) have identified
four factors which can improve project success:
(1) focusing on managing strategy and stakeholders instead of exclusively
concentrating on budget and scheduling;
(2) mastering technology and project content by securing critical internal and external
talent;
(3) building effective teams by aligning their incentives with the overall goals of
projects; and
(4) excelling at core project management practices, such as short-delivery cycles and
rigorous quality checks.
Rosacker and Rosacker (2010) observed that while there are many business practice
improvements that have a significant potential to enhance the outcomes of IT, the study of
“best business practices” in project management within the design and implementation
phases for IT projects holds a tremendous potential for improved outcomes.
In his study, Bannerman (2008) concluded that “success in software projects depends a
lot on the way people are managed, teams are motivated and their performance is monitored
and supported through the project […] the project manager is no superhero or lone crusader.
Organizational support is also needed. Good project management requires a complementary
framework of individual, team and organizational capabilities and effort to optimize their
contribution […] these projects indicate that project success is an outcome of good
management per se not necessarily ‘project management’ as a body of knowledge and
practice. What is critical to software project success is good (people) management of a
discrete, temporary, joint business-technical activity.”
JOCM Hadaya et al. (2012) reported that the two most valuable, rare and inimitable IT project
31,2 management resources/capabilities are:
(1) the capability to understand and manage the needs, expectations, priorities and
interests of project stakeholders; and
(2) the firm’s capability to align IT projects to the strategy and business objectives of
the client organization.
390
Thus, it is clear that the team that is delivering the product to the client should be well aware
of the business needs and requirements so that the team members can modify their
productivity rates to suit the needs of the project as well as deliver the needed skills and
competencies as required.
In her study of the Indian software industry and its growth, Athreye (2005) observed
that “[…] the growth in software exports was based on improved productivity of the
industry. We argue that this improved productivity was due to the development by
Indian firms of dynamic capabilities, which enabled them to use changing economic
opportunities to carve out a niche in the export of outsourced services […] the annual
average rate of growth of software revenues per person in 1993-98 was more than
16% per annum.”

5. Case study in a Tier-2 IT company in India

Our study was carried out in a Tier-2 IT company located in western India. For reasons of
confidentiality, we are unable to name the company. However, the company is publicly
listed in the Indian stock exchanges and its CEO maintains a very high profile in
NASSCOM, the Indian computer industry apex body.

6. Brief company background

Annual revenue 2,315 crores (2013-2014) (approximately

USD400 million)
Annual PAT 238 crores (2013-2014) (approximately
USD40 million)
Number of employees 6,800+ (across the globe)
Number of divisions (VBU’s – vertical business (1) Manufacturing
units) in the company (2) Banking, financial services and
insurance
(3) Retail
(4) Healthcare and digital enterprise
(5) Infrastructure management
Number of project managers in the company 150+ (project managers managing
development projects)
(all data as of the date the study was done)

7. Research methodology
Following steps were taken to conduct the study. It was decided to conduct both a
qualitative and quantitative study. Accordingly, a questionnaire was prepared (see the
Appendix) to be used for a survey of selected project managers. Cronbach’s α (Santos, 1999
and Lee Cronbach, 1951) was found to be 0.783, confirming that the data gathered can be
used for measuring the parameters that we set out to study.
 The questionnaire prepared was based on a literature review of lean methodology, project Project Health
management and agile methodology as well as a review of the implementation of lean in Index
Wipro and other organizations. In all, 40 questions were included, each one covering a specific
area of work. Of these, 37 questions asked for a scale response between 1 and 5 ( from 1 being
“never” to 5 being “constantly”). There were sub-questions and three questions which were
qualitative in nature for which responses could be descriptive. Responses to these qualitative
questions were used to perform qualitative analysis. In total, 30 projects were selected for 391
specific study and one of the authors interviewed each project management involved in each
of the 30 projects. Project managers of development, enhancement and maintenance projects
of different vertical business units across the organization were interviewed in-person.
For quantitative questions, project managers were asked to rate different parameters of
project execution on a scale of 1 to 5, as shown in Table I.
The survey response data were analyzed to find correlations between variables and their
impact on each other and PHI (the composition of what is PHI will be detailed further on).
Responses to qualitative questions were analyzed to know how different types of tasks are
executed by project managers from which best practices were culled out.
Highly correlated variables, identified through a process of multiple regression, have
been selected to calculate PHI. The equation derived to calculate PHI is as follows:
PHI ¼ 27:5771:975  a4_res_after_proj_billing_date_rate 1:889  c4
_project_delayed_right_resþ1:044  a7_review_session_planned0:859
a13_rework_coding_cust_change_req_rate0:780  a14_info_loss_onsite
_offshore_rate þ1:364  a15_team_meeting_rate2:478  b16_miss_requirement

_rate0:759  a17_customer_asks_extra_rate1:327  a21NC_core_resource

_per þ1:807  a22_motivate_team_rate3:618  a23_business_challenge_rate
þ1:300  c23_schedule_formal_training_rate þ4:755  a26_communicate_client
_rateþ1:468  a27_cust_business_pain_rateþ1:891  a29_lesson_learnt_rate
þ1:720  b30_revisit_best_practice_rateþ4:061  a32_confident_team_know_rate:
(1)
The variables were categorized as under.
Resourcing:
(1) hire resource after project start date;
(2) project delayed due to non-availability of right resource;
(3) percentage of core resource;
(4) team motivation;
(5) challenge in understanding business domain;

Scale Description
Table I.
1 Never Scale on which project
2 Rarely manager is asked to
3 Occasionally rate different
4 Regularly attributes of project
5 Constantly delivery
JOCM (6) formal training for business; and
31,2 (7) core resources allocated to project.
Communication:
(1) loss of requirement from onsite to offshore;
(2) frequency of team meetings;
392
(3) confidence on team knowledge;
(4) frequency of client communications; and
(5) understanding of customer business pain points.
Scope:
(1) rate of missing requirement;
(2) rework due to change in customer requirement; and
(3) customer asks extra feature.
Best practices:
(1) gather and implement lessons learnt; and
(2) revisit best practices.
The basis of selecting these variables is shown in Tables II-IV.
Using the equation, the value of PHI for each of the 30 projects was calculated and
plotted as shown in Figure 3.
PHI ranges from 31 to 64. Then, projects were categorized into three parts based on PHI
using following criteria (Table V ).
The methodology shown in Table V is called the “three bands” comparison approach.
Many research workers use the two set comparisons (e.g. Collins, 2001); however, we have
chosen the three bands concept which has proven to be very useful in our study. We believe

Unstandardized Standardized
coefficients coefficients
Model B SE β t Sig.

1 (Constant) −27.577 4.343 −6.350 0.000

Hire resource after project start date −1.975 0.223 −0.371 −8.865 0.000
c4_project_delayed_right_res −1.889 0.571 −0.129 −3.306 0.006
a7_review_session_planned 1.044 0.236 0.124 4.421 0.001
a13_rework_coding_cust_change_req_rate −0.859 0.261 −0.138 −3.287 0.006
a14_info_loss_onsite_offshore_rate −0.780 0.205 −0.104 −3.802 0.003
Frequency of team meeting 1.364 0.292 0.148 4.677 0.001
b16_miss_requirement_rate −2.478 0.253 −0.272 −9.795 0.000
Customer asks extra feature −0.759 0.240 −0.138 −3.159 0.008
a21NC_core_resource_per −1.327 0.169 −0.203 −7.840 0.000
a22_motivate_team_rate 1.807 0.215 0.224 8.419 0.000
a23_business_challenge_rate −3.618 0.289 −0.501 −12.508 0.000
c23_schedule_formal_training_rate 1.300 0.151 0.235 8.635 0.000
a26_communicate_client_rate 4.755 0.695 0.172 6.846 0.000
Table II. a27_cust_business_pain_rate 1.468 0.172 0.229 8.541 0.000
Selection of variables a29_lesson_learnt_rate 1.891 0.188 0.316 10.035 0.000
to calculate Project b30_revisit_best_practice_rate 1.720 0.247 0.230 6.955 0.000
Health Index a32_confident_team_know_rate 4.061 0.488 0.292 8.321 0.000
that the type of comparison chosen is unique and has not been done before in the literature Project Health
on project management in IT companies. The projects in the band closest to the mean have Index
been classified as “successful projects.” Thus, three “bands” of successful projects have been
identified as least successful, successful and most successful projects (LSP, SP and MSP)
and that is how the method has received the name.

Model summary
393
Model R R2 Adjusted R2 SE of the estimate

1 0.998a 0.996 0.990 0.70751

a
Notes: Predictors: (constant), a32_confident_team_know_rate, a26_communicate_client_rate, a22_
motivate_team_rate, b30_revisit_best_practice_rate, a27_cust_business_pain_rate, a21NC_core_ Table III.
resource_per, b16_miss_requirement_rate, c4_project_delayed_right_res, a14_info_loss_onsite_ The strong correlation
offshore_rate, a29_lesson_learnt_rate, a7_review_session_planned, c23_schedule_formal_training_rate, between the
Customer asks extra feature, Frequency of team meeting, a23_business_challenge_rate, Hire resource after dependent and
project start date, a13_rework_coding_cust_change_req_rate independent variables

ANOVA
Model Sum of squares df Mean square F Sig.

1 Regression 1,422.960 17 83.704 167.218 0.000a

Residual 6.007 12 0.501
Total 1,428.967 29
Notes: Dependent variable: project_health; apredictors: (constant), a32_confident_team_know_rate, a26_com-
municate_client_rate, a22_motivate_team_rate, b30_revisit_best_practice_rate, a27_cust_business_pain_rate,
a21NC_core_resource_per, b16_miss_requirement_rate, c4_project_delayed_right_res, a14_info_loss_
onsite_offshore_rate, a29_lesson_learnt_rate, a7_review_session_planned, c23_schedule_formal_training_rate, Table IV.
Customer asks extra feature, Frequency of team meeting, a23_business_challenge_rate, Hire resource after Selection of variables
project start date, a13_rework_coding_cust_change_req_rate (dependent)

4
Frequency

1
Mean = 48.87
SD = 7.324
n = 30
Figure 3.
0
Project health vs
30 40 50 60 70 projects
Project health
JOCM 8. How to use the PHI
31,2 First, one must calculate the value of PHI, as shown in Equation (1). Then, the applicable
rule is: if PHI ⩽ 48.87−7.32 ¼ 41.55, then the project is likely to be less successful. If the value
of PHI is ⩾ 48.87+7.32 ¼ 56.19, then the project is likely to be a more successful project.
In between, that is, 41.55 oPHI o56.19, the project is likely to be successful. In practice, the
reasons why a project is likely to be successful could encompass a gamut of activities and
394 the PHI is truly reflective of this composite/comprehensive nature of the underlying
phenomena. That is the strength of the PHI.
We have checked literature on non-IT project management and found that such an
approach (i.e. the three band approach) has not been used (see, e.g. Odeyinka and Yusif,
1997; Assaf and Al-Hejji, 2006; Faridi and Sageh, 2006; Murali and Soon, 2007; Abd El-Razek
et al., 2008; Salama et al., 2008; Challal and Tkiouat, 2012; Marzouk and El-Rasas, 2014;
Ruqaishi and Bashir, 2015).

9. Analysis and discussions of results

9.1 Discussions on the nature and usefulness of PHI
In the IT industry, projects software tools (language, sub routines, IF loops, etc.) are used to
develop a code for the programs required to be suitably linked to form the solution that has
been promised to the customer. If the outcome variables (lag metrics) are time, cost, quality
and maintainability of the project, then the enabling metrics (lead metrics) are usually
related to people and processes. The elements which compose both these lead and lag
metrics have to be identified for successful project implementation in a company.
A combination of these metrics will be a measure of the degree of success of a project.
This approach is what the BE models quoted earlier in the paper also advocate.
We have adopted a methodology of calculating the Cronbach’s α and using multiple
regression to identify the composition of the PHI for the company that we have studied.
As shown before, the PHI consists of a total of 17 factors which can be categorized under
four heads: resourcing, communication, scope and best practices. Of these, the first two are
largely related to the people management of the company, while the third one is an estimate
of the quantum of work and quality of the project. The last one is a process measure which is
related to the continuous improvement practices in the company. Thus, the composition of
the PHI indicates the lead metrics which need to be tackled (much like the root causes in an
Ishikawa diagram or the first few activities in a Pareto diagram) to succeed. Interestingly, a
PHI can be very useful for making progressive corrections during the process, unlike a lag
matric, which is useful only post facto.
A low value of PHI during the execution of a project can immediately indicate that the
project needs improvement. It is also possible to identify which of the four factors is pulling
down the PHI, thereby enabling the management to address specifics without the loss of
time. Usually resources are constrained and hence an idea of the PHI will allow the
management to target a medium or high PHI for individual projects which are at a low level.
Such decisions allow the optimal use of available resources as well as prioritization. Clearly,
PHI is a comprehensive decision variable.
Each component of PHI consists of at least two factors which indicate the leverage
available in using the PHI. That is, the value of PHI can be increased by increasing the

Projects Criteria

Table V. Less successful project (LSP) Project health ⩽ Mean−standard deviation

Project categorized as Successful project (SP) Mean−standard deviationoProject healtho Mean+standard deviation
per project health More successful project (MSP) Project health ⩾ Mean+standard deviation
value of any one of the factors (or levers). For example, if a project is low in PHI due to Project Health
“best practices,” then we can increase either “gather and implement lessons learnt” or Index
“revisit best practices”. The leverage can be useful for optimizing an individual or a group
of projects through the joint maximization of PHI. The levers available can be deployed
over several projects selectively.
Overall, the PHI conveys directionality through its quantitative value and qualitative
directionality through its composition. The PHI has to be calculated in a company using 395
data for several projects. As of now, it is not clear whether the PHI range is unique to a
company, and whether it will change with time or variations in other variables. The only
thing that can be stated just now is that PHI is a composite index which can be a
comprehensive decision variable.

9.2 Validation of PHI through alignment with the nine knowledge work areas of PMI
The basis for validation of PHI is that the factors included in the PMI nine knowledge
areas framework (excluding the last one – procurement – which is not relevant in an IT
project implementation) (http://getpmpcertified.blogspot.in/2011/05/chapter-7-project
management-knowledge.html, Guide to the PMBOK and https://certifedpmp.wordpress.
com/2008/09/18/summary-of-project-management-knowledge-areas/) and those used to
calculate PHI are fully aligned, in content and direction. That is to say, all the factors that
form a part of PHI can be linked and identified (or mapped) to be a part of the PMI
knowledge areas, and the way in which they move will affect the project success in the
same way.
9.2.1 People management. In a Tier-2 IT service organization, people management is one
of the most important project management activities done by the project managers.
Resource allocation. “Associates ramp up and ramp down” are normal phenomena and
have a significant impact on the successful delivery of projects. Our study shows that MSPs
take lesser time to ramp up a new joinee. In a similar fashion, there is lesser ramp down in
MSPs compared to LSPs. It is to be noted that attrition is the major cause of ramp down,
which means that MSPs are able to retain team members more than LSPs. MSPs are also
able to manage to allocate resources on time (see Figure 4).
However, it is interesting to note that both MSPs and LSPs are unable to manage project
timeline due to the unavailability of the right resource. In such scenarios, team members
stretch to deliver the projects on time.
Training. MSPs give more importance to business and technical training and, in turn,
face less business and technical challenges. In fact, MSPs conduct more business domain
training than LSPs. In total, 78 percent of LSPs confirm that the main reason of bug
introduction is due to the issues in understanding (lack of ) of business domain.

Resourcing
4.9
4.1
5.0
3.0 2.9 3.1 2.8
4.0 2.4
3.0 1.7 1.7 1.9
2.0
1.0
0.0
Week needed Resource Days wait to Project Resource ramp
to ramp up allocation after get new delayed due to down
new joinee project start resource unavailability
date of right
Figure 4.
resource
Attributes of
resourcing
More successful projects Less successful projects
JOCM Understanding of business domain helps a developer to understand the project end-to-end
31,2 and leads to fewer bug introduction and successful delivery on-time. It also helps to improve
productivity of developers (Figure 5).
In a low-performing project, more than a three-quarter of bugs are due to the issues in
understanding of business domain (also supported by Hadaya et al., 2012). MSPs conduct
more detailed training of applications than LSPs, which includes detailed walk-through of
396 the project (Figure 4). It also includes walk-through of non-functional requirement of the
projects, such as performance, document requirement, etc. As shown in Table VI, it has been
observed that the projects that conduct detailed walk-through are able to reduce the ramp
up duration of new joinees to three to four weeks.
Subject matter expert (SME)/core resources. High dependency on core resources leads to
low PHI (also supported by Athreye, 2005). It is identified that LSPs have more SMEs and
are more dependent on SMEs compared to MSPs. On an average, MSPs have 33 percent
SMEs, whereas LSPs have around 50 percent SMEs. At the same time, MSPs need less time
to build new SMEs. MSPs require less than six months to prepare SMEs, and LSPs require
more than seven months (see Figure 6).
Motivation. In the software service industry, the motivation of team members is very
important and plays a key role in the successful delivery of the project. Our study identifies
that the activities, as shown in Table VII, impact the motivation of team members in either a
positive or negative manner.
For example, activities, such as delivery of a project on time, which impact project
execution in a positive manner also help to improve the motivation. On the other hand,
factors like requirement miss and escalation from client lower the motivation of the team.

4.7
5.0 3.8 4.1
Figure 5. 3.7 3.7
Detailed walk-through 4.0 2.7
2.6 2.3
to new joinee, 3.0 2.0 1.9
business domain 2.0
challenges faced ,
business training, 1.0
technical challenges 0.0
faced and technical Detailed Business Business Technical Technical
training – comparison walk domain training challenge training
between LSPs through to challenge scheduled faced scheduled
and MSPs new joinee faced
More successful projects Less successful projects

Table VI.
Relationship between
ramp up duration and
detailed walk-through
of new joinee
 5.0
29.8
30.0 Project Health
Index
4.2
23.1 25.0
4.0
3.6 Dependent on core
20.0
resource

3.0 15.0 Core resources in the 397

2.4 team
10.0 Weeks required to create
2.0 SME
1.7
5.0

Figure 6.
1.0 0.0 Attributes of core
More successful Less successful resources
projects projects

Factors that improve motivation Factors that reduce motivation

Delivery of project on time Estimation changed by customer

Allocation of task based on complexity Dependency on core members
Identification of reusable component Reworks
Reviews of codes/documents Cost of project execution
Unit testing Information loss from onsite to offshore
Identification of clients business pain point Extra features requested by client Table VII.
Causal analysis Requirement miss Factors affecting
Functional awareness Technical challenges faced motivation of team
Escalation from client members

9.2.2 Communication management. Every project team needs a robust mechanism of

communication to reduce communication gaps and delays. Our study identifies that the
duration of relationship with client has a direct relationship with better communication; and
MSPs are on an average engaged for longer periods with their clients compared to LSPs.
For other parameters of communications, such as information loss from onsite to
offshore for various purposes, frequency of team meetings, knowing customer’s business
pain points and KT to stakeholders, MSPs are doing a little bit better than LSPs. However,
MSPs receive fewer escalation from clients compared with LSPs (see Figure 7).
9.2.3 Time management. In total, 71 percent of MSPs never missed their deadline;
however, 56 percent LSPs missed deadlines sometimes. In total, 65 percent of project
managers believed that the delay in delivery is due to the insufficient knowledge of business
domain and end-to-end domain knowledge (Figures 8 and 9).
In a few projects, to achieve the goals, project managers are requested to “stretch.”
MSPs request their members less frequently compared to LSPs. It has been observed
that stretch hides different types of issues of project execution and can be compared with
inventory in the manufacturing industry. A detailed analysis of stretch needs to be
done to identify the root causes of the issues (Figure 10). Project managers believe that
the allocation of task should be done based on the complexity of task and efficiency of
team members, which helps to reduce pressure on SMEs and improve the throughput
of the team.
JOCM 5.0 5.0
4.9 4.9
5.0
31,2 4.6

4.0 3.9
3.8
4.0
3.2
3.0
3.0
398 2.6

2.0 1.9
2.0 1.6

Figure 7. 1.0
Attributes of Relationship Info loss → Frequency of Communication Receive Know customer Knowledge
communication with client onsite to team meeting with client escalation from business pain transfer to
management offshore client point stakeholder
More successful project Less successful project

Reasons for missing deadline

11% Lack of end-to-end domain knowledge

12% 35% Issue in requirement collection/late

requirement
Issue in understanding scope
12%
Technological issue
Figure 8.
Reasons for missing 12% Cross-functional issue
deadline 18%
Others

Missed deadline
71%
80%
56%
60%
33% 29%
40%
11%
20% 0%
0%
Figure 9. Never Rarely Regularly
Missed deadlines
More successful projects Less successful projects

9.2.4 Quality management. Continuous zero-bug delivery helps to improve client

satisfaction and it definitely improves the top-line and bottom-line of the organization.
We observed that MSPs perform planned review sessions and causal analysis in a better
manner than LSPs. In a similar way, “rework after coding and analysis” of MSPs is less than
that of LSPs. Project managers should document lessons learnt after the completion of
milestones/projects and should also revisit their best practices, as is being frequently done
by MSPs. It is observed that MSPs gave less extra features to customer (gold plating)
 4.6
4.2 Project Health
5.0 Index
4.0 2.7
2.3
3.0

2.0 399
1.0

0.0
Stretch in office Allocation based on Figure 10.
task complexity Stretch and allocation
of resources
More successful project Less successful project

compared with LSPs. Overall, a small improvement in each factor of project delivery helps
projects to become more successful (Figure 11).
9.2.5 Scope management. Our study shows that MSPs perform better in all four major
parameters of scope management, as shown in Figure 12. There is a marginal difference in the
performance for the estimation changed by customers, when both types of projects are
compared. Rework due to change from customer is less than half for MSPs than that of LSPs.
In a similar way, in MSPs, clients ask less extra features and also have less requirement misses.

4.9
5.0 4.4 4.3
4.1
3.6 3.4 3.4 3.3
4.0

3.0 2.3
2.0 1.9
2.0 1.3

1.0

0.0
Planned Rework Causal Extra Lession Revisit best
review after coding analysis features learnt practice
Figure 11.
session and analysis provided to documented
Quality management
customer
in IT projects
More successful projects Less successful projects

5.0
3.8
4.0 3.3

3.0 2.1 2.0

1.9 1.7
1.4
2.0 1.1

1.0
Estimation Requirement Client asks Figure 12.
Rework due to
changed by miss extra feature Project scope
change from
customer management
customer
parameters
More successful projects Less successful projects
JOCM Estimation. The estimation of project requirement is one of the most challenging activities in
31,2 project execution. Proper project planning and control is not possible without an accurate
and reliable estimate. It is important that both project team and client agree on the estimate.
More than 50 percent of projects use standard methodology (Excel sheet) and around
28 percent of projects use Work Breakdown Structure to estimate the scope. However,
17 percent of projects (almost all of them new engagements) use ballpark/experience/gut
400 feel. Project managers should avoid gut feel or only experience to estimate the project, as it
leads to errors and the process cannot be re-used. High training in business domain results
in less rework (also seen in Bloch et al., 2012).
As per response of the project managers, estimation changed by a client is rare but a few
reasons were highlighted by them: estimation was done without understanding the
requirement of the project properly, complexity (non-functional requirement) was not taken
into account for estimation, and pressure from the client to reduce the effort and scope
increases/decreases after initial estimation of the project.
9.2.6 Risk management. Although attrition is one of the major risks in a Tier-2 IT
organization, MSPs are able to manage it better by continuous cross-training and reverse
KTs compared to LSPs. Common risks and corresponding mitigation identified for project
execution are enlisted in Table VIII.
9.2.7 Cost management. In the IT service industry, the cost of a project is mainly related
to the cost of associates working in it. Every project management tries to save money
through better execution. Our study shows that there is no major difference between the
initiatives taken by MSPs and LSPs to reduce the cost of their projects (Figure 13).

No. Risk Mitigation

1 Attrition Mainly impact small teams, where it is difficult to create backup. Cross-
training and creating backup help to mitigate attrition
2 Business knowledge of Reverse KT helps to identify and minimize the gap in understanding of
developer business domain
3 Unplanned leave Store the code at centralized location and always have a backup of the
associates
4 Dependency on cross flow Keep client aware about dependency on cross flow team.
team Must have basic understanding and details of touch points of cross flow
domain
5 Lack of scope Use query tracker to clarify scope in detail
Table VIII. understanding Use Request Traceability Matrix (RTM)
Risk management 6 Issue due to onsite- Formal communication to transport the requirement
in IT projects offshore communication 15-minute daily standing meeting avoids communication issues

5.0
3.4 3.2
4.0

3.0

2.0
Figure 13. 1.0
Cost management Initiative to reduce cost of the project
in IT projects
More successful projects Less successful projects
9.2.8 Project integration management. Quantitative analysis suggests that a few factors Project Health
work together and have a major impact on the other factors of project execution (Table IX). Index
Identification of best practices. Based on the above analysis, few best practices have been
identified. These are shown in Table X.

10. Conclusions
Our study, conducted in a Tier-2 IT firm in India, reveals that there are many factors that 401
affect the success of projects. We have innovated and used a new methodology to compare
and contrast the factors responsible for project success by using a “three bands” framework
where the three bands consist of: LSP, SP and MSP. We believe that this is a unique
methodology which may help future projects benefit in identifying the “best practices.”
We have also introduced a new parameter to signify a holistic approach to measure
project success, in contrast to the traditional view of “time” and “cost” as the sole criterion.
The PHI performs two functions: first, it indicates whether a project is an SP, LSP
or an MSP; and second, what can be done to improve the PHI value. Thus, the PHI is a
composite/comprehensive multivariate decision variable which can be used as a
progress monitor and as a basis for CAPA (corrective and preventive actions, in the
ISO 9000 terminology).
In our study, we have identified “best practices” which are suited to the company that we
studied. We believe that while some generic factors may be involved in determining the
success of IT projects, there could be specific factors which could affect the success in
certain situations obtained in different IT companies. We believe that such an approach may
be more beneficial to IT companies than merely adopting/adapting generic best practices.
Companies should also identify their in-house best practices and use them further for their
commercial interests.

Correlation within
Component Factors variables Comment

Customer Receive escalation from client 0.87 Increase in team ramp down (attrition),
escalation Ramp down of team 0.80 stretch to deliver project, allocation of
Stretch in office to meet 0.74 resource after project billing start date and
deadline customer asking extra features may lead
Resource allocation after 0.70 to customer escalation
billing start date
Customer asks extra 0.63
Resource Frequency of team meeting 0.88 Increase in frequency of team meeting,
dependency Tasks allocation based on 0.86 allocating tasks after analyzing
complexity complexity, detailed walk-through to new
Detailed walk-through 0.80 joinee reduce dependency on core
Dependency on core resource −0.62 resources
Project cost Reduce cost 0.80 Reduction cost of project leads to increase
optimization Communication with client 0.70 in communication with client, business
Business challenge faced 0.62 challenge and dependency on core
Dependency on core resources 0.60 resource increases
Capability Technical training 0.79 Increase in technical and business domain
impact Business training 0.72 training lead to reduction in extra features
Client asks extra feature −0.59 requested by client and rework due to
Rework due to client change −0.53 customer change request
request Table IX.
Confidence Functional awareness 0.85 Increase in functional awareness may lead Parameters relevant to
on team Confidence on team 0.84 to increase in confidence of project project integration in
management on team IT projects
JOCM Area of knowledge
31,2 management according to PMI Best practices identified in the IT project that was studied by us

Project integration Involve support department, mainly practice, RMG, talent acquisition,
management training, human resource department for project kick off
Scope management Prefer 15-minute daily standing meeting than that of long meeting
Use of Query tracker and Requirement Traceability Matrix helps to reduce
402 requirement miss and request by customer for extra features
Onsite should also convey why to do along with what to do
Cost management Analyze risk on continuous basis. Communicate to manager/client with
mitigation plan at earliest
Always update your assumptions
Time management Automate the process, wherever possible to speed up task by reducing
manual work
Use Work Breakdown Structure to identify small component.
Allocate task based on complexity of tasks and experience of resource
Treat change request as new project and plan separately
Human resources management Cross-train/rotate resources across modules/project
Plan and groom the resources by cross-training, resource rotation across
module/shores, mentoring, providing KT by recorded session for application
and at last giving freedom to appropriate decisions
Motivate your resources on continuous basis, as it impacts each and every
factor of project delivery
Assign challenging work to resources, as it is one of the best non-monitory
methods to motivate resources in short duration
Communication management Prefer 15-minute daily standing meeting than that of weekly long meeting
Onsite should also convey business justification along with what to do
Be aware of client’s business pain point, as it is area of opportunity
Risk management Analyze risk on continuous basis. Communicate to manager/client with
mitigation plan at earliest
Always update your assumptions and risk register
Quality management Plan all review activities in project schedule. Capture defects and analyze the
Table X. root cause
Best practices Minimum 60% of UT cases should be written before development
identified from this UT must be either automated or done by peer, preferably junior resources in
study in IT project the team
management Tasks of more than 40 hours should be reviewed by SMEs

11. Suggestions for further research

We believe that the three bands methodology, the PHI and the identification of best
practices suiting each organization can be additional tools to improve project success.
Further research is needed to validate our findings and this could be a new field for project
management research in IT/ITES companies.

References
Abd El-Razek, M., Bassioni, H. and Mobarak, A. (2008), “Causes of delay in building construction
projects in Egypt”, Journal of Construction Engineering and Management, Vol. 134 No. 11,
pp 831-841, 10.1061/(ASCE)0733-9364(2008)134:11(831).
Assaf, S.A. and Al-Hejji, S. (2006), “Causes of delay in large construction projects”, International Journal
of Project Management, Vol. 24 No. 4, pp. 349-357.
Athreye, S. (2005), “The Indian software industry and its evolving service capability”, Industrial and
Corporate Change, Vol. 14 No. 3, pp. 393-418.
Aundhe, M.D. and Mathew, S.K. (2009), “Risks in offshore IT outsourcing: a service provider
perspective”, European Management Journal, Vol. 27 No. 6, pp. 418-428.
Baccarini, D., Salm, G. and Love, P.E.D. (2004), “Management of risks in information technology Project Health
projects”, Industrial Management & Data Systems, Vol. 104 No. 4, pp. 286-295. Index
Baldrige Model for Performance Excellence (1987), available at: www.nist.gov/baldrige (accessed
February 21, 2018).
Bannerman, P.L. (2008), “Risk and risk management in software projects: a reassessment”, The Journal
of Systems and Software, Vol. 81 No. 12, pp. 2118-2133.
Bhoola, V. (2015), “Impact of project success factors in managing software projects in India: an 403
empirical analysis”, Business Perspectives and Research, Vol. 3 No. 2, pp. 109-125, © 2015 KJ
Somaiya Institute of Management Studies and Research, SAGE Publications.
Bloch, M., Blumberg, S. and Laartz, J. (2012), “Delivering large-scale IT projects on time, on budget, and
on value”, Tel Aviv, Düsseldorf, Berlin, October, available at: www.mckinsey.com/business-
functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-
and-on-value (accessed February 22, 2018).
Boehm, B.W. (1991), “Software risk management: principles and practices”, IEEE Software, Vol. 8 No. 1,
pp. 32-41.
Chacko, G.K. (2004a), “WIPRO: from coding to consulting: a case study”, Management Research News,
Vol. 27 No. 7, pp. 63-95.
Chacko, G.K. (2004b), “Infosys: new game new rules: a case study”, Management Research News,
Vol. 27 Nos 8/9, pp. 1-25.
Challal, A. and Tkiouat, M. (2012), “Identification of the causes of deadline slippage in construction
projects: state of the art and application”, Journal of Service Science and Management, Vol. 5,
pp. 151-159, available at: http://dx.doi.org/10.4236/jssm.2012.52019; www.SciRP.org/journal/jssm
Chandra, A., Fealey, T. and Rau, P. (2006), “National barriers to global competitiveness: the case of the
IT industry in India”, Competitiveness Review: An International Business Journal, Vol. 16 No. 1,
pp. 12-19.
Chui-Ha Ng., Walker, D.H.T. and Levin, G. (2013), “IT project management capabilities enhancement
impacts of contingent employment policy in Hong Kong organisations”, International Journal of
Managing Projects in Business, Vol. 7 No. 1, pp. 144-157.
Chulkov, D.V. and Desai, M.S. (2005), “Information technology project failures”, Information
Management & Computer Security, Vol. 13 No. 2, pp. 135-143.
Collins, J. (2001), Good to Great, Random House Business Books, London.
Dey, P.K., Kinch, J. and Ogunlana, S.O. (2007), “Managing risk in software development projects: a case
study”, Industrial Management and Data Systems, Vol. 107 No. 2, pp. 284-303.
European Foundation for Quality Management (1989), available at: www.efqm.org (accessed
February 21, 2018).
Faridi, A.S. and Sageh, S.M.E. (2006), “Significant factors causing delay in the UAE construction
industry”, Construction Management and Economics, Vol. 24, pp. 1167-1176.
Gartner Study and Gartner Report (2012), available at: https://thisiswhatgoodlookslike.com/2012/06/
10/gartner-survey-shows-why-projects-fail/ (accessed February 21, 2018).
Hadaya, P., Cassivi, L. and Chalabi, C. (2012), “IT project management resources and capabilities: a
Delphi study”, International Journal of Managing Projects in Business, Vol. 5 No. 2, pp. 216-229.
Ilavarasan, V. (2007), “Is Indian software workforce a case of uneven and combined development?”,
Equal Opportunities International, Vol. 26 No. 8, pp. 802-822.
Jake, W. (2008), “IT’s biggest project failures – and what we can learn from them”, available at: www.
computerworld.com/article/2533563/it-project-management/it-s-biggest-project-failures——and-
what-we-can-learn-from-them.html?page=4 (accessed February 21, 2018).
Kanaracus, C. (2014), available at: www.channelworld.in/news/global-it-spending-outlook-better-
subpar-2014-forrester-says (accessed February 21, 2018).
JOCM Keil, M., Smith, H.J., Pawlowski, S. and Jin, L. (2004), “ ‘Why didn’t somebody tell me?’: Climate,
31,2 information asymmetry, and bad news about troubled projects”, The Database for Advances in
Information Systems, Vol. 35 No. 2, pp. 65-84.
Lacity, M.C. and Rottman, J.W. (2009), “Effects of offshore outsourcing of information technology work on
client project management”, Strategic Outsourcing: An International Journal, Vol. 2 No. 1, pp. 4-26.
Lee Cronbach, J. (1951), “Coefficient alpha and the internal structure of tests”, Psychometrika, Vol. 16
No. 3, pp. 297-334.
404
Marzouk, M.M. and El-Rasas, T.I. (2014), “Analyzing delay causes in Egyptian construction projects”,
Journal of Advanced Research, Vol. 5 No. 1, pp. 49-55, doi: 10.1016/j.jare.2012.11.005.
Murali, S. and Soon, Y.W. (2007), “Causes and effects of delays in Malaysian construction industry”,
International Journal of Project Management, Vol. 25, pp. 517-526.
Odeyinka, H. and Yusif, A. (1997), “The causes and effects of construction delays on completion cost of
housing projects in Nigeria”, Journal of Financial Management of Property and Construction,
January, pp. 31-43.
Palitha, R.K., Mandal, P. and Smith, R. (2002), “IT project implementation strategies for effective
changes: a critical review”, Logistics Information Management, Vol. 15 No. 2, pp. 126-137.
Raghu Raman, S., P., Budhwar and Balasubramanian, G. (2007), “People management issues in Indian
KPOs”, Employee Relations, Vol. 29 No. 6, pp. 696-710.
Ropponen, J. and Lyytinen, K. (2000), “Components of software development risk: what influences it – a
project manager survey”, IEEE Transactions on Software Engineering, Vol. 26 No. 2, pp. 98-112.
Rosacker, K.M. and Rosacker, R.E. (2010), “Information technology project management within public
sector organizations”, Journal of Enterprise Information Management, Vol. 23 No. 5, pp. 587-594.
Ruqaishi, M. and Bashir, H.A. (2015), “Causes of delay in construction projects in the oil and gas industry in
the Gulf cooperation council countries: a case study”, Journal of Management in Engineering, Vol. 31,
available at: file:///C:/Users/Ja/Downloads/Most%20Important.pdf (accessed December 18, 2015).
Salama, M., El Hamid, M.A. and Keogh, B. (2008), “Investigating the causes of delay within oil and gas
projects in the UAE”, in Dainty, A. (Ed.), Proceedings of the 24th Annual ARCOM Conference,
September 1-3, pp. 819-826.
Santos, J.R.A. (1999), “Cronbach’s Alpha: a tool for assessing the reliability of scales”, Journal of
Extension, Vol. 37 No. 2, pp. 1-5.
Standish Group International (1995), “The chaos report: why projects fail”, available at: www.csus.edu/
indiv/v/velianitis/161/ChaosReport.pdf (accessed December 12, 2015).
(The) Standish Group (1999), “CHAOS: the recipe for success”, research report, available at: www.
standishgroup.com/chaos_resources/index.php
Toor, T.P.S. (2008), “People management: an imperative to effective project management”, Business
Strategy Series, Vol. 10 No. 1, pp. 40-54.

Further reading
Aibinu, A.A. and Jagboro, G.O. (2002), “The effects of construction delays on project delivery in Nigerian
construction industry”, International Journal of Project Management, Vol. 20 No. 8, pp. 593-599.
Costa, H.R., Barros, M.D.O. and Travassos, G.H. (2007), “Evaluating software project portfolio risks”,
The Journal of Systems and Software, Vol. 80 No. 1, pp. 16-31.
Dmitriy, V., Chulkov Mayur, S. and Desai (2005), “Information technology project failures”, Information
Management & Computer Security, Vol. 13 No. 2, pp. 135-143.
Lars, M., “Gartner reports show why projects fail”, available at: http://thisiswhatgoodlookslike.com/20
12/06/10/gartner-survey-shows-why-projects-fail/ (accessed December 12, 2015).
Martinez, E (1994), “Avoiding large scale information systems project failures: the importance of
fundamentals”, Project Management Journal, Vol. 25 No. 2, pp. 17-25.
Project Integration Management. Chapter 4, ©1996 Project Management Institute, Upper Darby, PA,
pp. 39-46.
Appendix. Questionnaire used for survey in the company Project Health
Index

405
JOCM
31,2

406
Project Health
Index

407
JOCM
31,2

408

About the authors

Jayaraman Rajagopalan is educated at IIT Bombay in Metallurgical Engineering, IIM Ahmedabad and
University of British Columbia where he graduated with Distinction in Metallurgical Engineering
(MS), as also a Diploma in Production Management from the SIES Institute of Management.
R. Jayaraman has had an illustrious career spanning over 35 years. Starting with Mukand Iron and
Steel Limited where he worked in production, design and R & D of a steel plant, he went on to Project Health
successfully install and commission the non ferrous bi-metal sintering line for the manufacture of Index
automotive bearings in Gabriel India Limited. He played a key role in the acquisition and merger of
Special Steels and Ahmedabad Advance Mills with Tata Steel. He worked in the highest offices in Tata
Steel – EA to the VC, Executive Officer to the MD Dr J.J. Irani, Head of Selection of a Coastal site for a
10 mtpa steel plant of Tata Steel, Chief of Project Planning, Monitoring and Cost Control of the world
class 1.2 million tpa Cold Rolling mill project of Tata Steel which set several world records in project
management and cost Rs2,000 crores. He has also served as the Chief of Business Excellence of Tata 409
Steel and Tata Communications Limited, both global giants in their respective areas of operations. He
also worked as a Senior VP of Technology and a Chief Safety Officer of Tata Teleservices where he
introduced industry standard practices in telecom tower management. He has co-authored, with the
past Vice Chairman of Tata Steel, a well acclaimed book on project management. He has also authored
more than 60 technical and management papers in various national and international journals some of
which have received awards. He was selected by the “Best Citizens of India” forum and the “India
International Friendship Society” for the “Best Citizen of India” and “Bharat Jyoti” awards for his
services to academia and industry in 2013. He was also nominated by Tata Communications Limited
for the “Best Changemaker” in the telecom industry in India in 2008. His current research interests are
in inventory management, supply chain, operations planning, lean management and operations
strategy. Jayaraman Rajagopalan is the corresponding author and can be contacted at:
[email protected]
Praveen Kumar Srivastava received Master of Science (Computer Science) Degree from Banaras
Hindu University, India and joined the IT industry. He is currently a Senior Manager at Cognizant
Technology Solutions with more than 17 years of experience in Program and Project Management for
eCommerce technology. He is instrumental in managing project/program planning & execution,
resource & stakeholder management, risk management, escalation management and budget of the
program. To enhance his management capability, he completed Post Graduate Executive Management
Program (PGEMP) from SPJIMR, Mumbai. Along with delivering program, he is always focused in
improving processes and methodologies and provides value adds to internal and external stakeholders.
During his professional journey, he worked at various international locations such as Japan, Singapore
and USA of America with clients of different business domain. He has written several blogs on
different topics on project and program management.

For instructions on how to order reprints of this article, please visit our website:
www.emeraldgrouppublishing.com/licensing/reprints.htm
Or contact us for further details: [email protected]