MCP1

Project Management National Conference 2011 PMI India

Your project is in Red, Now What?
Tools and Techniques for “Green”
pastures

Mandar P. Kulkarni PMP, MBA
Senior Business Analyst – Oracle Financials

2|P a g e
Application of Select Tools of Psychology for Effective Project Management


Contents

1 Abstract .............................................................................................................................4
2 Objectives...........................................................................................................................4
3 Keywords...........................................................................................................................4
4 Case Studies.......................................................................................................................8
5 Summary..........................................................................................................................15
6 Author’s Profile................................................................................................................15
7 References:.......................................................................................................................16

3|P a g e


1 Abstract

Best-in-class Organizations now have a Project Management Office (PMOi)
staffed with project managers who have years of experience in managing
projects of varying complexity and detail. Many of these managers also have
PMP certification to provide a structured, formal methodology essential to
managing projects. Despite superb planning and stakeholder involvement at
every stage, and a great team that collaborates effectively, projects do get into
the red and have to be brought back into green zone (on-target and on-budget
maintaining the triple constraint), otherwise failure is imminent. Project
managers use time-tested tools and techniques as presented in the PMBOK
guide and the collective experience of the team to pull through and provide
results. This paper discusses two test cases of implementing Oracle ERP and
the experiences to battle the odds and come out with flying colors.

2 Objectives

This presentation will help the audience get familiar with the tools and techniques
that are readily available and can be employed quickly to bring the project back
on-track and make a successful implementation. These techniques include, but
are not limited to, enhanced communication, a closer look at the triple
constraints, breaking the project into manageable phases implemented over
time, and risk re-analyzing and remediation. This presentation will discuss them
in detail and provide two case studies and analyze ‘lessons learned’ at the end of
our presentation.

3 Keywords

Risk Identification and Mitigation, Early Warning Signs

Project Management – opportunity to add value (revised and updated)

A project is goal oriented (something that can be tangibly achieved as described
in the project charter); is temporary in nature and has a distinct time-bound start
and end activities. No two projects are the same i.e. each project is unique.
Typical large-scale, high visibility, high impact projects are implemented with
empowered cross-functional project teams, stakeholder involvement at every
stage, and use of project organization structure.

Signs of Aging…

4|P a g e


There are always signs when your project inches towards trouble; sometimes
these early warning signs (EWS) are interpreted differently or in the worst-case
scenario, the signs are ignored. In any event, these early signs can be identified
by the following:

(a) Communication – communication is the key as explained in the PMBOK
knowledge areas. This activity spans all knowledge areas and process
groups explained earlier. Also, the communication channelsii grow
exponentially adding to the woes of the Project manager.

(b) Technology – Technology is the driver of the modern corporate engine.
Technology encompasses IT (Information Technology) and all the
components that make up technology, including but not limited to,
software, hardware, architecture, database, network, business process
reengineering and the ubiquitous internet. Sometimes, the wrong IT
strategy makes the project get into trouble and the triple constraints have
to be re-evaluated or changed to make the project feasible again.

(c) Poor risk response strategies – as explained earlier in the presentation,
many projects go through the process to identify, analyze and mitigate
risks as part of the project management process. But it has been
suggested that projects who do not manage their risk response planning
properly always end up not managing their triple constraints causing
projects to slip.

(d) Disparate Teams – A team that comprises different members of the
corporate departments with their unique agendas and animosity amongst
the peers definitely can affect the outcome of the project from the strategic
vision as encompassed in the project Charter.

(e) Project Scope – incorrect or poorly defined scope is the primary reason
why projects go downhill. It is not enough that stakeholders have a good
project charter and scope-as-we-know-it-today mentality of the
stakeholders. Also, scope creep due to influential stakeholders also adds
to the woes of the project managers.

(f) Business and Project Management alignment – many times, the strategic
vision as envisioned by the stakeholders and senior management at the
strategic level gets distorted when it comes to the tactical and operational
level in the organization.

5|P a g e


According to Leon Kappelman et al in the paper “Early Warning Signs of IT
Project Failures: The Dominant Dozen”iii discuss the “People-related” and
“Process-related” early-warning signs. The above six causes can be divided in to
the two categories as follows:

Cause or Sign of aging EWS Category

Communication Process

Technology Process

Poor Risk response strategies People and Process

Disparate Teams People

Project Scope People
Business and Project
People and Process
Management Alignment

Table 1: Causes of Project Failure and EWS Category

As shown in Table 1 above, the causes of failure are both people and process
related even though people related EWS take precedence over process EWS
due to the critical thinking ability that stakeholders and project manager
collectively have to ‘act’ on the EWS and steering the project in the correct
direction Also, according to Kappelman et al. the number one EWS is Lack of top
management support (people related) and Weak project manager at number 3
(also people-related) with lack of success criteria at number 2 (process related).
So what can the project manager do about these issues?

Tools of the Trade…

How to identify the early warning signs and how to use them effectively to
monitor your project status and if project is slipping, bring it back from the red
into the green zone? There are several tools and techniques available to the
project managers to monitor the health of the project. Let us discuss them briefly
and the case studies below will provide additional information on how the project
team utilized the tools and techniques to bring the project back on track.

a) Communication – As explained earlier, communication is the key area that
spans all activities of the project. What can Project Manager do to provide
consistent communication across all stakeholders? Communication can be
an effective conflict management tool wherein the team members resolve
their differences effectively using agreed upon communication strategy.
Groupthink should be avoided and project manager must ensure that the
effective communication is being reached to the right audience. Rules have

6|P a g e


to be place for running effective meetings (no checking emails or taking
phone calls, arriving on-time and only discussing the topic defined in the
meeting agenda are some examples). Methods of distributing project
information should also be part of the communication plan and strictly
followed. Lastly, developing better communication skills should be
encouraged and developed and leadership should lead by example with
planning and support and encouragement to the project team.

b) Technology – The knowledge and tools required to manage technology
projects are diverse, vary by industry and business requirements making it a
complex set of processes. The Project managers and the stakeholders
must ensure the use of right technology on the Project. One example is use
off-the-shelf software or to develop custom solution to meet the business
needs? The answer will require detail analysis with pro and con of each
option and recommended approach. The challenge of ensuring the
technology works in both these scenarios will determine the outcome of the
project. Case study II discusses this issue in detail.

c) Poor risk response strategies – This is also very important as far as the
project outcome is concerned. What is an acceptable risk for a project is
determined on how the project is structured and what the success criteria is
according to project scope document. The project manager should
encourage identification of all potential risks associated with the project and
work with the team to develop a risk register and quickly communicate the
risks that pose a problem with the help of the early warning signs. Case
study I discuss some of the steps the project manager took to avert disaster
and bring project back on track.

d) Disparate Teams – It is not uncommon to have teams located across
multiple geographies and even on different continents. What is required is a
clear communication strategy and team meetings to keep everyone abreast
of current status and issues if any. A smart project manager will be able to
identify groupthink and associated issues quickly and remedy the situation.
Case study I discuss one such scenario and how the team overcame the
problem successfully.

e) Project Scope – It is very difficult to identify the four walls of project day one.
But the stakeholders must make a conscious decision of writing the problem
statement and the desired outcome in great detail which will become the
scope of the project. In case study II, the Oracle ERP project required
interface with the legacy Logistics software. A decision was made to
purchase new logistics software which added considerable scope creep to
the project. The interface to and from Oracle became a big technology
challenge not only in design but also revised functionality. The logistics
software was a critical piece of day-to-day operation of the company and as
7|P a g e


such became absolute requirement. How the project team overcame the
problem is discussed in detail in the case study.

f) Business and Project Management alignment – The alignment of the
business stakeholders and the project team is required for the project to be
successful. Take the example of case study II. When it became apparent to
the project manager the legacy logistics software was outdated and need to
be replaced, the stakeholders were not sure why the Oracle ERP software
will not work with the existing legacy system. The alignment had to be
reiterated and reestablished and the stakeholders were taken into
confidence before moving ahead with the project.

4 Case Studies

Once it is identified that the project is in red, it is very important to use the tools
and techniques mentioned above in addition to identifying the people and
process categories for the early warning signs. These should be used effectively
to understand the current state of the project and devise an action plan to
mitigate and resolve the risks to bring the project back on track.

Case Study 1: Project is 25% complete and the project manager realize the big-
bang approach of implementing several countries in one go is not working as
identified by the EWS

Introduction: The Oracle Self-service iSupplier and iProcurement ERP project is
to be implemented in several South American Countries in a tight time-frame of
nine months. The implementation was cookie-cutter approach based on North
America model and the project was kicked off with much fanfare. After about two
months into the project, the project team realized that the project plan was
slipping and in the third month, the project became red with serious risk of delays
from the original plan…

Early warning signs that helped the project team identify the project is going
south were as follows:

1. Communication gap – most of English speaking team were unable to
communicate and solicit information from the South American business
leads causing confusion and mistrust.

2. Disparate teams – the business users were spread across geographies
with the Project implementation team located here in the US and the
development team located in India. The coordination and managing the
teams in different time zones was becoming difficult.

8|P a g e


3. Scope change – the cookie-cutter approach was deemed to be not a
good fit for the countries as legal and operational difficulties forced the
project team to rethink the current approach and provide a tailor-made
solution adding several months of design and development efforts.

The project team overcame the EWS to bring the project back on-track by
implementing the following changes:

a. To facilitate effective communication, the team identified a simple
way to breakdown the status reporting and assigned two translators to
help translate the English version in to the regional (Spanish and
Portuguese) languages so that our stakeholders were able to understand
very clearly what the project statuses is at all times. The team also
created a dedicated sharepoint project website to track all work
breakdown structures (WBS) and associated documentation of the
project online. The enhanced communication also helped us improve
cooperation amongst the stakeholders and the project manager and the
extended team.

b. To help the stakeholders understand the severity of changing scope,
the project manager put together a numerical score for each task and
map it back to the project plan and provided a color-coded display of the
scope change on the project (see Table 3 below). The numerical score
assigned to each task was based on its importance as per the Work
breakdown structure and if the task was on critical path. Adding new
tasks (because of scope creep) brought the statistical scoring off-
balance. The project team was able to identify easily what the %
complete status for each week should be (original plan) and what it is
(with the scope creep). The steering committee was able to justify
acceptance or rejection of the new scope so as not to jeopardize the
entire project deliverable.

c. Finally, the Business and Project Management alignment was
achieved by working with the Business to help drive the importance of
the project by clearly demonstrating that the project is part of the global
corporate strategy and also helps the regional geographies manage and
track spend and enhance the strategic sourcing initiatives.

Conclusion: The Results were clear for everyone to see. With correctly tracking
the project as per the risk response planning strategy, the stakeholders were
able to identify and isolate the issues early on and prevent further escalation and
possible failure. By evaluating the risk response strategies, the project manager
was able to bring the project back on track in the green zone and deliver it

9|P a g e


successfully with only a delay of eight weeks and the stakeholders were very
happy with the implementation team and the project.

Project: IMPLEMENTATION OFP ROCUREMENT ANDS UPPLIER
I I
Budget Status: GREEN
Schedule Status: GREEN
Risk Assessment: Low

Report Period: Week Ending June 18, 20
XX
Author: Mandar P. Kulkarni
Project Phase: Operations Analysis

Project Status Summary

20%
15%
15%
9%
10%
6%
5%

0%
Calendar Budget Activities

Table 2 Project Status Report

Task Rating 14-Jun 21-Jun
Project Charter 5 4 4
Project Work plan 5 3 3
Business Prototype CRP 10 3 3
Integration Testing 10
Test Case Scenarios - Standard
Operating Procedure 5 2
Test Case Scenarios - Exceptional
Conditions 5
Data Gathering and Cleansing -
Suppliers 8
Data Gathering and Cleansing - Item
Categories 8
Acceptance Criteria - Identification 4
User Acceptance Testing 8
Production Loading 9
Contingency Plans 4
Readiness Audits - Definition 4
Readiness Audits - Audit 4
Cutover Decision 10
Production Support - Approach
Definition 5
Production Support - Execution 5
Statistical Ranking: 109 10 12
Percentage Complete: 9.17% 11.01%

10|P a g e


Table 3: Project Scorecard

11|P a g e


Case Study 2: The project is 70% through the calendar (time) and we realize that
the technology challenges are more severe than previously anticipated and we
are nowhere near the development target!

Introduction: The project is to upgrade Oracle ERP from current version of 11i to
Release 12 using Oracle recommended technology for the upgrade. This is very
big implementation project spread over eighteen months with a team size of over
one hundred with everyone working diligently on the project plan well in to the
design and development phase of the project. After about a year on the project,
the PM realizes that the risk planning is showing considerable decay and that the
project is getting in to the red zone. The project has several issues as listed
below:

1. Technology – We were in new uncharted Technology territory with
the Oracle ERP upgrade with new terms like Oracle Framework
development and service-oriented architecture and Oracle Data
Integrator tool for Load-extract and translate data for conversions.

2. Scope Change – With better understanding of the project and its
impact, we realized that the current scope will not provide any real
benefits if we do not implement different areas that were previously were
considered out-of-scope and also some third-party software integration
that seemed necessary by our stakeholders

3. Disparate Teams – At one point of time, the project size was well
over one hundred developers, consultants, business analysts and
stakeholders working in India, and different time-zones in America and
lastly,

4. Poor risk response strategies to some of the new technology related
risks. We identified that the risks were minimal during the initial phases
but realized that the learning curve to master the new technologies were
longer than anticipated

5. Business and Project alignment – the Business was not sure why the
existing legacy Logistics software cannot function with the Oracle
software. The recommendation of third-party off-the-shelf software
integration with oracle was going to add several months of efforts.

12|P a g e


After a thorough evaluation of risk response strategies, the project manager
identified several remedial techniques to bring the project back on track and into
green again.

a. Technology issues identified were mostly that they were new to the
development staff. Oracle training was provided to several team
members including extended development team and consultants with
plenty of practice sessions to help them master the topic and helped gain
valuable confidence too.

b. Communication – The disparate team working in different time zones
was not working as an efficient well-oiled machine. The team realized
that a war-room concept, where team members work in one big room on
a time-zone comfortable to all will work better for this particular project.
The communication became more intelligent, and delays in responding
with each other also was reduced enabling the team to performing their
best in these given difficult circumstances. Also, daily sub-team meeting
notes were circulated to the project manager who in turn provided daily
status reports to the stakeholders.

c. Risk response strategies were enforced including identifying
unassigned work performed by team members without explicit
authorization by their respective module leader or project managers.
Schedule Performance Index (SPI), a measure of schedule efficiency is
ratio of earned value (EV) to planned value (PV). The project team
started tracking SPI for each sub-team for individual tasks that were
lower than 0.6, (considered a critical limit) as well as tracking each team
where the overall level was less than 0.8 (refer Table 4: SPI for tracking
purposes). This weekly monitoring of SPI helped the project manager
tremendously in anticipating the risks and proactively monitoring and
mitigating with concrete steps in place to work on the risks as they arose.
More than half the teams were below the .8 SPI thresholds, but within 3
weeks, all of them were above the .8 threshold and had shown
improvement. For the first time, the project manager could ‘see’ the
issues as they became visible in real-time and resolve them quickly with
strict control on the deliverables.

13|P a g e


Table 4: SPI for Project Tracking

d. Project Scope – Because the project scope changed due to so many
moving parts in the project, the project team decided to manage the
projects by breaking down into sub-projects using WBS ((Procure to
Pay, Record to Report etc.) into one combined ‘Rollup’ WBS as shown in
Table 4 above. This helped the team focus on the newly added scope
for the Logistics software interface (DEX) in addition to the existing
Oracle ERP module specific tracks.

Table 5: Improved Status Reporting

14|P a g e


Conclusion: Case study II provided details of a typical large-scale implementation
wherein the scope and technology affect the outcome considerably. The case
discussed in detail how the early warning signs were missed and once the
project went in to red, how the project manager used innovative approach to
bring the project back on track. The use of SPI and breaking down the projects in
manageable chunks using WBS was also very useful in keeping tight control
over the entire operation. Finally, the improved status reporting as shown in
Table 5 above was really useful in determining what the planned work was and
what unplanned work had to be done (either technology challenges or scope
creep) and what effect it had to the critical path. The combination of unique
status reporting, managing the scope effectively and effective use of technology
enabled the project team to complete the project successfully.

5 Summary

In summary, we have discussed the Early Warning Signs EWS of why projects
slip from their intended target with Communication and Technology being the top
two with people related EWS taking precedence over process related EWS. We
also discussed in detail two case-studies and how we were able to bring the
projects back on track with simple and easy-to-use methodologies. A quick demo
of Microsoft Project display SPI was also shown to enable project managers to
incorporate the SPI in their status reporting. Finally, EWS can be just an
indicator, but the project managers and the stakeholders should work
collaboratively to achieve the desired success as simply reporting EWS but not
‘acting’ will most definitely put the project in jeopardy.

6 Author’s Profile

Mandar P. Kulkarni is Senior Oracle IT Business Analyst with
experience implementing Oracle ERP since 1999 and has lived in
the USA since 2000. Mandar has MBA (MIS) from Loyola College in

15|P a g e


Maryland, USA and also is certified PMP professional. Mandar has
experience with Oracle implementation, upgrade and
enhancements. In the last three years, Mandar has started leading
projects combining the project management knowledge and the
Oracle ERP expertise. This is Mandar’s first professional paper at
PMI conference and he is looking to gain valuable experience and
feedback from this conference. Mandar can be reached at
MPKULKARNI@loyola.edu

Conference Paper: Your Project is in Red, now what? Tools and
techniques for green pastures…

PMI India Nationa l Conference – Bangalore, India 8-10 September
2011

7 References:

16|P a g e

i
A. Project management Office PMO is an organizational unit to centralize and
coordinate the management of projects under its domain. A PMO oversees
management of projects or programs or both. The PMO focuses on coordinated
planning, prioritization and execution of the projects and subprojects that are tied to
parent organization (or client’s) overall business objective – PMBOK Guide
ii
B. Communication channels as defined by the formula N*(N-1)/2 where N =
number of team members in the communication channel.
iii
C. Early Warning Signs of IT Project Failures: The Dominant Dozen”, by Leon
Kappelman, Robert McKeeman and Lixuan Zhang, Information Systems
Management Fall 2006 www.ism-journal.com

MCP1

More Related Content

What's hot

Viewers also liked

Similar to MCP1

More from PMI2011

Recently uploaded

MCP1