STANDARDIZED case studies in project program and organizational project management
390 CASE STUDIES
4. Joy Knows How to Defend As a critical incident, Joy Knows How to Defend discusses the need to
implement the project selection and evaluation process. Although an organi- zation does not really practice project management, establishing standardized
project selection may help defend the bottom line — profits.
CHAPTER SUMMARY
Name of Case Area Supported
by Case
Case Type Author of Case
Standardized Program Risk Management
Standardized Methodology
Issue - based Case Peerasit Patanakul
Go With the Template Always
Standardized Methodology
Issue - based Case Murugappan Chettiar
We Do Not Need Standard Methodology
Flexible Use of Standard
Methodology Critical Incident
Peerasit Patanakul, Sabin Srivannaboon,
and Dragan Z. Milosevic
Joy Knows How to Defend
Standardized Methodology
Critical Incident Dragan Z. Milosevic,
Peerasit Patanakul, and Sabin Srivannaboon
Standardized Program Risk Management
Peerasit Patanakul
Rose Martin, a senior program manager of the AB - 99 program, sits at her desk and looks at the risk management framework her team currently uses. This framework
has been developed over the years and is adopted by her organization as a stand- ard framework. Rose is wondering whether this standard methodology should be
revised to address the challenges of future programs. “ Our organization is taking more risks these days. If our risk management framework cannot handle this, one
day we will be on the front page, which may not necessarily be good. ”
THE COMPANY AND THE AB - 99 PROGRAM
Rose works for a multinational aerospace manufacturer, global security, and advanced technology company. The company is the world ’ s largest defense con-
tractor by revenue and offers a variety of products and services. Systems integration is among these services.
Rose ’ s program, AB - 99, is one of the programs under the Systems Integration business unit. The company is the prime systems integration contractor for AB - 99
with the total responsibility of overseeing all systems integration efforts. It is a multiyear contract to integrate advanced electronic systems into 99 multimission
helicopters to improve their communications capabilities.
STANDARD RISK MANAGEMENT METHODOLOGY
For AB - 99, Rose creates the environment that promotes a positive attitude toward risk management. Risk management is considered as an important part of program
management. In fact, risk management is ingrained in the company culture. It is practiced in every program by everyone. Since it is typical that a major defense
program consists of extended teams, it is important that the program stakeholders are involved in risk management on at least two different levels — the team level
and the program level see Figure 20.1 . Each level forms its own risk manage- ment board. At the team level, the team takes responsibility for the program risk
391
Risk Data base Online data repository
Facilitating real-time program risk management
Risk identification
Risk assessment
Risk handling Risk
surveillance Potential
risks Assessed
risks Response
plans Risk tracking data
Risk status data Potential risks
Assessment tools and techniques
Assessed risks Response plans
Team level
Risk identification,
assessment, and handling
Risk surveillance
Escalation Assignment
Program level
Potential risks Assesses risks
Response plans Risk tracking data
Risk status data - Periodical
program management
reviews - Ongoing
monitoring via data base
- Etc.
- Risk factor: probability and impact
- Quantitative risk analysis
- Assignment of ownership for risk
handling, e.g., team lead - Develop risk
response plans - Approval of risk
response plans by e.g., team lead
- Periodical project reviews
- Periodical status reviews
- Periodical technical performance
reviews - Risk meeting
- Technical reviews - Subcontractor reviews
- Ongoing program monitoring
- Technical performance measurements
- Cost and schedule analysis
- Periodical program management reviews
- Etc. - Program risk
reviews
Figure 20.1 Standard Risk Management Process
392
Standardized Methodologies 393
in their areas. The team is also responsible for highlighting risks that warrant elevation to the Program Risk Management Board. Risk management at the pro-
gram level is performed to facilitate the coordination and oversight of the overall program risks.
The company practices a standard risk management process which is aligned with the Department of Defense policy. The typical steps in the risk management
process include risk identification, risk assessment, risk handling, risk surveil- lance, and risk closure.
Risk Identification: Risks are identified at all levels and throughout the entire program life cycle. For AB - 99, Rose recalls that, during the early stage of the
program, they identified risks by examining the contract requirements, Statement of Work SOW, specification and other Request for Proposal RFP materials, as well
as the internally developed work breakdown structure WBS, Integrated Master Schedule IMS, and program plans. This initial assessment led to areas where the
team focused on improving the performance position to meet technical requirements, cost targets, and schedule goals, while balancing all three elements. The risk iden-
tification process also includes the review of the WBS against the internal risk taxonomy matrix. This matrix, in fact, serves as a checklist for risk categories,
which include requirements, design, integration and test, management processes, program constraints, production, and logistics including obsolescence.
Risk Assessment: To identify risk priority, risks were assessed by using both qualitative and quantitative approaches. For the qualitative risk assessment,
risks were classified by likelihood and impact levels. The likelihood represents the probability of risk occurrence. For the impact level, the adverse trends in
performance - measuring parameters from the impact or risks are measured and predicted. These parameters are the technical, cost, and schedule dimensions. In
terms of assessment scales, the AB - 99 team uses a scale of 1 to 5 to assess likeli- hood remote to near certain and impact high to low. The explicit operational
definitions for both likelihood and impact were used to facilitate a consistent evaluation standard. After the assessment, risks were added to a matrix. This
risk matrix helped facilitate the risk prioritization and the group review and discussion of the risk and corresponding step - by - step mitigation schemes. Rose
remembers that the cumulative effect of all of the risks on program cost in dollars was provided by a summation of the individual factored cost exposures. Cost
exposure is reviewed on a premitigation and a postmitigation basis, enabling the program to review the predicted reduction of cost exposure.
In addition to the qualitative risk assessment, the AB - 99 team also employed the quantitative risk assessment. In particular, the risk likelihood was evaluated in
terms of percent and the impact level was identified in terms of dollars cost or days schedule. Factored cost or schedule exposure was defined as the product
of the likelihood and impact in dollars or days. Rose recalls that each risk analy- sis included the determination of a root cause. By categorizing the root cause,
potential mitigation actions became more evident and more effective.
394 CASE STUDIES
Risk Handling: After the program risks were evaluated and prioritized,
the action plans were developed for responding to the moderate and high risks. Avoidance, mitigation, and the use of contingency acceptance were the com-
mon action plans. Low risks were maintained on a watch list, reviewed quarterly for changes, and closed when no longer applicable.
Risk Surveillance: At the team level, the risk management board of each team continually tracked high - or moderate - risk items. On a particular risk item,
once the board agreed that the risk level changed from moderate or high to low, that risk item was placed on the watch list and monitored for changes. The board
also monitored whether any risk items needed possible additional funding from the management reserve, whether any risks warranted elevation to the program
risk management board, and whether there were any newly identified risks. At the program level, the program risk management board met regularly to review and
discuss new potential risks and to manage existing risk mitigation efforts.
Risk Closure: Closure criteria were developed to evaluate risk items.
According to the criteria, if risks especially the ones on the watch list are assessed as no longer a factor, they are closed and removed from the list.
THE USE OF A RISK MANAGEMENT DATA BASE
To make this risk management activity possible, the AB - 99 team uses a risk man- agement data base. In the data base, risks are described, catalogued, updated,
tracked, and so forth. Rose believes fully that the use of the data base helps them manage risks effectively. The team uses the data base to support 1 the integrated
risk management, 2 the risk verifi cation by risk management boards, 3 the risk scoring system, and 4 the establishment of metrics and closure criteria for miti-
gation tracking. The data base also 1 is the central location for obtaining risk assessment data for the program, 2 provides for the team to respond quickly to
emerging risks, 3 facilitates shared monitoring of risks affecting multiple sub- systems, and 4 is the tool used to communicate risk areas and status to the chief
engineers and program leadership council. Rose loves the automated notifi cation feature of her data base because it gives any team member the ability to enter or
update risks and the ownerauctioneer receives an immediate notifi cation so they are aware of the changes and can access the information directly.
Discussion item
1. Discuss the standard risk management methodology of AB - 99 and suggest what Rose should do to improve this standard methodology.
395
Go With the Template Always
Murugappan Chettiar
The sales team at Click Computing Services CCS was exuberant upon closure of a multi - million - dollar contract to outsource IT services for a Minnesota - based
Fortune 100 company, SafeMining Inc. The deal was going to open doors for CCS in the vertical markets of mining and manufacturing where they had no track
record for the last 20 years.
The client management team at SafeMining foresaw the global economic slowdown in early 2007 and wanted to improve operating margins. They picked
CCS for being an industry leader and relied on their experience to effectively transition IT services from over 25 - year - old technology to state - of - the - art, scal-
able platforms and also adopt best practices. One request client management unambiguously made clear was “ never talk in abstract terms, always provide
specifics. ” They named the project Stella.
The implementation effort was organized into a program with three major IT projects — infrastructure, development, and services. The project team members
are both from CCS and SafeMining. Jeff Malta, a CCS program manager was a PMI professional. With his multiyear industry experience, Jeff foresees a prob-
lem with the reconciliation of project management standards between the two companies.
CLICK COMPUTING SERVICES
Click Computing Services CCS is an industry leader in outsourcing IT serv- ices with annual revenue of over 5 billion, and 15,000 people located across
20 offi ces in North America, Europe, Asia, and Australia. They manage IT func- tions i.e., computer hardware, computer networks, develop and deploy software,
and offer helpdesk support and Internet services. CCS started as a Y2K solution provider in the late 1980s and forayed into outsourcing leveraging offshore
methodology.
396 CASE STUDIES
PROJECT MANAGEMENT AT CCS
Typical Projects
Typical projects would include enhancements to current applications either thro- ugh product upgrade or custom programming. For example, an ERP procurement
module for a pharmaceutical client is being extended for international use with custom programming done by a team of onsite, onshore, and offshore resources.
New implementation projects would include migration of applications from client infrastructure to CCS infrastructure, such as hosting and support of an AutoCad
system for a manufacturing client and maintenance and support of a billing appli- cation for a retailer.
Project Organization
CCS built strong projectprocess methodologies to support its outsourcing activi- ties. Vertical markets such as government services, healthcare, consumer products,
manufacturing, fi nance, etc. were organized into portfolios under a principal part- ner. Principal partners had dedicated portfolio managers reporting to them from
various offi ces across the company. Each portfolio manager was responsible for the profi tability of accounts i.e., client in hisher portfolio. Each portfolio would con-
tain multiple programs either to implement new projects or service existing clients. Every individual client would have an implementation program andor service pro-
gram at any given time; and each program would have multiple individual projects. Staffi ng was managed at an organizational level, and resources were shared across
projectsprograms based on technical expertise. This included project managers, program managers, technical resources, and subject matter experts.
Project Resources
Project managers typically were drawn from the technical pool of resources and given the additional responsibility of project management based on tenure. Formal
on - the - job training was subsequently provided. Program managers, however, were dedicated within the portfolio and were subject matter experts on the industry verti-
cal market. Project managers reported a dotted line to program managers and a solid line to functional managers. The bulk of the project activity was done by technical
resources grouped under various functional managers. Project resources, project managers, and program managers were typically onsite at the client ’ s location for
the duration of project execution, barring confl ict with other priority programs.
Standard Project Management Process
Projects followed the PMBOK
®
Guide phases of Initiate, Plan, Execute, Monitor, and Close. The initiate phase generally included sales and portfolio managers select-
ing the project team. The planning phase included preplanning internal to CCS and
Standardized Methodologies 397
planning with the client. Execution was left to project resources. The monitor and close was the responsibility of program managers along with a steering team that
was comprised of members from CCS and client management. All projects had to be approved by a CCS portfolio manager prior to starttermination.
Organizational Support
CCS management supported project management practices and encouraged training; CCS management did not believe in oversight through a central project
management offi ce and left the successfailure of each project to its portfolio managers. Tenure of resources played a crucial role in the informal hierarchy;
communication fl ow among project resources was not always open but took place on an as - needed basis. CCS, as an organization, struggled with the adoption of
its own project management standards in a consistent way across all projects programs. This also aggravated existing clients who continued to have different
experiences with execution of each project.
STELLA PROGRAM
The program was organized into three major IT projects —
infrastructure, development, and services; lasted nine months, used 20 resources, and had
almost an open checkbook. Jeff Malta, the CCS program manager with many years of industry experience, was relatively new to CCS. He joined CCS a
little over two years ago. Both the development and service project managers had been with the company for less than fi ve years. Dave Wu, an infrastruc-
ture project manager, was a veteran. He had the most tenure at CCS with over 15 years.
AT PROJECT ANALYSIS MEETING Jeff: Dave, based on what we know from sales, in your opinion, what do you
think is the complexity we are dealing with here and how long will this take to implement?
Dave: The project is of average complexity, right in the middle of our scale and shouldn ’ t take longer than six months.
Jeff: Really. When can we present a draft schedule to the client team and what process do we follow?
Dave: We can present a schedule when we are done with project analysis. I just plug in the dates to MS - Project templates and we will have a plan.
Jeff: Wait a minute. I presume our project team will also be involved in the analysis prior to fi nalizing the dates or presenting it to the client, right?
398 CASE STUDIES
Dave: No, our project team is never involved in schedule preparation. We just change start dates on the template and that ’ s it.
Jeff: I am a little concerned about this approach for two reasons. One, every project is different. It ’ s okay to use a template as the starting point, but to use
it as if it is the fi nal plan. Two, not including the project team will not get us the buy - in.
Dave: This is how we have been operating for 15 years and have been success- ful. I see no reason to change this and do not have the time to do it either.
Jeff: I can help you do it, so we have a quality deliverable to the client based on actual requirements; not blindly using a template.
Dave: Sorry, I have three other projects to manage and this should not be a concern. As long as the client is available, we will do whatever it takes to make
it happen.
Jeff: How do we identify when client resources are needed? Don ’ t we have to plan with both project teams instead of assuming resource availability per
template?
Dave: Let me take care of it, Jeff. Jeff:
But Dave, you know that SafeMining practices a standard project management process and they want us to be very specifi c and realistic. We
have to take them very seriously. Plus, this is a multi - million - dollar contract. Getting it right will help our company expand our services to the mining and
manufacturing industry.
Dave: I will take care of it. Don ’ t worry. PROJECT ANALYSIS WAS COMPLETED
The client and CCS team met to discuss the schedule; upon review of CCS ’ s infrastructure project schedule the client team was dumb - founded and refused to
continue work on the project. SafeMining ’ s project manager requested a steering team meeting to discuss challenges.
Similar to a project management office, SafeMining had an Engineering Management Office with emphasis on engineering subject matter related to
mining and manufacturing. All new projects were evaluated so as to not impact their production operations; the company also had a methodology close to
PMBOK ’ s five phases. Project Stella had been assigned a representative from the engineering management office to support the deployment and change man-
agement as a result of outsourcing to CCS.
Client management reviewed the situation with their project managers and engineering management office representative to find out that CCS never
Standardized Methodologies 399
consulted their team members while creating the infrastructure schedule and never provided specifics for the activities to be completed, while assuming client
resources would be available almost 90 percent of the time for the project. Any SafeMining resource workload of more than 50 percent had to be explicitly
approved by the engineering management office. SafeMining management was concerned about the lack of consultation from CCS and collaboration to create a
successful working relationship. SafeMining decided not to pay the next install- ment of implementation fees and decided to re - review the relationship.
Discussion items
1. What is the role of a template and how was it applied at CCS? 2.
How entrenched were current practices and what could have helped with change management?
400
We Do Not Need Standard Methodology
Peerasit Patanakul, Sabin Srivannaboon, and Dragan Z. Milosevic
Since the organization ’ s restructuring, the project management department of Zeus Inc. has been struggling to implement standard methodologies across all
of its directorates. Some directorates have a formal way of managing their projects and require their project managers to be certifi ed. “ The fi rst thing I say
to someone who wants to be my project manager is: ‘ go study, take the exam, become certifi ed, and then, you can come work for me,’ ” said Tim Darby, the
director of product deployment directorate. Other directorates, on the other hand, are more fl exible in their project management approach. Project man-
agement certifi cation is not mandated. This case discusses how they reached a common ground.
PROJECT MANAGEMENT VETERAN
Tim ’
s product deployment directorate is among the four directorates under the program management department. James Higgs is Tim ’ s peer, who is also the
dire ctor of product deployment directorate. The difference is that James deploys new products related to Zeus ’ s new strategic initiative. Tim ’ s products are those
of the existing business initiatives, a bread - and - butter kind.
Tim started his career as an engineer, then project manager, and is now the director. As a project management veteran, Tim has developed a standard proj-
ect management methodology for his organization. It is a web - based tool called PDX, which includes the five
- step product deployment process. Templates,
tools, and techniques were created to support the project management activity in each phase. Tim requires his project managers to update the project document,
status, and issues every Monday. This web - based tool is also used as a project repository. So far, Tim has the information of over 500 projects that have been
implemented.
Standardized Methodologies 401
DON ’ T YOU WANT TO USE PDX?
Tim is very proud of his PDX. He owns it. He has a full - time staff allocated to monitor and upgrade the system. His boss also sees the benefi ts of PDX and
encourages the other directors to use the system. However, it is not mandatory. Tim does not understand why other directorates do not fully adopt PDX.
Tim: James, have you checked out PDX? What do you think about it? James: Yes. It is great. You have all the project history, all the checklists,
and tools. I also like the fact that it provides us a means to check the status of projects 247. You even have a function to print out the project status report.
This is all great stuff. But I am not sure how much this will apply to my projects. I am not sure if I should require my project managers to do all of that.
Tim: Why? James: My projects are unique. They are different. Some of those forms may
not be applicable to us. My project managers and I look at this and to tell you the truth, we are overwhelmed by it. We decided that we should not commit to
this at this time because we should focus on getting the projects done.
Tim: But James, if you guys follow the process in PDX, wouldn ’ t it help you jump - start your projects?
James: Probably not. With the entire document that we have to create, we will focus too much time in documentation rather than leading the projects. My
goal for them is to focus the least amount of time on creating the document. It does not mean that we do not do our job. We just go for the necessity.
Plus, I do not need to look at PDX to get the status update. My project manag- ers are collocated. I can go and talk with them, review the project document,
check the project status whenever we want. They can come and talk to me when issues arise. You are my offi ce neighbor but your project managers are
all in different locations. I think PDX suits your needs perfectly.
Tim: All the excuses, James. You just do not want to try. I cannot see the real reason why PDX is not applicable to you guys. Your product may be unique
but it does not mean that the standard deployment process doesn ’ t apply to it. Don ’ t tell me that your project managers are lazy or not capable of using the
system.
James: Hey Tim. That ’ s not nice. Even though my project managers are not certifi ed like yours, I can guarantee that they are capable. I know that you are
proud of your PDX. Don ’ t take it personally if we don ’ t use it. I told you that in my opinion it is a real good system but it is just not what I need my project
402 CASE STUDIES
managers to focus on at this time. Plus our boss never complains about whether I use it or not. I provide the documents he needs, in timely fashion, and I am on
top of all my projects without using PDX.
Tim: Sorry, I did not mean to offend you or your project managers. I just think that you and your project managers will benefi t from using PDX. All
the forms, templates, checklists, guidelines, tools, and techniques are there in PDX, arranged per phase. You guys don ’ t have to create anything new. They
are there for you to use. I think our organization will benefi t from this, too. All of the past project records are there. In fact, when we start new projects,
I require my project managers to search for similar projects in PDX, read all the documents, critical issues, lessons learned, etc. So far, this helps them
jump - start the new projects. The system makes it legitimate for me to set a goal of a 90 percent success rate for my project managers. I know that you
are struggling with setting up a 90 percent success rate goal. PDX has a lot of benefi ts: Effi ciency, effectiveness, project success, personal learning, and
organization learning are among them.
COMMON GROUND
James knows wholeheartedly that what Tim says makes sense. He agrees to implement PDX slowly. The overall fi ve - phase process is applied to all of James ’ s
projects, however, not all the documents, templates, tools, and techniques in each phase will be used. They agree that James ’ s projects are more dynamic and not
all cookie - cutter projects, like the majority of Tim ’ s projects. However, having a common place for project repository is very important.
Discussion items
1. To what extent do the following items play a role in implementing a standard methodology: project characteristics, project organization, and readiness of
project managers? 2. Suggest an approach to alleviate the resistant to use a standard methodology.
3. List the benefits and shortcomings of having a standard methodology.
403
Joy Knows How to Defend
Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon
Joy Pechum, CEO of California Anesthesiology Group CAG, was sitting in her offi ce, preparing the agenda for the meeting of the board of directors to be
held next Sunday. She thought about what to offer the board as an explanation for why she would spend 20,000 to deploy standardized project management
methodology. The board typically viewed these methodologies as unnecessary red tape — quite the contrary to her own beliefs that having too many methodolo-
gies in a company was not productive but saw them as a prerequisite to having orderly business processes.
At that moment the phone rang. She picked it up and heard the voice of Patrick, her VP of finance. He began, “ Joy, I have a vendor invoice here. It shows
that Dr. Squirrel had bought a computerized patient management system, costing 250,000. Its deployment would cost us another 250,000, i.e., a total of half a
million dollars All I want to know is whether you have approved it. ” “ No, I have not , ” answered Joy hanging up angrily, trying to visualize the face of Dr. Squirrel,
a big gun in the company, both as an anesthesiology expert and shareholder - owner, when she tells the board about this purchase.
OUR UNIQUE PRACTICE
CAG is a for - profi t company of 200+ medical doctors that provides their services by placing anesthesiologists in hospitals where they are needed; with annual sales
of 90 million. CAG is an employee - owned company, where the largest share- holders are the most senior medical doctors in the company. Accustomed to being
treated as royalty by the hospitals, these owners – senior doctors often behaved fi nancially irresponsibly and ignored CEOs before Joy.
Then, two years ago, Joy, with the reputation of the best CEO in town for mid - sized health organizations, was hired at CAG. The first order of business for Joy
was to introduce financial discipline. She was successful in her mission but only after spending a lot of time and anguish. But, still some of these owners–senior
doctors behaved in the same old way. Being owners–senior doctors, they often
404 CASE STUDIES
visited the premiere hospitals in the country, and, staying there a month or two, learned from the best in the business. Also, they often had the opportunity to see
the best or newest professional software, usually for managing patient systems. In pre - Joy times, some of them would order the software without consulting anyone.
The then CEOs did not object to these purchases because they feared the power of these owners–senior doctors.
EVIDENCE AND EVIDENCE
Then came Joy, who did not tolerate this behavior. She, of course, tried to avoid confl ict with the owners–senior doctors, but nevertheless brought two cases
of such a purchase to the board ’ s attention. That was an appropriate way, Joy thought, since all owners–senior doctors sat on the board. Basically, she painted
such purchases as an undesired attack on company profi ts. She thought that cul- prits were not aware of that, viewing the purchases only as CAG ’ s technological
improvement, which eventually is passed onto customers. The board was on Joy ’ s side whenever she mentioned erosion of profi ts with such unplanned purchases.
Simply, this was their money, and they did not like one to spend it, whether or not that someone was a colleague.
HERE IS AN IDEA
“ Good God, ” Joy thought to herself, “ Half a million dollars Gone Wasted ” She remembered the last two software computerized patient management sys-
tems they had were never deployed CAG did not have the skills to deploy the software, and doctors - owners appreciated making money working more than not
making it and spending time deploying software. Then, she got an idea. What if she explains to the board that she needs standardized project management
methodology to help prevent this purchasing behavior? Actually, she wanted to deploy standardized project management methodology exactly for this reason.
Only, she could not tell the board earlier, and now that Dr. Squirrel made that dangerous move on the software purchase, she could.
The first part of standardized project management methodology will be a standardized project selection process, mostly dealing with various patient man-
agement software projects deployed in order to improve service. Joy may use ZBB Zero - Based Budgeting or some other process that will prevent pet projects
like this. The second part will be project life cycle–based project planning to secure that no one rushes into the project without first thinking it through. And,
the third part will prescribe the project implementation procedure for Joy to know what is going on. Good idea? She once more scrutinized the idea and imagined
how individuals on the board would react to how much of their money the system would save. Then, she concluded, “ Joy knows how to defend profits. ”
Standardized Methodologies 405
Discussion items
1. Which part of the standardized project management system that CAG intends to introduce may help prevent purchasing behavior of owners–senior doctors
when buying patient management software on their own? 2. Identify several options to help prevent purchasing behavior of owners–senior
doctors when buying patient management software on their own. Do pro and con analysis of each and decide which option is the best.
3. How much does Joy risk conflict with the owners–senior doctors by bringing the attention of the board to the purchasing behavior of individual owners–
senior doctors when buying patient management software on their own? Describe this risk.
407