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 • “_____” 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

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 don’t understand, hire a consultant • if your computer personnel can’t or won’t explain, replace them

12. 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

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 can’t 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 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

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]