Although attempting some different project management efforts will increase the risk to the project, where that risk can be appropriately managed, the project manager should be willing to build a case to try some new approaches. Those approaches need not be radical. The idea should be to begin the process of demonstrating the value to the entire organization of moving into new project management areas.
Some of those changes are going to succeed, and some are going to fail. However, when the people within the organization come to realize that different project management approaches will produce additional benefits, the risk will prove to have been worthwhile.
CONCLUSION
A primary imperative of a PMO is to raise a project’
s visibility. A clear and direct line
from the project manager to a high-level manager and emphasis on project success
greatly increase the chance for actual success. Although responsibility for a project rests with the project manager, in the PMO structure, senior level management shares that responsibility and can positively influence a project.
When a senior manager assumes an important role in project management, many ancillary, unproductive issues that normally arise can be eliminated. People are less willing to raise objections and more likely to avoid conflicts if they know senior management may be involved.
Is a PMO the ultimate IT project management panacea? The answer, of course, is no.
No matter what approach is used, managing IT projects successfully involves hard work and risk. However, a properly funded and supported PMO can bring improvement to the process of managing IT projects. Specifically, a PMO can reduce the levels of project tension and risk. There is also an opportunity to begin to set a course for the continued improvement of project management.
When a PMO successfully delivers its first project, customer attitude about IT will begin to change. As people in the IT department, the business units, and at the senior management level begin to understand that higher levels of IT project performance are attainable, support for the PMO and in turn for the IT effort grows.
Moving to those higher levels takes time, patience, and persistence, but doing so is worth the effort.
It can be argued that a PMO adds expense to the project. That argument is correct; a PMO is not going to be free. The costs associated with the PMO are going to reach beyond that of dollars. The stress of using new approaches, the effort required to sell, install, and implement the PMO, and the tension associated with the cultural changes brought about by the PMO all have to considered as costs. However, the benefit to be found in the effective use of a PMO quickly negates any concerns about unnecessary additional expense. A PMO is an effective tool to improve the delivery of IT projects. Organizations that adequately fund and support PMOs find they have made the right choice.
Chapter 44: Creating and Implementing a
Balanced Measurement Program
Dana T. Edberg
OVERVIEW
It is still unclear why many information systems (IS) projects continue to fail, and why some succeed. Understanding the reasons for project success or failure, however, provides IS managers the information they need to form actions that enable the IS function to move forward and improve. The best way to gain this necessary knowledge is from a comprehensive IS measurement program.
Measurement is sometimes viewed as an objective in itself rather than as a way of supporting organizational goals. Much of the available advice on the application of measurement to the software development and maintenance process focuses on the intricacies and integrity of specific forms of measurement rather than on understanding the strengths and components of a comprehensive IS measurement program. This chapter focuses on the latter by describing a flexible measurement framework adaptable to specific organizational requirements. The chapter:
§ Explores the concept of a measurement program
§ Uses the balanced-scorecard structure to develop a framework that serves as a guideline for the measurement procedure[1]
§ Divides the measurement procedure into manageable components
§ Provides guidelines for the development and successful implementation of a measurement program
It has been said that the best way to understand the real behavior of software development and maintenance is to institute a measurement program that helps clarify patterns and guides decision making.[2] Measuring key attributes of software development and maintenance reveals behavior patterns that can be analyzed and interpreted to devise methods that better control and improve these functions.
[1 ]R.S. Kaplan and D.P. Norton, “Using the Balanced Scorecard as a Strategic Management System,” Harvard Business Review, January-February 1996.
[2 ]L.H. Putnam and W. Myers, Measures for Excellence, Englewood Cliffs, NJ: Yourdon Press, 1992, p. 11.
WHAT IS A MEASUREMENT PROGRAM?
A measurement program is designed to help people understand and interpret the processes of an organization. No company, for example, would dream of operating without a way of tracking and analyzing its financial transactions. A financial accounting system is the fundamental data collection process within the financial measurement program of an organization. One measurement used by accountants in
this program is the accounts- receivable turnover ratio. This ratio indicates how well assets are used by determining how many times accounts receivable is turned over each year. Calculating this ratio requires a system that collects the net credit sales and the average accounts receivable for the organization.
Although executives would not ask a credit manager to improve operations without first determining the current and potentially optimum accounts-receivable turnover ratios, they frequently ask IS managers to improve operations without any idea about important current and projected data and ratios. Whereas extensive computerized tracking systems support the financial and managerial measurement systems that underlie the operations of an organization, IS managers are left with intuition and guesswork to control their part of the organization. The historical lack of systems to track and analyze key characteristics of the IS function sets the function apart from other aspects of business operations. Cutting costs or enhancing productivity is thus especially problematic in IS because it is usually accomplished without a detailed picture of expected versus curre nt operations.
A measurement program spans the past, present, and future of company operations.
Data from past operations is used as a historical baseline to measure present and future processes and projects. Present tasks provide current collection opportunities and data that is analyzed against the historical baseline to guide improvements in future performance. A measurement program thus consolidates data from the past and present to provide the insight that helps IS managers take action for future improvement.
A measurement program requires the formulation of specific, quantifiable metrics.
Metrics are quantitative values obtained by measuring characteristics of a system or process. A metric is a piece of information that is analyzed, interpreted, and used to monitor progress toward improvement.
GOALS OF A MEASUREMENT PROGRAM
One of the most frequently asked questions about an IS measurement program is,
“What are the best metrics?” A more appropriate question is, “What are the goals of IS and how can they be measured?” Understanding and defining the goals of an IS
organization help clarify the metrics that are a part of the measurement program.
These goals, and the related goals of the measurement program, must be delineated before the counting begins.
Focusing on goals rather than on metrics is important for several reasons. People notice what is measured in an organization and frequently modify their behavior to make those measurements appear more favorable. Although laboriously counting the number of lines of code written per programmer per day encourages programmers to write more code and results in a lot of code, the code may not solve business problems. Tracking each computer development project and painstakingly updating visibly placed Gantt charts may prod employees to deliver systems on time, but the systems may have many defects that make them difficult to use or maintain.
Surveying the satisfaction level of computer users may result in actions that produce happy users, but it could also have the effect of generating a costly and inefficient systems development and maintenance process.
Measurement helps to highlight specific areas in an organization and encourages people to focus their attention and energies on those areas. To leverage this measurement spotlight, IS managers should identify a set of combined goals that achieve the objectives of the organization. Once goals are established, managers should identify specific questions to be answered, which, in turn, leads to the metrics to be collected. This structure is termed the goal/question/metric (G/Q/M) approach.[3]
[3 ]V.R. Basili and D.M. Weiss, “A Methodology for Collecting Valid Software Engineering Data,” IEEE Transactions on Software Engineering, 10, no. 3, 728–738, 1984.
THE GOAL/QUESTION/METRIC APPROACH
The success of the G/Q/M approach is exemplified by the experience of the Motorola Corporation. Managers at Motorola identified seven goals they believed would improve their systems development organization.[4] For each goal they defined specific questions that needed to be answered to determine whether improvement had occurred. Each question was then defined in terms of an analytical equation, and the variables in the equation were div ided into specific metrics that could be collected. For example, one goal was to increase defect containment. The managers defined the following two questions and related metrics to evaluate progress in this area: