10-Mangement Issues in Systems Development

MISD
 This lecture looks at the issues surrounding

systems development:
 Project Management
 What is it
 Change Management
 Risk Management
 Ways to replace legacy systems, and
 Measuring the benefits of systems
 Case examples include the BOC Group, Down
Corning, GTE Directories, Amazon.com, Toyota
Motor Sales, Wachovia and a trucking company
INSY 532 Lecture Slides Slide2
This Lecture includes
 Introduction
 Project Management
 What is Project Management
 The Job of a Project Manager
 Change Management
 Risk Management
 Tips for Good IT Project Management
INSY 532 Lecture Slides

Slide3
This Lecture…
 Improving Legacy Systems
 To Replace or Not to Replace?
 Options for Improving a Legacy System
 Measuring the Benefits of Systems
 Distinguish Between the Different Roles of Systems
 Measure What Is Important to Management
 Assess Investments Across Organizational Levels
 Do Investors Value IT Investments?

Slide4
Introduction
 Companies are in three ‘businesses’:
1. Infrastructure Management
2. Customer Relationship
3. Product Innovation
 Traditionally companies have bundled the
three (businesses)
 Leads to compromises because the three have
conflicting agendas
INSY 532 Lecture Slides Slide5

Introduction…
 IS departments can be viewed as being in the
same three businesses:
1. Operations are infrastructure management
2. The help desk is the customer relationship
business
3. System development is product innovation

Slide6
Introduction…
 Infrastructure management:
 Goal = reducing costs
 Providing infrastructure involves high fixed costs
 Battle = build scale
 Management focus =
 Efficiency
 Standards
 As we are seeing with operations and network management
 Outsourcing

Slide7
Introduction…
 Customer relationship:
 Goal = provide service
 PC support & help desks often outsourced
 Especially in Europe & Asia (multilingual needs)
 Outsourcing offshore = increasing dramatically
 Product innovation:
 Goal = speed
 Provides nimbleness
 Key to success = talent
 In IT, developers are “king” so they are given the coolest tools
 There are a number of management issues surrounding system
development:
 “Staffing, staffing, staffing”,
 As well as speed & nimbleness

Slide8
Project Management
 Today, much organizational work is
performed via projects
 In IS as well as other functions, being able to
manage a project to completion, and deliver
the expected outcome within the allotted
time and budget, has become an increasingly
valuable skill

Slide9
Project Management
What is Project Management?
 Project Management is simply the management
of a project
 May sound simple and self-evident BUT = doesn’t
make it easy!
 Many people get confused/concerned because IT
project management contains the dreaded ‘T’ word –
Technology
 In reality IT project management is not that much different
from other forms e.g. construction

Slide10
Project Management
What is Project Management?...
 A project is a collection of related tasks and activities
undertaken to achieve a specific goal. All Projects (IT or
other) should:
 Have a clearly stated goal
 Be ‘finite’
 Clear beginning & end
 IT Project Management:
 10% technical, 90% common sense
 Management styles vary as do backgrounds
 Key = keeping in mind, and under control the numerous
interdependencies
 GET THE JOB DONE!

Slide11
Project Management
What is Project Management?...
 Project Management Institute
 Project Management encompasses five processes
1. Initiating
2. Planning
3. Executing
4. Controlling, and
5. Closing
 To become a certified PMP = must pass tests covering nine knowledge
areas:
1. Integration
2. Scope
3. Time
4. Cost
5. Quality
6. Human Resources
7. Communication
8. Risk
9. Procurement
Slide12
Project Management
The Job of a Project Manager
 Responsible for the following tasks:
1. Setting Up the Project
 Why
 A brief background of the project, and
 The business objectives to be achieved
 What
 Key outputs to be produced
 Benefits
 When
 List of milestones and expected timing
 High level project plan
 Who
 Project team
 Stakeholders – and their expectations
 How
 Definition of the work that needs to be undertaken
 Scope
 Specific exclusions
Slide13
Project Management
The Job of a Project Manager...
 Responsible for the following tasks cont.:
2. Managing the Schedule
 Schedule / project plan = heart of the project and main
communication tool
 High level first – then break down as you proceed
 Baseline and track
 Use automated tools
 Recommendations:
1. Focus on the date that tasks are/ will be completed rather than
on the % of overall project completed
2. Review progress at least monthly, preferably more often
3. Focus on tasks to be completed Vs. those finished
4. Reforecast when new evidence comes to light
Slide14
Project Management
The Job of a Project Manager cont.
3. Managing the Finances
 Financial plan, who is accountable, benefits etc.
 Baseline costs and track
 They will change!
 Need to know how much has been spent and how much
money is left
4. Managing the Benefits
 Difficult to estimate but must try
 Base on same assumptions as costs
 Look at timings
 Track
 Why are we doing this????
 Should we still be doing it? Slid
INSY 532 Lecture Slides e15
Project Management
The Job of a Project Manager cont.
5. Managing Risks, Opportunities and Threats
 Risk mitigation and risk management
 Usually poorly done
 Risk logs
 Issue management
6. Soliciting Independent Reviews
 Health checks (of the project)
 By someone independent (could be external)

Slide16
Project Management
Change Management
 IS often assume a technically elegant system is a successful
system. (IT’S NOT!!!)
 Many technically sound systems have turned into
implementation failures because the people side of the system
was not handled correctly
 System is only a success if it meets the users’ requirements and
they are happy with it and with using it
 Information technology is all about managing change
 New systems require changing how work is done
 Focusing only on the technical aspects is only half the job – the
other job is change management

Slide17
Project Management
Change Management...
 Changing management = process assisting
people to make change in their working
environment
 Change – caused by the introduction of a new
computer system
 People resist change, especially technological
change, when they view it as a crisis. ‘Resistance’
includes:
 Deny the change
 Distort information they hear about the change
 Convince themselves and others the new system will
not change status quo
Slide18
Project Management
 Type of people involved in a change project
 Sponsor: the person or group that legitimizes the change
 Change agent: the person or group who causes the change
to happen
 Target: the person or group who is being expected to
change and at whom the change is aimed

Slide19
Project Management
Methodology to manage technological change
 Conduct surveys with all three groups to determine:
 Whether the scope of the project is do-able, or whether the
organization is trying to change too much at one time
 Whether the sponsors are committed enough to push the change
through, or whether they are sitting back expecting the
organization to change on its own
 Whether the change agents have the skills to implement the
change, or whether e.g. they are not adept at rallying support
 Which groups are receptive to the change and which are resistant

Slide20
Project Management
Risk Management
 Not all IT-based projects succeed
 Many fail, especially the really large ones e.g. ERP, CRM
 30 to 70% fail
 Why? = Do not overcome their risks
 Technical
 Business
 Technical risks
 Sub-performance, scope creep making it too complex
 Can’t always be predicted but they can be contained
 Business risks
 Business does not change properly to use the new systems
 Are not as easily righted
 Need to:
1. Assess the risk
2. Mitigate the risk
3. Adjust the project management approach
Slide27
Project Management
Risk Management...
 Step 1: Assess the Risks
 Three predominant risk factors:
1. Leadership of the business change
2. Employees’ perspective of the change
3. Scope and urgency of the change
• Decision tree (Figure 10-1)
 Project leader = executive(s) responsible for the change
– Must be a business executive
 It is the business, not IT that is required to change
• Contributes to success/failure? – 6 questions:
1. Are they committed to the business case?
2. Do they understand the extent of change in work behaviour required for the
project to succeed?
3. Are they formally motivated to pull off the change?
4. Are they at the appropriate org. level with the formal power…..?
5. Do they have experience with a project of similar scope, urgency and people
impact?
6. Do they have informal power, such as credibility and respect?
Slide28
Slide29
Project Management
Risk Management...
 Step 2: Mitigate the Risks
 Project management styles
 Authoritative Vs. Participative
 Project’s budget and timeframe
 Rigid Vs. Adjustable
 Figure 10-2
 Big Bang- Only appropriate when all 3 factors = positive
 Improvisation
 Leadership and employee = positive but scope or urgency place the project at
risk- Committed workforce can adapt etc.
 Guided Evolution
 Used when only the employee perception is negative
 Can be overcome by involving them
 Top-down Coordination
 Only works when the leadership factor supports the business change and
when the leadership is respected, full-time and highly experienced in leading
business change
Slide30
Slide31
Tips for Good IT Project
Management
 Establish the Ground Rules
 Open systems, industry standards, web-enabled etc.
 Foster Discipline, Planning, Documentation and Management
 If the process is not controlled properly, anything can happen or, more
realistically, potentially nothing will happen
 Obtain and Document the ‘Final’ User Requirements
 Don’t get too technical
 Obtain Tenders from All Appropriate Potential Vendors
 Include Suppliers in Decision Making
 Convert Existing Data
 Task might appear quite simple but often causes the biggest headaches
 Follow Through After Implementation
 Cross the t’s and dot the i’s in terms of documentation, future maintenance
processes etc.

Slide34
Reasons for Success
 Proper Planning
 Appropriate User Involvement
 Strong Visible Management Support
 Project Manager(s) with Power and Time
 Good Change Management
 Working As A Team
 Proper Project Monitoring and Control
 Proper Project Closure
Slide35
Project Management
Reasons for Success...
In all circumstances:
KEEP YOUR FOCUS ON THE END
RESULT
Look at enablers not obstacles

Slide36
Project Management
Danger signs
 Top management informed?
 Top management involved?
 Sponsorship?
 Project planning tools?
 Scope creep?
 Status reporting?
 Current capabilities?
 IT/business interaction?
 Training/business change management?
Slide37
Improving Legacy Systems
 Many Information Systems executives feel
trapped by the past:
 Old legacy programs & data they would
love to replace
 However, replacement is not the only
option
 In many cases = not even the wisest
 Possibly = only delay (the inevitable?)

Slide38
Improving Legacy Systems:
To Replace or Not to Replace?
 Upgrading – sometimes makes more sense
 More difficult (to sell?)
 Not as exciting as a totally new system
 Most replacement projects that failed could have been upgrade projects
 Many reverted to upgrading anyway
 When a systems technology is so obsolete that it does not exist in many
places, then replacement is probably the only choice – BUT otherwise –
perform 3 analyses:
1. Rigorous analysis of the costs and benefits the new system
2. Determine how specialized the new system really is
 Sometimes = think you need ‘made to order’ when purchased would do just fine
 KISS
3. Assess the IS staff’s capabilities honestly
 Can they do the job?
Slide39
Options for Improving a Legacy
System
Figure 10-3 illustrates the choices companies
have with dealing with legacy systems
 Analogy with a home
 The options can be performed:
 In-house or
 Outsourced – including:
 Transitional
 Part

Slide40
Slide41
Options for Improving a Legacy System…
1. Restructure the system:
 House = updating the look of a room e.g. repainting or
getting rid of clutter
 Applicable to systems that are basically doing the job but
run inefficiently or are “fragile.”
Seven Steps in restructuring:
1. Evaluate the amount of structure in the current system
- number of layers of nesting, degree of complexity,
etc.
– Use tools to trace program control logic
2. Compile the program, to be sure it is in working order

Slide42
System…
1. Restructure the system…
3. Run the program through a structuring engine, which cleans up and
restructures the code, following structured programming concepts
– This process does not change the logic of the program, but replaces poor
coding:
• Reduces number of ‘GOTOs’
• Removes dead code
• Highlights loops, and
• Groups input/output
4. Reformat the listing to make it easier for programmers to understand
5. Ensure that the old and new versions produce the same output
– File to file comparator
6. Minimize overhead introduced by restructuring (optimizer package)
7. “Rationalize” the data by giving all uses of the same data one data name
Slide43
System…
2. Reengineer the system:
 A step beyond restructuring, implies extracting the data
elements from an existing file and the business logic from
an existing program and moving them to an existing
platform. See Life Cycle Figure Slide4
 House = fixing what isn’t working
1. Reverse engineering: existing programs, along with their files and
DB descriptions, are converted from their implementation level
description to their equivalent design level components
2. Forward engineering: from requirements level to operational
systems
Slide44
Slide45
System…
3. Refurbish the system
 House = enhancing the usefulness by replacing furniture,
landscaping etc.
 If the old system is maintainable and causing no major
problems; it may be worthwhile to add ‘extensions’
– Potential extensions:
 Supply input in a new manner
 Make new uses of input, or
 Allow the programs to deal more comprehensively with the data
 Occurring quite a bit these days with the ‘web’
– Old system an ‘untouchable’ black box surrounded by new systems
 Note: this method was popular even before the ‘web’
Slide48
System…
4. Rejuvenate the system:
 House = adding new functions e.g. new room, pool etc.
 Adding new functions to a reengineered system to make it more valuable. Phases
of rejuvenation process:
1. Recognize a system’s potential
– First clean up existing system using code restructuring tools and then building from
there
2. Clean up the system
– Transform the poorly structured COBOL code into more structured, maintainable
code
3. Make the system more efficient
– System can be converted to a new operating environment and a new file structure,
together with manual tuning and enhancements to reduce system processing time
4. Give the system a strategic role
– To answer the question “How can we provide even more timely information or
improve competitive position in the marketplace.”
• e.g. allowing it to feed a data warehouse

Slide49
Options for Improving a Legacy System…
5. Rearchitect the System:
 House = rethinking the use of space by perhaps
gutting a major portion of the house and
remodelling it
 This option involves having a to-be architecture for
new systems, then using that architecture to
upgrade legacy systems
 Previously not seen as necessary, IT architectures =
now mandatory
 Where possible CTOs work hard to migrate their
enterprise to that desired to-be architecture,
generally one system at a time
Slide51
System…
6. Replace with a Package or Service: to move an old
application to a new operating environment, e.g.:
centralized to distributed, e.g., SAP
– This alternative has become the norm; another option, one being
touted as “the future,” is to replace a system with a service
delivered over the Internet
– House = move!
7. Rewrite the System: if too far gone to rescue, obsolete
technology; beware of true cost and risk failure
– RARE! = only ‘specialized’. Normally = go for a package
– House = knock down and build a new one
Slide53
Measuring the Benefits of
Systems
 Measuring the value of Information Systems
seems to be a continuing request
 Never mind that the Internet has changed the world or
that e-commerce and e-business are impossible
without computers
 Executives want specific links between new
systems and corporate financial measures e.g.
 Increase in earnings
 Shareholder value
 Revenue
Slide55
Systems…
 Achieving this is very difficult because IT is only
one of many factors contributing to the successful
use of systems
 e.g. the value of decision support systems and data
warehouses are difficult to measure because they are
intended to change such un-measurable actions as:
 Improved decisions
 Better identification of opportunities
 More thorough analysis
 Enhanced communication among people

Slide56
Systems…
 E-commerce systems, which aim to improve a firm’s
competitive edge or protect its market share, also elude
measurement
 New market systems
 How do you calculate ROI?
 Infrastructure investments (upon which future
applications will be built) often cannot be justified on ROI
because they have none!
 Can’t however just say “it’s too hard”
 Three (of many!) suggestions on how to deal with these
measurement dilemmas:
1. Distinguish between the different roles of systems
2. Measure what is important to management
3. Assess investments across organizational levels
Slide57
Systems…
Distinguish Between the Different Roles of
Systems
 Information systems can play three roles in a
company:
1. Help other departments do their job better: “support systems” with
the goal to increase organizational efficiency
2. Carry out a business strategy: e.g. CAD systems that customers and
suppliers can use together to design custom products
 Differ from support systems because they are used by customers
3. As a product or service as the basis for a product or service: e.g.
testing or design software that a company sells to another firm
 Measuring the benefits of these three kinds of systems

differs
Slide58
Measuring the Benefits of Systems…
Distinguish Between the Different Roles of Systems…
1. Measuring Organizational Performance:
 Meeting deadlines and milestones
 Operating within budget
 Doing quality work
 Performance measures internal efficiency of operations
2. Measuring Business Value:
 Deals with marketplace goals
 They must have a direct impact on the company’s relationships
with customers, clients, or suppliers; e.g. sales/customer
3. Measuring a Product or Service:
 An IS offered as a product or service to produce revenue
= measured as any other business venture e.g. by ROI
Slide59
Systems…
Measure What Is Important to Management
 IS support can only be linked to corporate effectiveness
by finding all the indicators management use, besides
the traditional financial ones
 Measure in terms like:
 Customer relations (incl. satisfaction)
 Employee morale
 “Cycle time”
 How long to accomplish a complete assignment; fast cycle time might
mean higher-quality products, beating competitors to the market,
winning a bid, etc.

Slide60
Systems…
Assess Investments Across Organizational Levels
 IT benefits cross organizational levels, sources of value at
three levels:
 Individual
 Division
 Corporation
 Impact focus of an IT investment extends to
 Economic performance payoffs - market measures of
performance
 Organizational process impacts - process change
 Technology impacts - key functionality
 Combine views to form a 3 x 3 matrix
 Used by a trucking firm who uncovered benefits that
otherwise would have gone unrealized
Slide61
Do Investors Value IT
Investments?
 An even more intriguing question than how
business executives value IT investments is how
investors value IT investments
 A study found that every $1 invested in
computers yielded up to $17 in stock market
value – and no less than $5
 Whereas, $1 invested in property, plant, and
equipment (book value) only yielded $1 in stock
market value; and
 $1 investment in other assets (inventory, liquid assts,
and accounts receivables) yielded only 70 cents

Slide63
Do Investors Value IT
Investments?...
 The researchers reason that investors value $1 spent on
computers more than the other investments because it
leads to organizational changes that create $16 worth of
“intangible assets” – know-how, skills, organizational
structures, and such
 Investments in “organizational capital” generally lead to
adopting decentralized work practices:
 Using teams more often
 Giving employees broader decision-making authority, and
 Offering more employee training
 Firms with these three decentralized work practices had a
market value of 8 percent higher than the mean
Slide64
Conclusion
 Managing projects has always been one of the most important, and
toughest, jobs in the IS organization
 Even with outsourcing and software packages, project management
belongs in-house because responsibility for project success remains in
house
 Project management skills = critical
 People job in system development:
 Managing development staff
 Helping people adjust to the organizational changes that occur with a new
system
 Successfully implementing systems:
 Sponsors understand their role in enforcing change – giving change
agents the tools & skills to foster the change
 Assisting the targets in making the change – providing training etc.
Slide65
Conclusion…
 Software – difficult to keep up-to-date:
 Variety of options (refurbish etc.) as well as replacing it with a package
 New alternative = rearchitect the system toward a desired “to be”
architecture
 “Rent” software off the Web, per seat, per month
 Process of justifying a new system can uncover what is
important to management
 Measuring benefits afterward can help companies spot benefits
they had not originally planned
 Investors more highly value companies with higher IT
investments and more distributed work practices

Slide66

10-Mangement Issues in Systems Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10-Mangement Issues in Systems Development

Uploaded by

Copyright:

Available Formats

MISD

 This lecture looks at the issues surrounding

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides Slide5

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

 Measuring the benefits of these three kinds of systems

INSY 532 Lecture Slides

INSY 532 Lecture Slides

INSY 532 Lecture Slides

You might also like