Managing IT Personnel and Projects

William A. Yasnoff, MD, PhD

Oregon Health Division

Managing IT Personnel

Identifying Computer Expertise Common Pitfalls Team Organization User Involvement Selecting Technologies

Computer Expertise

Automobile Analogy– Driver– Race car driver– Weekend mechanic– Professional mechanic– Engine designer for GM

Computer Expertise - 2

Scenario: experienced driver designs new engine

Result: engine explodes Conclusion: engine design is risky Correct Conclusion: engine design is

risky in the absence of needed competence

Computer Expertise - 3

Empire Blue Cross– Dentist on Board of Trustees» installs image scanning system in his office

– Given responsibility for total redesign of Blue Cross information systems

– Result: $millions spent, system never works, business nearly fails

– Conclusion: image scanning is risky technology (?!)

Computer Expertise - 4

Look for Experience– Has the person previously done what you are

trying to do now? How many times?– Was it successful?– What was the role of the person?» programmer

» analyst

» designer

» project leader

Computer Expertise - 5 Look for Education– B.S.» programming skills» database design» project tools

– M.S.» completed at least one major project

– Ph.D.» developed significant new approach to solving a

computer science problem

Computer Expertise - 6 Pay Market-level Compensation or Better– Good computer personnel are $$– Failed computer projects are $$$$$$$$$– inadequate compensation is short-sighted– compensation information readily available

Some technical skills are in very high demand (e.g. network manager)– pay scale may be higher than manager

Common Pitfalls

“_____” can’t be done– rarely correct

– usually means» “I don’t know how to do ______” (ignorance)» “______ is too much work” (laziness)» “I don’t think I can figure out how to do _____” (fear)» “______ will cost too much” (inappropriate decision-

making)

– insist on understandable explanation

Common Pitfalls - 2

Failure to use consultants appropriately Reasons to hire consultant– very special expertise– unbiased viewpoint– deliver bad news to senior management– verify internal technical advice

Be sure your consultant really is an expert

Common Pitfalls - 3

Technical Obfuscation– common technique to control workload– computer personnel gain control

Computer concepts should be clearly explained– if you don’t understand, hire a consultant– if your computer personnel can’t or won’t

explain, replace them

Common Pitfalls - 4

Pride in Ignorance– “I’m computer naive and proud of it”

Learn about IT management– key element in public health management– increasing in importance– an essential competence for public health

managers– many good books available

Team Organization

Smaller is better– large teams have too many communication

paths Document everything– meetings, ideas, progress reports

Use technology– e-mail, voice mail, fax, electronic conferencing

Overcommunicate

User Involvement

Computer personnel need to meet with users

Facilitation of communication needed Manage expectations– promise only what can be delivered– keep users informed of progress

Selecting Technologies

After requirements understood– tendency to discuss these issues first– business requirements should drive technology,

NOT vice versa Evaluate multiple alternatives Avoid proprietary solutions, if possible Technical evaluations should be understandable Use consultant(s)

Selecting Technologies - 2

Avoid “bleeding edge”– production systems require proven methods

Recognize constant changes– may need to re-evaluate decisions later

Consider availability of personnel– high productivity tool is not helpful if you

can’t find someone who can use it

Managing IT Projects

Software Life Cycle Traditional Development Objects Rapid Prototyping User Involvement Political Obstacles Avoid Inappropriate Use of Technology

Managing IT Projects

MOST SYSTEM DEVELOPMENT PROJECTS FAIL

Rates of IT Failure are High

• 16.2% were “project successful” (software projects that are completed on-time and on-budget among

American companies and governments)

• 52.7% were “project challenged” (they were completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally

scheduled) • 31.1% were “project impaired” (canceled)

Source: “Charting the Seas of Information Technology” The Standish Group 1994

Key Elements in IT Projects

Time

Budget

Features

Software Life Cycle Development– 1/3 of total cost

Maintenance– 2/3 of total cost

Based on traditional development Lesson: user needs constantly changing– new system induces desire for changes– showing users possibilities expands their

conceptual framework

Traditional Development

Requirements Design Coding Testing Release Maintenance

Traditional Development

Based on obsolete assumptions– development is slow process– changes are difficult

Too slow– system may be obsolete before completion

Insufficient user input

Rapid Prototyping

Develop prototype as quickly as possible Review prototype with users– document suggested changes

Implement revised prototype Review with users again, etc. Iterative process– maintains user involvement– ensures usefulness of final system

Rapid Prototyping

Requires new tools and skills– high productivity: screens and databases– users shouldn’t have to wait too long

Requires new attitudes– computer personnel mostly writing

“throwaway” programs– need to convince all of wisdom of overall

process

User Involvement

Key success factor in system development

Nearly continuous with rapid prototyping

Assures user acceptance Users are able to assess a prototype– written system design hard for most users to

understand and review

User Involvement - 2

Ask users about benefits– listen carefully to what users want– these are key to a successful system

Users perceptions will change– prototype of system alters perspective– need repeated benefits assessment

Beware of benefits that development staff “imagines” (including you)

Objects

What is an object?

Independent, reusable software component designed to perform a specific process

Characteristics– reuse of code– building systems with connected components– platform independence (messaging)

Properties of Objects

Polymorphism– object responds differently depending on

type of data– e.g. “print” object treats text and graphics

data differently Encapsulation Inheritance

Properties of Objects

Polymorphism Encapsulation– All data and algorithms needed are within

the object– Only connection to rest of system is passing

data– Each objects acts independently

Inheritance

Properties of Objects

Polymorphism Encapsulation Inheritance– characteristics of data are passed along to

lower level objects (hierarchy)– e.g. “truck” objects inherits characteristics

of “vehicle” object

Advantages of Objects

Abstraction: hide complexity Corresponds well to real world More reliable systems Reusability of code Faster system development More flexible systems

Disadvantages of Objects New technology– evolving products– developing expertise

Competing Standards Reliability not yet proven Limited development tools– difficult to link to legacy systems

Substantial transition costs (staff training, software)

Reliable Software

Eliminate coupling between modules– content– common (OS/360)– external– control– stamp (same data structure; not global)

Reliable Software (continued)

Data coupling only = objects Reference:– Glenford J. Myers: Reliable Software

Through Composite Design (New York: Petrocelli/Charter, 1975)

Political Obstacles

Inertia Funding Changing Behavior

Political Obstacles: Inertia Stakeholders in status quo will be

formidable opposition Support for new system is usually lukewarm Understand who benefits from system

development failure– need to minimize possible impact– potentially displaced personnel need

reassurance (and perhaps placement assistance)

Political Obstacles: Inertia

New system should change business practices– creates threats to existing power structure– understand and work with potential power

shifts– recognize and expect hidden agendas

Political Obstacles: Funding Inadequate funding is manifestation of

opposition Do not attempt to pursue underfunded

projects– even if successful, will be failure– recognize clear signal that system is not wanted

Incremental funding tied to milestones helps to reduce risk

Political Obstacles: Funding

Information Systems are Expensive– hardware is very small part of cost– personnel is largest portion

Strategic Information System Decisions are Difficult

Political Obstacles: Behavior

New information system requires behavior change

Most powerful behavior modification technique is intermittent positive reinforcement– need early “success”– must provide real benefits to users– what they want, NOT what you want

Inappropriate Technology Use

Not all problems have a technology solution

Avoid temptation to apply technology when it cannot meet system requirements

Case study: – Immunization input from private providers

Reasons Projects Succeed

User involvement Management support Skilled, experienced project managers Clear requirements statement Comprehensive work plan Sound development methodology Prototyping Extensive Testing

Paradigm for Success

Behavior Modification– management– users

Minimize increments of change Use intermittent positive reinforcement– provide real benefits to users– what they want, NOT what you want

Managing IT - Summary

Know what you are doing Use competent personnel Use rapid prototyping to ensure user

involvement Assess and respond to political

challenges Know when to avoid technology

References

Tapscott D & Caston A: Paradigm Shift: The New Promise of Information Technology (New York: McGraw-Hill, 1993)

Ennals R: Executive Guide to Preventing Information Technology Disasters (Berlin: Springer-Verlag, 1995)

References - 2

Clemons EK: Evaluation of Strategic Investments in Information Technology. Communications of the ACM 34,1: 22-36, 1991. [handout]