Managing IT Personnel and Projects

1
Managing IT Personnel and Projects

• William A. Yasnoff, MD, PhD
• Oregon Health Division

2
Managing IT Personnel

• Identifying Computer Expertise
• Common Pitfalls
• Team Organization
• User Involvement
• Selecting Technologies

3
Computer Expertise

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

4
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

5
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
  (?!)

6
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

7
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

8
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

9
Common Pitfalls

• _____ cant be done
• rarely correct
• usually means
• I dont know how to do ______ (ignorance)
• ______ is too much work (laziness)
• I dont think I can figure out how to do _____
  (fear)
• ______ will cost too much (inappropriate
  decision-making)
• insist on understandable explanation

10
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

11
Common Pitfalls - 3

• Technical Obfuscation
• common technique to control workload
• computer personnel gain control
• Computer concepts should be clearly explained
• if you dont understand, hire a consultant
• if your computer personnel cant or wont
  explain, replace them

12
Common Pitfalls - 4

• Pride in Ignorance
• Im 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

13
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

14
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

15
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)

16
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
  cant find someone who can use it

17
Managing IT Projects

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

18
Managing IT Projects

• MOST SYSTEM DEVELOPMENT PROJECTS FAIL

19
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
20
Key Elements in IT Projects
Time
Features
Budget
21
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

22
Traditional Development

• Requirements
• Design
• Coding
• Testing
• Release
• Maintenance

23
Traditional Development

• Based on obsolete assumptions
• development is slow process
• changes are difficult
• Too slow
• system may be obsolete before completion
• Insufficient user input

24
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

25
Rapid Prototyping

• Requires new tools and skills
• high productivity screens and databases
• users shouldnt have to wait too long
• Requires new attitudes
• computer personnel mostly writing throwaway
  programs
• need to convince all of wisdom of overall process

26
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

27
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)

28
Objects
29
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)

30
Properties of Objects

• Polymorphism
• object responds differently depending on type of
  data
• e.g. print object treats text and graphics data
  differently
• Encapsulation
• Inheritance

31
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

32
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

33
Advantages of Objects

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

34
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)

35
Reliable Software

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

36
Reliable Software (continued)

• Data coupling only objects
• Reference
• Glenford J. Myers Reliable Software Through
  Composite Design (New York Petrocelli/Charter,
  1975)

37
Political Obstacles

• Inertia
• Funding
• Changing Behavior

38
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)

39
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

40
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

41
Political Obstacles Funding

• Information Systems are Expensive
• hardware is very small part of cost
• personnel is largest portion
• Strategic Information System Decisions are
  Difficult

42
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

43
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

44
Reasons Projects Succeed

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

45
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

46
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

47
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)

48
References - 2

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