New Directions in Project Management by Paul C. Tinnirello

§ Reporting arrangements § To CEO, to a functional head, to a steering committee, to a subunit head

§ Organizational

§ Stand-alone, in a functional department

positioning

§ Projects in scope

§ All, major, specific type (e.g., merger), one

department or business unit’

s projects

Design Factors

Alternatives

Organizational Factors

§ Ownership of resources § PMO leaders, all project managers, all project resources

§ A permanent or

§ Permanent, temporary

temporary office

§ Size and budget

§ From just PMO specific costs and resources to all

project resources and costs

Human Resource Responsibilities

§ Recruit ment and

§ Project managers, specialist staff, all project

selection

resources

§ Training and

§ Internal training, training vendor management,

certification

standard setting, accreditation

§ Appraisal and promotion § Provide templates for project management staff, facilitate process, coordinate

§ Providing resources to § Provide project managers, provide teams, projects

provide all project resources, maintain repositories

§ Time recording

§ Implement, manage, analyze

§ Career planning

§ Support individuals, support organization

§ Personnel

§ Manage vacations, sick leave, salaries, bonuses

administration

§ External vendor

§ Manage recruitment agencies, service providers,

management

consultants, hardware and software suppliers

§ Counseling and

§ Formal, informal, new project resources, all

mentoring

project resources

Responsibilities for Setting Project Management Standards

§ Setting project

§ Define project management and project life cycle

management

standards, define methodologies/processes to be

methodologies

used

§ Providing templates

§ Charters, status reports, risk assessments,

budgets, issue logs, post-implementation reviews

§ Providing project

§ Templates, software tools, intranet sites

management tools

§ Providing repositories

§ Computer directories, project documentation,

best practices, project deliverables

Project Execution Responsibilities

§ Risk and issue

§ Set standards, facilitate, conduct, control

management

§ Impact and change

§ Set standards, facilitate, conduct, control

management

§ Communication

§ Among projects, between projects and other

parts of the organization, executive updates,

newsletters

§ Project auditing

§ Formal, oversight role, with internal audit or

Design Factors

Alternatives

Organizational Factors

independent

§ Focus on major or

§ Major, specific type (e.g., merger)

special projects

Responsibilities for Business Strategy

§ Collection of initiatives § Provide standards and templates, facilitate, coordinate or manage

§ Project evaluation

§ Provide standards and templates, facilitate,

coordinate or manage

§ Project prioritization

§ Provide standards and templates, facilitate,

coordinate or manage

§ Project planning and

§ Provide standards and templates, facilitate,

scheduling

coordinate or manage

§ Project approval and

§ Provide standards and templates, facilitate,

funding

coordinate or manage

§ Project monitoring and § Provide standards and templates, facilitate, controlling

coordinate or manage

§ Project portfolio

§ Provide standards and templates, facilitate,

management

coordinate or manage

The checklist can be used by considering each of the factors in the left-hand column and inserting the design alternative that meets the business needs of an organization.

In many cases, there will be responsibilities that are not required. There are many possible alternative processes for completing the checklist. For example, it could be completed by an executive setting up an office; it could be completed in a workshop setting by a cross-functional group interested in designing a PMO; or it could be used as research tool by a group given the responsibility of designing a PMO.

CONCLUSION

This chapter has discussed a wide variety of factors that should be considered in designing a PMO. Undoubtedly, the list is not comprehensive — in fact, it is unlikely that it could be possible to identify all the factors that could be relevant to all organizations. However, the list does include a major set of factors that are relevant to designing PMOs. Every organization will have its own set of requirements. By considering the factors discussed, an organization has the opportunity to systematically choose a set of design factors that will help it meet its requirements at a given point in time.

The design possibilities for PMOs are almost limitless. A PMO can be designed to have quite restricted responsibilities; or a PMO can be established to have a major role in the planning, controlling, and coordinating of an organization’

s portfolio of

projects and managing its project resources. By systematically evaluating the design possibilities, an organization can quickly choose a design that meets its needs.

Chapter 41: Assessing the Real Costs of a Major System Change

Brian Jeffery

OVERVIEW

The widespread assumption of the late 1980s that downsizing from mainframes would reduce IS costs for just about any business sparked what has come to be an increasingly confusing debate about the costs of computing. Today, evidence from a wide range of sources challenges this assumption. Users have become increasingly disturbed about the high costs of decentralizing IS resources. There is also a growing realization that the cost structures of mission-critical systems have remarkably little to do with underlying technologies.

As user experiences with major platform changes have shown, no one system is inherently more or less expensive than another. Real costs depend greatly on the applications and workload profiles of individual organizations. Cost profiles vary by industry, by type and size of business, as well as by geographical location.

Underlying hardware and software technologies are also less important than the way the IS department is organized, the quality of IS management and staff, and the efficiency with which IS resources are used, including the effectiveness of cost accounting and control procedures. IS managers who are considering a major system change involving new computing platforms need a better understanding of IS

cost structures and how these structures change over time. Lack of understanding of these areas can result in a business applying the wrong solutions to the wrong problems — and wasting a great deal of money.

This chapter discusses the key factors affecting IS costs in any business. It offers IS

managers suggestions on how to avoid common mistakes in forecasting the costs of computing and guidelines for using comparisons with other companies to determine real computing costs more effectively.

COMPOSITION OF IS BUDGETS

The cost of providing IS services to a business involves a wide range of items. These include not only hardware and software acquisitions, but also personnel and their associated costs, along with the c osts of maintenance, telecommunications, facilities, supplies, and various other related items and outside services.

A 1993 survey of corporate IS budgets in the United States conducted by Computer Economics, Inc., of Carlsbad, California, found that the largest single IS cost item was personnel (42.1 percent), followed by hardware (28.9 percent), software (11.9

percent), and “other” (17.1 percent). The category of “other” included telecommunications, outside services, supplies, facilities, and miscellaneous items.

IS managers should pay particular attention to this category because although the individual items in it may each represent only a fraction of total IS costs, their

percentage is far from insignificant. Most of these costs remain the same or increase during major system changes.

Businesses often make the mistake of focusing solely on one-time investment outlays, primarily hardware acquisitions, rather than on longer-term operating costs.

This approach inevitably misses the main components of the total IS costs of the company. Organizations that make this mistake are likely to experience a U-curve effect, as illustrated in Exhibit 1. Costs may follow original projections while a new system is in the start-up and test stages, but as soon as the system enters production and handles real workloads, IS spending escalates rapidly as new costs are incurred.

Exhibit 1. U-Curve Effect of a New System on Total IS Costs

QUANTIFYING PRODUCTION WORKLOADS

In any production environment, a minimum six sets of workload parameters affect the capacity requirements of a system and hence its costs:

1. Numbers of active users

2. Volumes of data generated and used by applications

3. Type, size, and volume of transactions

4. Type, size, and volume of database queries

5. Type, size, and number of documents generated and printed 6. Batch workloads, including data consolidations, backup operations, and production printing

These parameters can vary widely within a company, as well as between different types and sizes of businesses in different industries. As a result, use of standardized, generic measurements for quantifying system performance is one of the most common causes of cost underestimates.

Because there is no such thing as a generic business, any valid computing cost comparisons must be specific to the needs of an individual business organization.

Most standardized measurement techniques have little relevance to the performance that will actually be experienced by users in any given production environment.

For example, much of the industry debate about millions of instructions per second (MIPS) is based on a fundamental error. Instruction sets, as well as the complexity and size of instructions, and the system processes that are instructed vary widely between systems. MIPS has no validity in a cross-architecture comparison. In addition, MIPS represents only a measure of CPU performance. In any real production environment, the performance actually experienced by users is influenced by hundreds of different parameters.

Measurements of transaction performance, such as TPC/A, TPC/B, or TPC/C, are based on stylized suites of software and workloads. These rarely correspond to the applications portfolios, transaction volumes, or workload characteristics of a specific business. Variations between different types of transactions have a major effect on capacity requirements, and hence on costs.

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115

Leave a Reply 0

Your email address will not be published. Required fields are marked *