IT Interaction Model Markus Silver The Implementation Process



















- Slides: 19

IT Interaction Model (Markus & Silver) The Implementation Process Initiation Build/Buy Introduction Maintenance Business Environment/ Firm Strategy Business Processes Organizational Structure and Culture IT Infrastructure Information System or Application (not just software) Use Adaptation Consequences: • Financial • Human Resources • Competitive Position • Future Flexibility

Systems as Planned Org Change Many parts of organization are affected • Resouces/authority/jobs are at stake • Politics and resistance are likely Need to adopt similar tactics/strategies • Always: Participation • Frequently: Co-optation • Occasionally: Managerial fiat

Cross-functional teams are needed System • • builders are responsible for: Technical quality User interface Overall organization impact Design and implementation process No single function can handle all this!

Who should be involved? Senior Mgmt IS HR Corporate Strategic Planning IS Steering Committee Middle Mgmt IS Project Mgmt User Project Mgmt IS Team Members User Team Members Supervisors & Operations

User involvement is key Users provide essential information User involvement tends to generate resources needed for org change: • “Buy-in” (or co-optation) • Committment User involvement tends to promote: • Increased satisfaction • Higher probability of success

Other essentials (Forsberg et al) Common vocabulary Teamwork • Goals, rewards, norms & expectations, support Project cycle (sequential activities) Project management (situational activities)

System Development Life-Cycle WARNING: The most expensive errors happen early. . . Requirements Design Code/Customize Testing Implementation Maintenance Time (1 -2 years for complex system)

Alternative models Spiral: Risk Driven approach • Evaluate risks at each stage • Respond to them The Vee (Forsberg et al) • Sequential activities • Situational activities

Risk-benefit perspective Project Risk High Low High Cautiously Examine Identify & Develop Low Avoid! Routine Projects Potential Benefits

Requirements analysis Problem definition: What are our needs? Feasibility: technical, economic, operational Information requirements are hard Possible outcomes: • Do nothing; leave well enough alone • Upgrade/extend existing system • New System Output: Project/system proposal

Make or Buy? To explore the “buy” option, use your requirements document as the basis for an RFP to major vendors. • Vendors can propose system designs • Vendors can perform tests to see if their product meets your needs We will discuss vendor selection again later in the semester

System Design After needs have been identified, still need to decide details of what system will do Says what is to be done, but not how to do it (that is left to programmers) Output: Design specifications • documentation (data tables, menus, screens, etc. ) • flow charts • data flow diagrams

Prototyping: design by trial & error Identify basic user requirements Create quick prototype Use the prototype Revise and enhance the protype Re-write the prototype (important, but often neglected) Good approach for complex situations where requirements are unclear

Customization Even packaged software requires customization Large Enterprise Resource Planning (ERP) systems (like SAP, Peoplesoft, Baan, etc. ) can have literally thousands of parameters that must be set. This is a significant effort

Coding/Testing Coding • Code walk-throughs & reviews are critical • More programmers will usually take longer Testing • Unit testing: pieces of the system • System testing: whole system • Acceptance testing: user “sign-off” tests, especially important for vendors/consultants

The Mythical Man-Month A “ 5 person-year” project takes more than 5 people for one year • Dependencies between tasks • Coordination overhead Adding people typically delays completion • If coordination is the problem, adding people makes it worse

Implementation Data conversion & Roll-out • Parallel systems: safe but expensive • Direct cut-over: risky but cheap • Phased approach (e. g. , by geographic area) Documentation User training & support

Production and maintenance Average breakdown of effort: • 20% debugging & emergency fixes • 20% changes in data, files, reports, etc. • 60% enhancements 50% of life-cycle cost An effective requirements/design process greatly reduces these costs

Planning is Essential Agood plan “simulates” the actual development process Need to measure progress against the plan • to detect problems (“variances”) • To initiate corrective action before your project turns into a runaway The harder it is to plan, the more you need to do it.