Portfolio approach to IT projects
A div. Of chemical co. scrapped a SAP project
–They had implemented SAP before
–This time used inexperienced project manager
•He misjudged amount of change management necessary
–Lost millions of dollars
•Major credit card co. underestimates processing
requirements by >90% when outsourcing
–System crashes
–Service levels plunge
–CIO and a side kick get fired
• A mfging co. consolidates activities from 50
plants
– Wait time to confirm orders averages 25 secs
• More than 2 secs makes the system unusable
• Two major insurance co. install same software
– One sees 46% increase in sales
– Other had to scrap the system at cost of $600 mill
• This happened in late 1990s
Whats wrong?
3 serious deficiencies in general and IT mgmt
1. Failure to assess implementation risk when
the project is funded
2. Failure to consider the total implementation
risk of a portfolio of projects
3. Failure to recognize that different IT projects
require different managerial approaches
Sources of implemenation risk
Mismanagement is not included since it is not
inherent part of the project. Also assume that
proper info tools and methodology is used.
• Project with high benefits usually have high
risks
• Managers produce lots of reports about benefits
but very little is done about risk
• Risk of time slippage, cost overruns, technical
shortfalls, and outright failure seldom assessed
3 main sources of implementation risk
1. Project size
•
•
•
•
•
$ value of the project: bigger $ value carry
more risk, relative to other projects undertaken
Staffing levels
Durations
Number of departments affected
Project Size relative to the size of the other
projects undertaken by the IT department
2. Experience with technology
•
•
•
•
Familiarity with hardware
Familiarity with software
Familiarity with operating system
Familiarity with dbms etc.
Notice its familiarity. A department familiar with
these may face lower risk than a dept. new to
it
Handle risks by using systems integrator
consultants with expertise in these technolo.
Companies that do these include
• CSC, IBM, EDS, Computer associates etc.
3. Project structure
•
•
•
Will requirements change before implementation
Does project require little or high organizational
change
Does the project require BPR
Low structure projects usually require
organizational change
The questions in fig 10.3 may not be appropriate
for all companies but it’s a good starting point
Higher assessment score mean more need for
very senior mgmt approval.
Show figure 10.1 which shows effect of degree of structure, technology relative to company’s experience,
and project size on project implementation risk.
Then show figure 10.2 which is an example
One companied developed a questionnaire to assess project implementation risk. Show figure 10.3 which
has some of the questions.
These questions may not be appropriate for all companies but provide a good starting point.
Higher score means greater need for very senior level approval. Only executive committee can approve
projects with high risks. And managers should ask next slide questions before giving approval.
Use the questionnaire several times during the project to show major changes in the risks. Usually risks
should reduce with progress as the size of remaining tasks dwindle and people become familiar with
the technology. When managers think its low risk and IT folks think its high then usually things go very
bad. Using the questions in this case helps.
Managers should ask themselves:
1. Are the benefits great enuf to offset risks
2. Can the affected parts of org survive if the
project fails
3. Have the planners considered appropriate
alternatives
Administer the assessment questionnaire several
times during the project.
Usually risk should decline as make progress on
the project.
Portfolio risk
Company should also assess risk with the project
portfolio
• A co in strategic quadrant should be concerned
if portfolio has no high risk projects
• A portfolio full of high risk projects is also not
good
– Compan operations may be at risk from disruptions
• Co in support quadrant shouldn’t have lots of
high risk projects in its portfolio
Factors that influence implementation risk profile of
portfolio
Portfolio risk focus
factor
Low
high
Stability of IT development group
High
low
Perceived quality of IT dev gr by insiders
High
low
IT critical to delivery of current co services No
Yes
IT an imp decision support aid
no
yes
Experienced IT development group
Yes
no
Major IT fiascoes in last 2 years
No
Yes
New IT management team
no
yes
IT perceived as critical to delivery of
future co services
No
Yes
Co perceived as backward in IT use
no
yes
If the stability is low then the risk level will be high
Different projects should be managed differently
Principal management tools for project mgmt:
1. External integration tools: used to improve
coordination/acceptance/ from/with user & mgmt
2. Internal integration devices: to coordinate with
project team members
3. Formal planning tools
4. Formal results control tools
Formal planning tools include PM sw, etc. go to next 2 slides
External integration tools/tech
Internal integration tools/tech
User as PM
Selection of experience IT as leader
User steering committee
Team meetings
User-managed change control
Key design decision info available
Distribute proj team info to key
users
Have users as team members
Tech status review/inspections
User approval process for sys
specs
Try to pick people who have
worked together before
Prototyping with users
Get outside technical assistance
Progress reports
Have team members set goals &
deadlines
User involvement in other areas
Team members personalities should
be compatible
Techniques for low HR turnover
Formal planning tools
Formal results control tools
Project management s/w
Status vs plan reports
Milestone selection
Change control discipline and
systems
System specs
Milestone review meetings
Project approval process
Analysis of deviation from plan
Postproject audit procedures
Result controls are v. good for projects that have:
• Clear advanced knowledge of desired results
• Whoever is supposed to be effected by these
mechanisms can control the desired results
• Results can be measured effectively
Highly structured projects using low degree of tech are
very good for these.
Not for low structured projects using high degree of
tech. ……here use high degree of internal integration
tools
Which tools for which project types
High structure/low tech: lowest risk, easiest to manage but rare
1. Requirements are defined clearly and do not change so
don’t need change management,
2. don’t need heavy representation of users on the team,
3. don’t have to assign IT systems analysts to user
departments,
4. don’t require formal user approval of design specs,
5. but still need user training
6. Can be staffed with average skill people
7. Project leader doesn’t require extra ordinary IT skills
8. Can use junior managers to gain experience
9. Pert/cpm techniques work very well
10. Likely to meet milestones and target budget
11. Result control techniques give good data to help team work
hard to meet goals
High structure high tech projects
Example would be converting mainframe system to client-server with same
functions.
1.
Here interaction with the user is not crucial but is needed to ensure
coordination of any changes in the input/output and to deal with system
changes that are being brought in cuz the old mainframe had some short
comings
2.
Often find that the selected technology was inadequate so either select a
new tech or some vital features are modified.
3.
PM should have strong IT background and should be able to
communicate with techies.
4.
For large projects its important to maintain teamwork
5.
Develop a record of all key decisions
6.
Call subject meetings as needed
7.
Will find bugs which will increase cost of implementation
8.
Formal results mechanisms don’t help much but personnel controls
become imp.
9.
Internal integration more important than external integration
Low structure low technology projects
Less risky if managed very well.
Fail cuz of not enuf understanding and focus on bus. requirements
Get users involved in design, development, and implementation
1. Get user as PM or deputy PM
2. User steering committee to evaluate design periodically
3. Break project into several subprojects
4. Formal user review and approval on all key project specs
5. Distribute minutes of all key design meetings to users
6. Try sticking to key subproject time schedules. Keep turnover
among users low, agreement with a user manager who is
gone is of very low value….get agreement with the new user
manager again
7. Need strict formal change control process
8. Formal planning controls good if users heavily involved
9. External integration tools very important here
Low structure high tech projects
•
•
•
•
•
•
•
•
•
•
•
Requirements not clearly and completely defined
Technology is complex
Managers need technical expertise
PM should have ability to communicate with users
External integration very important
Total user commitment to design specs imp
Need highly experienced project leaders
Need high degree of support from users
If possible divide the project into smaller parts
Formal planning and results do not help in the beginning
Time, cost, and technical performance very diff to predict at the
same time
• Show table 10.3 page 592