Mandarkulkarni 111003065827-phpapp01

Project Management National Conference 2011 PMI India

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

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

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


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 PeopleBusiness and Project

Management Alignment People and Process

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 OF IPROCUREMENT AND ISUPPLIER Budget Status: GREEN Schedule Status: GREEN Risk Assessment: Low Report Period: Week Ending June 18, 20XX Author: Mandar P. Kulkarni Project Phase: Operations Analysis

Project Status Summary

9%6%

15%

0%

5%

10%

15%

20%

Calendar Budget Activities

Table 2 Project Status Report

Task Rating 14-Jun 21-JunProject Charter 5 4 4Project Work plan 5 3 3Business Prototype CRP 10 3 3Integration Testing 10 Test Case Scenarios - Standard Operating Procedure 5 2Test 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 12Percentage 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 [email protected]

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

mailto:[email protected]

i

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

Date post:	08-May-2015
Category:	Business
Upload:	pmiireptp
View:	70 times
Download:	0 times