Exam Flashcards
- IT investments
Investing in IT is not a goal in it self – we make these investments to create some kind of business value.
Our job is to be able to optimize the outcome of IT investments.
- Proces performance
Value is created by changing the way work is accomplished
- Context / environment
The context impacts the possibility for value creation!
Country factors: General IT-level in a population.
Industry factors: The level of competition in the industry, the technical standard we need to follow
Firm factors: E.g. If the culture in the company is that it is really hard to make changes in the company. The projects before took a long time - this project will take a long time.
E.g. If the people in the company have a low technical skill.
If people are critical of changes and having a hard time changing behavior
- Organizational performance
Proces from performace to organizational is not automatic
- Lag effects
Value creation can take years before we see the full effects.
How long is it actually going to take before we see any inpact on the performance?
If you do an evaluation straight after the project stopped the project will be a failure. It takes years before the system and changes will be effective and implemented. People do not want to change their work methods - therefore implementation takes time.
- The effects of IT in companies are substantially larger when mearued over longer time periods.
- One interpretation of these results is that short-term returns represent the direct effects of IT investment (e.g. simple optimiation of individual tasks)
- While the longer-term returns represent the effects of It when combined with related complementary investments in organizational change (e.g. new business processes)
The impact of IT investment can (for various reasons) take years to become visible – evaluations of project outcome in term of value creation right after project closure will often lead to disappointing outcomes.
- Common mistake in society with new systems
They believe that new systems are not designed to fit the way that peple are working. That is wrong. Systems should be designed to be aligned with new process of working instead of the old way.
- Information systems:
A system which assembles, stores, processes and delivers information relevant to an organization in such way that information is accessible and useful to those who wish to use it. e.g. BI system, e-commerce
- IS investment
Investments in IS, IT managers and IT specialist.
- Complementary investments
Investments in varoius forms of organizational change that complements investments in IS. E.g. investment in process change or restructuring of the organization.
- IS business value
IS the impact of investments in particular IS assets on the multidimensional performance and capabilities of a company, complemented by the ”ultimate meaning of performance in the economic environment”.
Benefits gathered using IT systems to work in a different way than we do today.
- Contextual factors
Factors related to the individual company, the industry or the society that somehow impacts the possibilites for creating value from IS and complementary investments.
- Competitive advantage
A company is said to have competitive advantage when the value that is created in an economic exchange in which the company takes part is greater than the value that could be created if the company did not participate in the exchange.
- Sustainability
A condition where a company’s competitive advantage resists erosion by competitive behavior. This requires that a company possesses some barriers that make imitation of the strategy difficult. Competitors face significant challenges in acquiring, developing, and using the resources underlying the value creating strategy.
- Co-specialization process:
The combination of IS and non-IS investments.
• Making the “system” or “cluster” of mutually reinforcing organizational changes based on IS and non-IS resources is an example of co-specialization.
• Lack of proper co-specialization can explain why many large scale IT projects fail, while successful information technology adopters earn significant rents
• There is a great deal of individual variation in firm’s success with IT: They might be good at buying or developing systems – but bad at co-specialization.
• Co-specialization is very difficult e.g. because it requires the collaboration of people with different backgrounds from different departments.
- Mutually reinforcing organizational changes
Structure, task, people and technology
- Design of organization
Hierarchical organizational structures can reduce communication costs because they minimize the number of communications links required to connect multiple economic actors, as compared with more decentralized strcutures.
- Internal Vertical integration
Producing the required inputs in-house.
Used to be the best option for securing competitive advantage. That is no longer the case.
• Benefits can be realized when interorganizational systems are combined with new methids of working with suppliers such as just-in-time delivery.
- External resources
New business models based on external resources owned by other actors like Uber and Airbnb.
- The barriers to erosion (4)
For barriers to erosion fully capture the determinants of sustainability in the context of IT-dependent strategic initiatives: • IT resources barrier • Complementary resources barrier • IT project barrier • Preemption barrier
Underpinned by their respective response-lag drivers, contribute independently, or in combination with one another, to enable a firm to sustain competitive advantage.
- Hard-to-accelerate-processes (2)
Two processes contribute to reinforce barriers to erosion:
• Organizational learning (A person can learn - and so can organizations –> Organizationel learning)
• Asset Stock Accumulation
These are subject to time compression diseconomies and therefore cannot be accelerated by the company.
- Organizational learning (hard-to-accelerate processes)
The capacity or processes within an organization to maintain or improve performance based on experience
• A company can develop superior capabilities through learning mechanisms, including repetition, experimentation, and the analysis of mistakes.
• Depends on “path dependency”: It depends on our history and previous experience – and cannot take place without appropriate preconditions.
- Asset stock accumulation (hard-to-accelerate processes)
The process by which a company builds up a ressource over time.
• E.g. Google (specialized IT infrastructure) or Facebook (Specialized information repository)
• Only the company that has aquired or developed the precursory resources can begin the accumulation process.
- IT Ressource Barrier (barrier to erosion)
IT assets: o IT Infrastructure o Information repository • IT capabilities o Technical skills o IT Management skills o Relationship asset
- Complementory resources barrier (barrier to erosion)
Co-specialization between IT and non-IT investments that create a competitive advantage
Internal (Scale of operations / market share) + external resources (Brand recognition, image, trust)
- IT Project Barrier (barrier to erosion)
Divided into 2 categories: IT Characteristics (technology) • Visibility • Uniqueness • Complexity
Implementation processes
• Implementation process complexity
• Degree of Process Change
- Preemption barrier (barrier to erosion)
Switching cost: 3 sources of switching costs: 1. Co-specialized tangible investments, 2. Co-specialized intangible investments, and 3. Collective switching costs
- Formalized methods
Methods as described in text books
- Method-in-action
The methods actually used by developers.
- Developers
Business analyst, programmers
- Roles of methods
Different rational and political roles
- Development context
The context in which the system is developed and used
2.Information Processing System
The new system
- Plan-driven development:
Discrete stages with a specific end product, stage-limited commitment, specialization, bureaucrazy, documentation. Used when uncertainty is low, or if complexity is high.
You always have to tailor the method to the specifik context you are working in.
- Agile development
Short iterations, feature planning, dynamic prioritization, feedback and change. Used when unvertainty is high and complexity is low.
You always have to tailor the method to the specifik context you are working in.
- Characteristics of information system
Complexity: High complexity = Plan-driven
Solved vs. unsolved: If solved before = low uncertainty = Plan-driven
Mature vs. new technology: New = prototypes and more quality assurance = Agile
Systems and change: More change = Agile
- Strategies for change
Proactive: An opportunity might show up, and the organization changes the context before problems materialize.
Reactive: Organizations react to problems in the contexts as they turn up.
Problem-solving: Projects attempts to understanding the current business process, fix errors, and optimize the process using IS. Analysis play a big role.
Innovation: Change is viewed as a creative way to form a new context. We are not just fixing errors. Creativity and design plays a big role.
Innovation is high risk and hard.
Incremental: Change is accomplished in several small steps (related to problem solving)
Radical: More risk. Change is accomplished in major steps that fundamentally changes the context.
Radical changes are only done when it is absolutely necessary for the organization. We prefer incremental changes.
- System development life cycle (development process model) (Formal method)
Typically contains a series of development phases arranged in a certain sequence. The phases are typically concerned with planning, analysis, design, programming of systems.
Typically not the implementation, which is problematic because development and implementation are closely related. Like the waterfall model or an agile model.
- Information systems development method (Formal method)
A coherent and systematic approach, based on a particular philosophy of systems development, which will guide developers on what steps should be performed and why these steps are important in the development of an information system.
Like object oriented analysis & design.
Technique: How to do more specific task. E.g. how to illustrate a business process using a swimlane diagrams.
Tool: An instrument that might support a specific method or technique. E.g. A tool that supports designing E-R diagrams and generate databases.
- Rational roles (Formal method)
Reduce complexity: E.g. by dividing a complicated process into smaller and more manageable and less complex steps.
Facilitate project management: E.g. creating transparency by having developers do interim products that makes it possible to evaluate the progress.
Allow skill specialization: By defining roles and activities that can be allocated to specific developers.
Standardization: By having several projects in the same organixation work in similar ways, thereby making it easier to share developers and experience.
Economics: By improving productivity.
Learning: E.g. getting new employees integrated faster because they can read and learn how things are dine in this organization.
Quality: Reduce the reliance upon individual developer skills.
- Political Roles (Formal method)
Assure customers,
Legitimate specific ways,
Professionalization,
A power base
- Plan-driven (Formal method)
Requirements are stable
Technology is well-known and mature
Everything happens as one would expect
Not much new or unknown
We have done something similar before
- Agile method (Formal method)
Short iterations
Feature planning
Dynamic prioritization
Feedback and change
Teamwork
Customer collaboration
- Methods-in-action challenges
The major challenge is that our methods-in-actions have to be changed whenever the context changes, and this is one of the major reasons behind the many projects delays and budget overruns.
The problems:
Predictability: We have difficulties estimating how much time and other resources we need.
Costs: Development and implementation gets more expensive than originally expected.
Change: We have difficulties implementing the organizational changes that are needed to benefit from the new system.
Quality: New systems do often not work properly in the context they should support, users to not find the system usable.
Value: We have difficulties realizing the expected benefits from IT investments, maybe nobody actually takes responsibility for doing so.
Examples:
There is no single best strategy:
1. Alternative 1: The development of an entirely new system from scratch
2. Alternative 2: Buying/re-using some components and developing other components
3. Alternative X: The configuring of a standard application to fit a specific organization.
These are variations of agile and plan-driven development.
- Advise: If there is an application out there you can use - use it! Don’t develop a new system unless it the ultimately important.
Advise: If there is an application out there you can use - use it! Don’t develop a new system unless it the ultimately important.
- Developers (People really matter. Struggle to get the best possible people in a project)
Who are they
• Technical experts in computer science, programmers, database specialists, business analysts or change agents.
• Together they are multiple stakeholders working together in a cross-functional effort
• Both developers and users learn throughout the project. Difficult if not impossible to know all requirements up front.
Skills
• Ability to communicate and collaborate with client and users – must be able to explain technological issues to users and managers
• Analytical skills: being able to analyze and understand complex problems
• Creative skills: Design solutions to problems
• Compositional skills: Come up with new systems and join the existing system and the existing context into a whole system.
Motivation • Communication and motivation are vital • New technology • Ownership • Working with top management • Trust and autonomy
- System development life cycle (development process model)
Typically contains a series of development phases arranged in a certain sequence.
Use this type of model to benefit from previous experience and knowledge and to establish some kind of shared understanding.
- Tailoring
Adapting a general development process model to be used in a specific project.
- Simple model for simple jobs
The system development model that is used should be as simple as possible given the level of complexity involved.
- The waterfall model
When complexity increases:
A rational model for developing large and complicated systems.
- We understand the requirements
- We design a solution
- We make a solution
- And test it and remove errors
However it seldom works in practice.
We have to go back and make som adjustments to make it work.
- Concept: Re-work
When we waste time because we have to go back in the proces and remake some processes to fix the problem.
- How to deal with problems related to finding problems late (The waterfall model)
• Introduce a preliminary design phase before analysis with the purpose of identifying the technical constraints that the analysis have to respect. This will increase the technical feasibility of the development effort.
The idea of doing more analysis and more design only works in stable conditions.
• Document the design carefully. The argument is that documentation supports communication and coordination and makes it possible to monitor progress. Force designers to make design decisions, makes quality of design transparent and reduce cost during test, operations and maintenance and reduce reliance on specific programmers.
• Do it twice. When developing something unfamiliar – do it twice. Build a simulation (pilot model) to gain experience. Focus on critical issues.
• Plan, control and monitor testing. Use independent testers, review before testing, test all logical parts in a program, test again when identified errors have been fixed.
• Involve the customer. Important to involve the customer in a formal way so that they have committed themselves at earlier points before final delivery.
- Prototyping
The traditional development paradigm does not respond well to increased complexity and uncertainty. Tendency is to increase controls and to require more precise requirements definitions which does not fit this specific context.
Users recognize potential benefits of new applications but are not able to describe the necessary details of a solution. We can’t get better requirements just by asking questions.
“You want to try are car before buying it”
- Iterative development (Prototyping - 4 steps)
- Identify the user’s basic information requirements: Focus on data and process
- Develop: A purposely limited prototype is developed in a short timeframe. Design and implementation are accomplished by building a working system
- Implement and use the prototype system: “Hands-on” use of the system provides experience, understanding, and evaluation.
- Revise and enhance the prototype system: Undesirable or missing features identified by the user must be corrected.
- The nature of prototyping (4 pro’s)
- “True evaluation”: The most effective representation possible since it enables evaluation of proposed design in context.
- Accomodates change: Change in both the user and systems environment
- Development and operations mixed: If user environment is unstable or extremely dynamic, development iterations could continue indefinitely. In such situations: Traditional systems methodologies are integrated by the prototype model.
- In a more static environment where a prototype meets the user’s full needs, it may either serve as-is or be used to design specifications for a more efficient information system.
In a stable environment, the decision to replace an operating prototype system with a traditional system can be made with relatively simple breakeven analysis.
- Users can become co-designers (prototyping)
- Users: Users play more active roles in prototyping than is possible with traditional development methods. They become system designers who use and evaluate a system.
- Developers: They construct successive versions of the system, compromising and resolving conflicts between the context (users needs and desires) and the form, as constrained by technology and economics.
- Motivation behind agile development (XP)
XP = Extreme prototyping
Before users would define all requirements at once and the system was then designed, coded and tested. It did not work. Users can’t tell us once and for all what exactly they want – maybe they don’t know, or they changed their minds.
- XP practices (13)
- Planning game: Customers decide the scope and timing of releases based on estimates provided by the programmers.
- Small releases: The system it put into production in a few months, before solving the whole problem. New releases are made often (daily/monthly)
- Metaphor: The shape of the system is defined by a metaphor.
- Simple design: At every moment, the design runs all the tests, communicate everything the programmers want to communicate… “Say everything once and only once”
- Tests: Programmers write unit tests minute by minute.
- Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running
- Pair programming: All the production code is written by two people at one screen.
- Continuous integration: New code is integrated with the current system after no more than a few hours.
- Collective ownership: Every programmer improves any code anywhere in the system at any time if they see the opportunity.
- On-site customer: A customer sits with the team full-time
- 40-hour week: No one can work second consecutive week of overtime.
- Open workspace: The team works in a large room with small cubicles around the periphery.
- Just rules: Being part of the Extreme team, you sign up to follow the rules. The team can always change the rules as long as they agree on how they will assess the effects of the change.
- XP development cycle (5)
Always work on the features that are perceived as the most valuable by the customer.
- Releases: The project (that is not a project) is divided into releases. The customer picks the nest release cu choosing the most valuable features (called stories in XP) from among all the possible stories.
- Iterations: Each release is divided into even smaller iterations. The customer picks the next iteration’s stories by choosing the most valuable stories remaining, again informed by the costs of the stories and the team’s speed.
- Task: The programmers turn the stories into smaller-grained tasts, which they individually accept the responsibility for.
- Test case: Then the programmer turns a task into a set of test cases that will demonstrate that the task is finished
- Design, programming and test: Working with a partner, the programmer makes the test cases run, evolving the design in the meantime to maintain the simplest possible design for the system as a whole.
- Underestimation in XP (3)
If you have commited to more than you can accomplish:
• Reduce the occurrence of underestimation as much as possible by getting lots of practice estimating
• If you are overcommitted – ask the following internally first: Slipped away from practices? Are you doing as well as you can? Are you delivering more than the customer needs?
• If you cannot find a way to be faster, you have to ask the customer for relief.
- How to deal with uncooperative customers in XP:
- Trying to build a trust relationship with the customer
- If trust begins to break – figure out if it is your fault.
- If they don’t change – make your concerns more visible. If no one cares enough to solve the problem – maybe the project isn’t high enough priority to go on.
- People turnover in XP
People turnover is not a big problem since all programming are done in pairs.
- Changing requirements in XP
Not an issue since XP is designed to deal with change in a low cost way.
• Little or no documentation
• The code is nice and clean due to refactoring
• Iterations are short, so we will learn fast if something needs to be changed.
- Crowd sourcing definition
The act of a company/institution taking a function once performed by employees and outsourcing it to an undefined (and generally large) network of people in the form of an open call.
Different from outsourcing:
• Work announced through an open call to which anyone can respond
• The workers who volunteer are unknown to the organization needing the work done
• The group of workers can be very large and geographically, culturally etc. distanced
- 3 types of crowdsourcing
Peer production
• The oldest and best-known model
• Open source development is an example of peer production – a model in which control is decentralized and contributions are made without monetary reward.
• The contributors, rather than the paying client, decide the project’s scope and goals
• Contributors are typically motivated by the opportunity to gain experience with new technologies, gain reputation and contribute to a good cause
Competition
• Competitions are similar to traditional outsourcing, in which a client requests work and pays for its completion. They treat workers as contestants rather than collaborators.
• A client proposes a project. Then a copilot (an experienced worker who gets paid) decomposes the project into a series of competitions that might cover requirements, architecture and so on.
• The copilot divides each competition into tasks that can be completed in an number of days.
• Contestants each provide a competing solution. The copilot selects a winner, runner up and the corresponding workers are paid.
• This gives the clients access to diverse solutions, which might lead to higher-quality results.
Microtasking
• Decomposes work into a set of self-contained micotasks, which can each be completed in minutes and which together constitute a solution to a more complex task.
• Typified by Amazon’s Mechanical Turk – a general platform in which clients post batches of microtasks. That workers (“Turkers”) complete one at a time.
• Multiple worker can be asked to complete the same task to ensure quality. Best solution will be selected by voting.
• Advantage: Extreme scalability. Work can be distributed to arbitrary large crowds, enabling a quick completion of large tasks.
- Advantages and challenges with Crowd Sourcing
Advantage: • Increased development speed • Generating alternative solutions • Getting easier access to specialist • The democratization of participation: Contributors determines how, when and what to contribute. • Learning through work
Crowd sourcing challenges:
You don’t know if you are going to get anything useful or when you will get it.
- It might be risky.
- Tailoring methods to specific projects (Model: Boehm, B., & Turner, R. (2003)) (5 steps)
- Apply risk analysis to specific risk areas associated with agile and plan-driven methods (specific risk categories: environmental, agile and plan-driven)
- Evaluate the risk analysis results to determine of the project is appropriate for either purely agile or purely plan-driven methods.
- If the risk analysis shows that the project has no clear agile or plan-driven home ground. It also applies to cases in which parts of the system have such different risks that they fall into different home grounds.
- In this step overall project strategy that addresses the identified risks is developed. This involves identifying risk resolution strategies for each risk and integrating them.
- No decision is ideal for all time, the management team must constantly monitor and evaluate the performance of its selected processes while keeping an eye on the environment.
- Closed invocation paradigm vs. open Innovation paradigm
Closed invocation paradigm:
Like waterfall, prototyping, agile etc. all belongs to the closed invocation paradigm
Open Innovation paradigm
open innovation paradigm, as in crowd sourcing open innovation paradigm, as in crowd sourcing
- The Benefits Realization Framework challenges
- Lack of benefits realization
- Perceiving projects as IT projects, not techno-change projects
- Separating systems development from organizational development and change
- Lack of integration of implementation concerns in solution design
- Poorly managed organizational change
OBS. The model is competencies not activities
- Technochange project
A project that changes an organization based on new uses of IT.
Technochange from article: Using IT in ways that can trigger major organizational changes creates high-risk, potentially high-reward, situations that I call technochange (for technology-driven organizational change) Today these project would be labelled as “transformational” or “disruptive”.
Perceiving a Technochange project as an IT project is a classic mistake.
- IT project
A purely technical IT project (such as upgrading a web-server).
- Problems of separation
The problems that comes from separating IT development from organizational development.
- A complete design (By Markus)
A design that not only consist of the design of an IT systems but also the design of the changes to the organization.
- A design that is implementable (by Markus)
A design without misfits towards key organizational characteristics such as the culture, business process and incentives.
- Technochange prototyping
An iterative approach that not only focus on the development of IT, but the organizational changes and benefits as well
- Benefits realization (Benefit realization framework)
the process of organizing and managing, such that the potential benefits arising from the use of IT are actually realized.
- Benefits planning (Benefit realization framework)
the ability to effectively identify and enumerate the planned outcomes of an IS development project and explicitly stipulate the means by which they will be achieved.
- Benefits do not simply emerge, as if by magic, from the introduction of a new technology.
- Their realization needs to be carefully planned and managed.
Examples:
• Understand business strategy:
Clarify the strategic/business drivers for the project and how the project might contribute to the achievement of business strategy.
• Understand stakeholders:
Analyze stakeholders’ requirements in terms of benefits that should be delivered by the project.
• Identify benefits:
Use the strategic/business drivers and stakeholder requirements to identify the agreed upon benefits to be delivered by the project.
• Plan benefits realization:
Develop an overall plan to show the business case (what the benefits are) and how they are going to be realized. Define who is responsible.
- Benefits delivery (Benefit realization framework)
the ability to design and execute the programme of organizational change necessary to realize all of the benefits specified in the benefits realization plan.
- Benefits primarily arise from the organizational change that accompanies an IT implementation, rather than directly from the technology
- Consequently, organizations will only be able to deliver value from their IT investments if they can develop a benefits delivery competence
as the technical solution gradually takes shape, so does the organizational re-design.
Examples:
• Actively lead the business change:
Design, build and lead the project team and governance framework with a focus on realizing benefits.
• Specify changes to work and organizational design:
The project focuses on the design and delivery of a business solution.
• Benefits-driven training and education:
Ensure education and training are focused on the realization of benefits.
• Implement organizational changes:
Implement new and revised business processes, working practices, structures, roles, management framework and performance measures. Take action as required to encourage cultural changes.
- Benefits review (Benefit realization framework)
the organization’s ability to effectively assess the success of a project in terms of the potential benefits, the delivered benefits, and the identification of the ways and means by which further benefits might be realized.
- The benefits from IT investments will only be realized if they are measured and managed in a systematic way.
- Organizations must, therefore, be able to effectively monitor and evaluate the results of their projects, on an on-going basis, to ensure that its ability to deliver business value is incrementally improved.
Remember lag effects!
Examples:
• Benefits-driven project appraisal: Use agreed evaluation criteria to undertake a systematic assessment of benefits.
• Identify actions to realize further benefits: Where planned benefits have not been achieved, or opportunities for new benefits have been identified, a benefits’ action plan needs to be established
- Benefits exploitation (Benefit realization framework)
The adoption of the portfolio of practices required to realize the potential benefits from information, applications and IT services, over their operational life
- Attempts to capture benefits from a piece of business software should not cease as soon as it has been implemented.
- It is often the case that the full potential of a particular application does not become apparent until it is fully operational and the stakeholder community has become experienced in its use.
Managers responsibility
Examples:
• Ensure ownership of continued benefits exploitation: Establish a clear business role for ongoing ownership of realizing benefits.
• Maintain benefits-driven training: Training is focused around benefits realization and establishing new ways of working.
• Evolve working practices: Continue to evolve working practices post deployment to realize further benefits.
- Problems with classic IT project management (In respect to techno change)
- Classic IT project management (and systems development models and software engineering) do typically not address the major risk in technochange: that people will not use IT and related work practices. The focus is on project cost, project schedule, and system functionality.
- Although the discipline of project management is a very important contributor to successful technochange, it has very little to say about how to manage the risks associated with people’s ‘resistance to change’.
Why not just IT project management + change management? too much separation.
• The problem is that the ‘organizational solution’ is expected to conform to the ‘IT solution’, when a better outcome would be an integrated technochange solution. For example we need to align system design and job design in a concurrent process. Implementation issues should be considered during the design process.
- Reasons for Bad technochange (2)
Bad technochange:
Technochange solutions can be bad in two major and related ways:
• They can be incomplete,
• and they can be misaligned with the organization.
Incomplete technochange solutions: are simply IT solutions; they lack the other supportive changes required for use of the IT solution to yield the desired results. For example, getting the desired results from CRM software may require reallocated sales territories and new salesforce incentive systems etc.
Misaligned technochange solutions: may or may not be complete, but conflict so seriously with the existing organization that they are likely to be rejected. For example, health information systems that require doctors to enter information sometimes offend doctors’ sense of status and fail to gain their acceptance.
Technochange projects should change organizations – but in ways that are implementable.
- Separation (in technochange projects)
- Lack of IT understanding in business:
- Lack of business understanding in IT:
- Bad strategy for collaborative innovation: Although ‘user representatives’ on IT project design teams are common, their involvement may not be sufficient to guarantee a good IT solution. People involved in participatory design processes often produce incremental solutions, even when more radical change is needed.
• Unless decisions about new IT and business processes changes are integrated, the likelihood of an incomplete or misaligned solution is large.
- Problems in technochange life cycle caused by separation (3)
3 major problems:
1. Time and distance effects
• Team members get organizationally and phychologically distant from the ongoing operations of the organization.
• A design team can lose their ability to think like a ‘user’ within a matter of weeks.
• Time and distance effects can create ‘drift’ between the project and the business needs that led to it
• The agile / iterative systems development models reduce time and distance effects.
- Exported problems
• Exported problems are problems that arise during one phase of the life cycle but either are not recognized as problems or fixed at that time. Instead, they show up in later phases, when it may be too late or too expensive to fix them.
• The classic example of an exported problem is failure during the chartering phase to recognize that a proposed IT implementation is actually a technochange situation: - Technochange failure creating a culture of failure and unintended consequences
• Canceling a failing project (blaming technology) rather than sinking more time and effort into the attempt to overcome resistance may be a sound business decision.
• Failing in this way can have long-term negative side effects on the organization’s ability to succeed in future change efforts (‘here it comes again’)…
• Even completed and apparently successful technochange initiatives can have unintended consequences, that were not expected or intended by executives or project personnel.
- Technochange life cycle (5)
- Phase
- Chartering
- Project
- Shakedown
- Benefit capture
- Technochange prototyping
- Technochange prototyping is iterative / agile development + organizational changes integrated into one, and the same, process.
- The essential characteristic of the Technochange prototyping approach is that each phase (iteration) involves both new IT functionality and related organizational changes, such as redesigned business processes, new performance metrics, and training.
- In successful techochange, both the solution and the process of arriving at the solution are important.
- A good technochange solution
Successful technochange has three conditions.
- A complete solution:
The first is a technochange solution that is capable of yielding the desired results if it is properly implemented.
- The benefits are only realized when organizations reorganize work in new ways to take advantage of the capabilities of IT.
- When organizations fail to make complementary changes, they often lose business value from their IT investments: If you automate a bad business process, you get a faster, more expensive, but bad business process.
- An implementable solution:
The second is that the solution is actually used effectively.
- The second condition for a successful technochange is a solution that can be, and is, adopted and used.
- But many technochange solutions simply cannot be adopted and used easily or at all, because they conflict with existing organizational structures, cultures, or practices. All technochange has the potential to provoke the human reaction often called ‘resistance to change’.
- But not all technochange solutions are actually resisted. For almost any organizational change goal, it is possible to design several complete technochange solutions that could accomplish the goal, if the solution were adopted and used. The challenge of successful technochange management is to design or select a complete solution that is likely to be adopted and used. Such solutions are said to be implementable.
- It is a much better idea to try to prevent resistance than to hope you will be successful in eliminating it after it arises.
- A solution where benefits are actually exploited:
The third is that the benefits of the solution are actively captured and exploited.
• The benefits of technochange, unlike those of IT projects, are not automatic. Effort is required to turn potential benefits into measurable organizational results.
An example:
o A major benefit of a technochange is that it enables accountants to do their work in less time.
o How does the organization benefit? If the accountants have been completing their work in unpaid overtime, there is no financial benefit to the organization (just happier accountants). If the accountants can now do their work in 6 hours instead of 8hours, does the organization benefit financially? To realize financial benefits, managers would have to reassign work and reduce the number of accountants. Would they actually do so? There are lots of reasons not to.
• To make sure that managers actually capture these benefits, the managers must have incentives (such as rewards) to reduce their costs actively.
- Misfits
3 main types of misfits
(Technochange)
- Task or business process misfits
• A solution may be technically adequate but still not fit the ways people work in particular settings. For example:
o Knowledge bases designed for use by experts often do not work well when they are made available to novices.
o Systems that work well in one national context with particular business practices or legal frameworks do not work well in other countries with different norms and requirements.
- Cultural misfits
• A technically adequate solution may not fit particular settings for reasons that reflect organizational or national culture more than particular tasks.
• Organizational culture can be defined as ‘the way we do things around here’. It often reflects what has been successful in the past.
• Differences between technochanges and organizational culture can contribute to ‘resistance’. For example:
o Systems aimed at increasing administrative efficiency are often resented by doctors and nurses who are committed to patient care.
o Systems designed to promote teamwork may be rejected by people who typically work alone.
- Incentive misfits
• Technically adequate solutions may be misaligned with the authority and reward systems of an organization.
• These misfits are sometimes called ‘political’ misfits, because change managers who promote technochanges with incentive misfits often run into lots of destructive organizational politics. For example
o When Lotus Notes was first introduced into a consulting firm to promote knowledge sharing, it was not used that way. The reason was that, in the company’s up-or-out promotion system, consultants got ahead by hording what they knew. The system only gained got success when the firm began making promotion decision in part on the basis of consultants’ contributions to the knowledgebase.
o Corporate accountants introduced a new financial system to give them detailed visibility into what was happening in the divisions. The system was strenuously opposed by division managers who wanted to avoid headquarters interference.
- Dealing with misfits
- Unfortunately, misfits often have the appearance of technical inadequacy, and those who experience misfits often claim that the system is inadequate.
- Therefore, it is important to take potential misfits carefully into account when designing technochange solutions and when dealing with apparent cases of resistance to technochange.
- The concepts in the model by Petter et al. (3)
IS Succes Model
How to increase chances of succes:
• Systems quality – in which way does quality matter for the creation of benefits? Which quality attributes are especially important (e.g. security etc.)
• Information quality – what kind of information should be offered by the system to help create benefits?
• Service quality – what kind of service should be offered to support the creation of these particular benefits?
And continuously assess:
• Intention to use and
• User satisfaction
For each of the quality aspects we have to design some kind of evaluation that has a high likelihood of identifying any problems with the requirements.
You should continuously through a project try to measure and improve system quality, information quality and service quality as perceived by the users.
User perception of these factors has major impact on their intention to use the system, their satisfaction with the system, and actual use of the system.
- Trust
Trust is defined as an individual’s willingness to depend on another party because of the characteristics of the other party.
- Implementability
Companies should design and build implementability into information systems (e.g. that systems helps users achieve goals that are supported by incentives)
- IS Succes model
IS Success variable: Not surprisingly the users perception of system quality, information quality and service quality has impact on the user intention to use, and use, of systems and impact on user satisfaction. Many systems development methods neglects service quality.
- Incorporating quality requirements during design
During the design:
• You should incorporate all the quality requirements into your design (e.g. if something should be “easy to use” you have to incorporate that into your design and later verify that the design actually fulfill the requirements.
• In the agile approach you will face the challenge that there are no documents describing the relationship between the requirements and the design.
• In a plan-based project the same applies: You have to incorporate the quality requirements into the design, and you have to verify that it is done correctly. However it will be a more formal and documented approach.
- Incorporating quality requirements during test
The purpose of test is to find problems in the code regarding these quality attributes, as well as errors regarding the functional aspects of the code.
- One of the major benefits of agile development is that you test often and also get frequent feedback about the quality, that can be used in later iterations. It is however important that these test / evaluations cover all the quality requirements in a systematic way.
- The plan based approach has a long history of designing tests for all the different kinds of quality. Performance test, usability test, deployment test….. But in practice these tests are not executed properly in many cases.
- Factors that impact the success factors of the model (IS Succes model) (4)
Task
• Task compatibility: the alignment of the technology with the work processes or work styles.
• Task difficulty: task difficulty has an inverse relationship with IS success. The easier the task, the more successful the IS.
User
• Enjoyment: the degree to which users have a positive affect toward the use of technology or an IS.
• Trust: in the technology or IS.
• User expectations: reasonable expectations toward an IS by users is a precursor to IS success.
• Attitudes toward technology: the users general attitude towards the use of technology.
• Organizational role is: a user’s role in an organization does affect the user’s resistance to a new IS.
• Technology experience: the users experience with technology in general (good or bad).
• Self-efficacy: one’s belief that he or she is capable of performing tasks with an IS.
Project
• User involvement: has long been associated with IS success.
• The relationship with developers: the relationship between the IS group and the users, has been shown to have a positive effect on several dimensions of IS success. This relationship between the users and developers is maintained through a partnership, shared knowledge, trust, and effective communication during the development process.
• Domain expert knowledge: has not been studied much, but when it has been included as an independent variable predicting IS success, there is often support for this relationship.
Organization
• The use of extrinsic motivation: such as incentives or pressure by the organization to use the IS, has strong support as a predictor of IS success.
• IT infrastructure: the sophistication or level of IT infrastructure.
• Management support: management support refers to the willingness to allocate time, resources, and encouragement for the use of an IS.
• Organizational competence: managers with higher levels of IT knowledge and competencies affect the adoption of IS and the extent of use of IS within the organization.
• Management processes: such as the culture, bureaucracy, or change control processes, also affect IS success. When management invokes processes that encourage open communication or strongly inform users about the benefits of the new IS, more use of the IS seems to follow. Formal management processes must be adopted to influence the resulting benefits received from the IS. In these cases, management processes strongly affects both use and net benefits
- Managing the factors that impact the success factors of the model (IS Succes model) (4)
- Limited project level impact on some factors: When looking at these factors it is obvious that only some of them might be managed by an individual projects – for example a project has limited impact on the organizational factors and more impact on the project factors.
- Understand your development context: Nevertheless projects should analyze these factors as part of their efforts to understand the development context, so they know what they are facing, and e.g. plan the implementation effort accordingly.
- Use the factors when doing risk analysis: The factors would be very useful when doing a risk analysis of a specific project.
- Increase organizational maturity and possibilities for success: In organizations that depends on IT, management could invest in more general organizational development programs that tries to impact these factor in a way that smoothens the way for individual projects.
