PROGRAM MONITORING case studies in project program and organizational project management
314 CASE STUDIES
CHAPTER SUMMARY
Name of Case Area Supported by Case
Case Type Author of Case
I Have Only Three Minutes a Month
Progress Report Critical Incident
Dragan Z. Milosevic, Russ J. Martinelli, and
James M. Waddell OSSOP
Monitor and Control Program Risk
Issue - based Case Sabin Srivannaboon
That Which Is Not Earned Is Never Valued
Monitor and Control Program Performance,
Program Schedule, and Program Financials
Critical Incident Sabin Srivannaboon
315
I Have Only Three Minutes a Month
Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell
Al Petroff, CEO of DirectConnect, a world premiere producer of interface cable, was very expressive, almost rude: “ Look guys, my time is very expensive, and
I am sick of wasting my time reading poor reports. I need you to design a report showing the monthly status of my 40 - plus programs going on at any time. It must
be a one - pager showing the most important things about my programs; it need not contain words, only numbers and graphical symbols, and I must be able
to read it in three minutes because I have only three minutes for that purpose a month. Is it clear? ” A consultant who Al was talking to nodded and said,
“ Yes, it is clear. ”
Seven days later the consultant was back with a one - page report. He began by saying, “ We included five metrics, covering program management as it relates
to measurement from strategic management, portfolio management, program management, and project management:
LEVEL: STRATEGIC MANAGEMENT AND PROGRAM PORTFOLIO MANAGEMENT
1 Alignment of programs to business - unit strategic goals : Percentage of total program portfolio that is compatible with documented business - unit strategic
goals. It appears diffi cult to fi nd a program that does not support specifi c business - unit goals. But if so, an explanation should be provided.
LEVEL: STRATEGIC MANAGEMENT AND PROGRAM MANAGEMENT
2 Projected future income from program road map : Fraction of future net income by year projected from programs on the program roadmap over multiple years; the
probability times the net income for accomplishing each program goal will also be provided.
316 CASE STUDIES
LEVEL: PROGRAM PORTFOLIO MANAGEMENT
3 Program portfolio distribution : A way to express fractions of the total program portfolio among various dimensions that are important to program stakeholders.
The metrics help determine how to modify the program portfolio if the programs are not in balance.
LEVEL: PROGRAM PORTFOLIO MANAGEMENT AND PROGRAM MANAGEMENT
4 External customer satisfaction survey : Average value of ratings given by key external customers, on a Likert scale of 1 to 5, with 5 being the highest value and
1 being the lowest value. It measures various dimensions such as timeliness of the program completion and customer value of the program output.
LEVEL: PROGRAM PORTFOLIO MANAGEMENT, PROGRAM MANAGEMENT, AND PROJECT MANAGEMENT
5 Percent of the program milestones accomplished : The percent of all pro- gram milestones in the portfolio of programs achieved within appropriate time.
It refl ects the in - process timelines of the program portfolio, individual programs, and projects within a program as the metric acts as an early warning signal for a
company ’ s time management system. ”
Then, he went on to say, “ Each metric shows one number for the month and one for the cumulative value, where applicable. Quality of the monthly status,
cumulative value, and overall trend are shown by colors. A green status signifies progress as planned, a yellow status indicates a heads - up to management of a
potential problem, and red requires management intervention. We have tested the time needed to read and interpret the report with our executives, and they need
an average of three minutes. ”
Al took a long look at the one - page report, paused, and said, “ Okay, let me test it. ”
Discussion item
1. Do you agree with the metrics suggested on the one - page report? Why or why not?
317
OSSOP
Sabin Srivannaboon
WHO ’ S WHO?
Mr. John Jackson was Executive Vice - President of Information Technology Group at one of the leading life insurance companies in the region. He was a renowned
programmer who had more than 25 years of work experience in various technical fi elds, and had been with the company since his career began. Two years ago he
was promoted to a management position after the sudden and tragic death of the previous vice - president, who was also his mentor.
As the new executive, John oversaw the big picture of software projects, and led more than 70 programmers, computer engineers, and technicians in his
department. Historically, more than 30 software projects were executed each year mainly to support the company ’ s business units. However, more than half of
them failed either because they were completed late, over budget, missed func- tions, terminated early, or combinations of any of these. John urged changes as
he saw a lot of room for improvement, one of which was definitely in the project management area. He decided to hire an experienced consultant to give him
recommendations on how to start.
Mr. Sammy Lee was a young independent consultant, and expert in project program management. He was hired to help John develop a project management
methodology and a simple tool to track all project status in the IT department. Sammy was born in Singapore, and was not familiar with the corporate culture at all.
THE COMPANY BACKGROUND AND CULTURE
In 1969, the company was founded as one of the very fi rst locally owned businesses with the absolute goal to provide security and protection for families in the region. The
company underwent major changes in the organizational structure and management system during the 1980s, leading to a new foundation for modern and effi cient opera-
tion in many respects. The company has seven divisions including claims, human resources, fi nance, investment, and accounting departments, a medical center, and an
information technology group. In 2008, the company assets were around 300 million, maintaining their ranking as the leading life insurance business in the region.
318 CASE STUDIES
Under John ’
s supervision, the Information Technology Group ITG focused on solving the challenges faced by growing insurance businesses. The
ITG organization was structured into two main subgroups: software and hard- ware teams, with a total of 80 employees. The uniqueness of the ITG laid on a
strict policy of using open source software, which was the original source code available to the general public for use andor modification “ free of charge. ”
In particular, no commercial software, especially those with license fees, was allowed in the company at all. John called it the “ OSSOP ” policy O pen S ource
S oftware O nly, P
eriod. And because of the OSSOP policy, the company saved millions of dollars last year. And the CEO was very pleased to see the
OSSOP continue.
FIRST MEETING WITH THE EXECUTIVE John: I ’ m very pleased that you decided to take this job. Our group is in need
of fresh ideas, especially with regard to the implementation of a system for project management. I am sure you can help us.
Sammy: Thank you. It ’ s my pleasure. First of all, if I understand the con- tract correctly, you ’ d like me to develop project management methodology and
tools in your group for improved business results. You ’ d like to standardize the way your project managers manage their projects, and be able to regularly
track the status of each individual project. Is that right?
John: Yes, currently we do not have a systematic tool or standard for managing projects. Each manager manages his or her projects from personal experi-
ence. And if you notice, there is no person designated as “ project manager ” in my group. Senior programmers who have more than 10 years of work
experience are usually assigned to be responsible for success of the projects. That ’ s the way we have been doing it. But now I want to change it. Here are
the formal documents that we have for project management. Not a lot, as you can see. Hopefully, they will give you some ideas of our business and how
we run it.
Sammy: Okay, so let me go through these documents tonight. Also, I ’ d like to talk to your people sometime this week. Would you please arrange that
for me?
John: Sure, I can do that.
Three days later, Sammy met seven people who had assumed project manager roles. He discovered several interesting things. First, each manager had his or
her own distinct way of managing projects. Second, all of them claimed that they had important projects, and the resources were inadequate. Third, there was
an inconsistency among the tool utilizations. Some managers used open source
Program Monitoring and Controlling Process 319
spreadsheet programs
1
to schedule their projects. Many did not do scheduling at all. They simply forecasted the schedule based on their experiences. Why didn ’ t
they use an open source program to do that? Mainly because they believed open source software was not sophisticated enough to do scheduling. Their complaint
was “ It ’ s darn slow ”
Sammy learned from the interviews that John held the monthly meeting to get project status reports from all managers, and that was the only meeting asso-
ciated with project management. If there was an urgent problem that couldn ’ t wait, most managers went directly to John ’ s office and requested support infor-
mally. Most of these were sorted out, but some weren ’ t because as an executive vice - president, John was very busy. What happened was that some issues were
neglected, and so no follow - up was initiated in many cases, especially those with low priority projects. Of course, this was not John ’ s fault. Simply, it was the
system and approach that prevented John from providing support to everyone every time it was needed. Fortunately, John was more than ready to make a move.
In fact, it was the best time to make changes because people perceived this time as crisis, due to the high number of projects that failed last year. And with crisis
often came opportunities.
SECOND MEETING WITH THE EXECUTIVE Sammy: Now I understand both your concerns and your people ’ s concerns.
Overall, I think your managers are frustrated with the speed of open source software for project management simply because it ’ s relatively slow. They ’ d
actually like you to consider purchasing commercial software licenses because they believe the commercial ones are much better. But they didn ’ t want to say
it out loud because they know it is against your OSSOP policy. They wanted me to talk to you.
But you know what? I don ’ t think commercial software is so much different from open source in terms of the critical features. Although not sophisticated,
many open source software can very well handle constructing a network dia- gram, identifying a critical path, and so on. So I believe your people think
open source software is slow because they don ’ t know how to do scheduling properly. They ’ ve never been trained. This is fi ne. I can set up a training
session for them.
But fi rst of all, I strongly suggest you to consider establishing some criteria for project classifi cations. Your managers don ’ t have consistent ways of manag-
ing their projects. Big or small projects were managed differently depending
1
In this case, the term “ program ” refers to written programs, procedures, or rules pertaining to the operation of a computer system, and wasn ’ t used to indicate a set of interrelated projects.
320 CASE STUDIES
on each person ’ s experience. To develop and implement project management methodology, we need to have a documented approach for performing project
activities in an accountable , consistent, and repeatable manner. We need eve- ryone ’ s buy - in on this.
According to the information I learned from the interviews, I would suggest dividing your projects into two groups. One group is called “ high priority ”
project bucket and the other “ low - to - medium priority ” project bucket. And we can use these criteria to fi lter our projects:
Business Alignment Regulation - related Effort
Security Impact to IT System Business Impact on a Large Scale in Terms of Company Revenue
These criteria were identifi ed during the interviews days ago, waiting for your approval. Any projects that fi t into one or more of these criteria will be
called the “ high priority ” projects, and these are what we need to pay attention to the most. Those that do not fall into any of these criteria, which are the
majority, we ’ ll call them “ low - to - medium priority ” projects. I drafted the ini- tial guidelines for managing these projects. Please take a look.
Guidelines for a Low - to - Medium Priority Project Subject to Change
1. A project manager is required to identify an expected completion date. 2. A project manager is required to report the status at the end of the project life
cycle. 3. A Gantt chart is optional.
Guidelines for a High - Priority Project Subject to Change
1. A project manager is required to identify major milestones and dates and expected completion date for a project.
2. A project manager is required to report the status at each major milestone. 3. A Gantt chart and critical path determination are mandatory except if a proj-
ect has a very short timeline less than two months for software development projects and three weeks for hardware projects
John: I think we will have to refi ne it a little. Let me call a meeting with my people next week. But this is a good start.
Sammy: Sure. I ’ d like everyone to get involved and agree on the approach. Second, I ’ d like to recommend a concept of project dashboard as the monitor-
ing and controlling tool for all projects. The dashboard concept has been widely used recently as an indicator to show the status of each project using colors.
● ●
● ●
Program Monitoring and Controlling Process 321
Basically, the commonly used colors are green, yellow, and red, like a traffi c light. A green means projects are doing fi ne. A yellow indicates a heads - up.
And a red means management help is immediately needed. We can also use as many colors as you wish. There are many commercial software packages on
the market that do the work very well. But I know this is against your policy. So I suggest we develop one of our own on the spreadsheet see Table 17.1 .
Of course, you can add more information that you think appropriate to the dashboard like the project customers or the size of the project team. This is just
a draft. This dashboard should be stored in the network location that everyone can access. Each week, let ’ s say every Thursday, you require all of your project
managers to provide their input to the dashboard. Then, Friday morning you ’ ll be able to view the status of each project online.
John: How are we going to do this? If we store this dashboard in the directory that everyone can access, it means someone or everyone can mess with it.
Sammy: That ’ s true. So I recommend you assign someone to compile all the inputs from the project managers. Let ’ s say Project Manager 5
PM
5 is assigned to be responsible to collect the dashboard data from Project
Managers 1 to 4
PM
1 to
PM
4.
PM
5 will put the collected information on the dashboard every week. Once the fi le has been updated, it will be made as
Table 17.1 Dashboard Example
Project Brief Scope
Status If Yellow or Red,
Explanation Corrective
Actions Are Needed
Priority Responsible
Person Project
Manager
Expected Finish
Budget
Barcode Initiative
Create a barcode
system to store
employee information
and use with the employee
badges G reen
High priority
Mr. John Doe
December 2009
76,000
Online Statement
Create an online
system for customers
to view the statement
and request for help
Green Low - to -
medium priority
Ms. Jane Doe
September 2009
62,000
322 CASE STUDIES
read - only before being saved to the network to prevent further corrections and or accidental modifi cations. Then, PM 5 will send a notifi cation to you that the
dashboard is ready to be viewed. This is also a way of limiting the requirement changes during the development phase without your approval. Here is the idea
see Figure 17.1 .
I also strongly encourage opening this dashboard to your customers. They are internal customers, right? So they should not have any problem in accessing
this fi le, if you grant them access. You know, there ’ s a lot of research iden- tifying customer involvement as one of the top success factors in software
development projects. This dashboard will be one way to increase the degree in which the customers will get involved. They can come to the dashboard any
time, and if they have questions or suggestions for your project teams, they can contact your teams directly.
John: Okay, that sounds doable. Let me call a meeting, and see what my people think about it.
Discussion items
1. In managing software projects, to what extent do you agree or disagree with the OSSOP policy? Why?
2. What do you think would be the next step? What would be the team ’ s reaction to the new approach to project management tools?
Dashboard read-only Compile and post summary
online shared drive Send notification to
management when dashboard is ready every week
Send notification to users when dashboard is ready
every week
Clarification involvement
Support help
Each person sends dashboard updates to Project Manager 5
Project Manager 1
Project Manager 2
Project Manager 3
Project Manager 4
Project Manager 5
Management Users
Figure 17.1 Reporting Concept
Program Monitoring and Controlling Process 323
3. Do you think Sammy ’ s recommendations would work? How would you amend these recommendations? What sort of additional channels could be used to
make the dashboard more visible in addition to storing it on the network drive?
4. What would be the major challenges in implementing the project classification method and the dashboard concept for monitoring and controlling purposes?
How would you overcome such barriers?
324
That Which Is Not Earned Is Never Valued
Sabin Srivannaboon
DXT
Famous for its reliable service and low price campaigns, DXT was one of the well - known mobile operators in the area. The company customer base comprises
prepaid customers, and it was doing well in this territory. To take the company into another level, the management team started looking at expanding the com-
pany business into an uncharted area — the postpaid customer segment.
DXT was a program - driven company. Last year, DXT initiated more than 40 programs, addressing various issues from the organizational structure to the
competition perspectives. This year, many programs were dedicated to the post- paid customer segment as efforts in diversifying the company business. However,
the postpaid customer segment was something that DXT wasn ’ t familiar with. And the company was still unclear as to what competitive advantage it would and
should provide to its postpaid customers. As a result, several programs were mov- ing in different directions, and the company ended up nowhere. The deadlines
for many programs were clearly defined from the beginning. Nevertheless, DXT failed to provide a clear idea of what kind of strategies and actions they really
wanted to see. Eventually, many programs failed. The lack of the alignment seemed to be a major issue at DXT these days.
XTRA AND THE EARNED VALUE CONCEPT
Xtra was a program that was carried out at the end of the year. Because of its strategic importance, the program delay wasn ’ t acceptable. To make sure the pro-
gram would be completed on time, the program team decided to use the Earned Value concept. Although it was a good intention, the program team faced one big
challenge: the earned value concept had never been implemented in the company before And as one could expect, the team ran into multiple problems and diffi cul-
ties not only in managing the program itself, but also understanding and using the earned value concept.
Program Monitoring and Controlling Process 325
Figure 17.2 is the Earned Value Chart of the recently closed - out Xtra program. The program objective was to develop a set of marketing projects for DXT ’ s
postpaid customer segment over a period of three months.
WHAT WENT WRONG?
Trying to understand what went wrong and the earned value concept better for future programs, the team looked back at the history of the Earned Value Chart.
Although the Xtra program status appeared to be ahead of the schedule and budget plans at the beginning, the turning point was around December 21, the
long vacation period, because of a lack of the company ’ s clear direction. Since then, things got worse as the program progressed. As an effort to recover the pro-
gram status, the Xtra program team tried to cut down several program scopes with hopes of improving the earned value. But problems never ceased coming. In the
end, the program was not fully able to recover, and less work was accomplished than planned. In other words, the program was not able to deliver its full results.
Eventually, the program was called off. At the termination time February 22, the program was behind both schedule and budget. The Xtra program ended up
spending 10,000, but only accomplished 8,600 worth of work, while the fore- casted budget at completion was 13,000 March 8.
One major lesson learned was that in implementing the earned value concept both the Schedule Performance Index SPI and Cost Performance Index CPI
Figure 17.2 The Earned Value Chart of the Xtra Program
Dec 7 Dec 14 Dec 21 Dec 28
Jan 4 Jan 11
Jan 25 Feb 1
Feb 8 Feb 15 Feb 22
2,000 4,000
6,000 8,000
10,000 12,000
Earned Value Actual Cost
Planned Value
326 CASE STUDIES
were important indicators to watch, but the CPI was clearly the more sensitive factor because a poor CPI was likely to be nonrecoverable. The program team
should have monitored closely the trend of the CPI throughout the program life cycle. The SPI, on the other hand, was more important during the early phases,
but became less significant as the program neared completion.
Discussion items
1. Analyze the program history and calculate the program schedule performance index SPI and the program cost performance index CPI at different major
points in time of the program life cycle. 2. What could have been done when the cost and time overruns were detected?
3. What would be the major challenges in implementing the earned value concept? How can such challenges be overcome?
4. Why does the SPI become less significant as the program neared
completion?
327