Managing IT Personnel and Projects William A. Yasnoff, MD, PhD Oregon Health Division.
-
date post
22-Dec-2015 -
Category
Documents
-
view
215 -
download
1
Transcript of 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
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
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
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)
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 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)