Benefit Realisation and IT Project Management: A Comprehensive Guide, Slides of Business Administration

An in-depth exploration of benefit realisation in the context of it projects. It covers topics such as team characteristics, collecting requirements, overall scope arbitration, the itt, comparing tenders, shortlisted firms, next steps, implementation phase, erp roll outs, and various factors to consider during the project. It also touches upon data transfers and training.

Typology: Slides

2012/2013

Uploaded on 07/29/2013

divit
divit 🇮🇳

4.2

(18)

133 documents

1 / 14

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Benefit realisation
Only occurs when definitive targets sought
Only occurs if analysis was realistic and did not neglect
downsides
May be more intangible than measurable
Head count
Upfront implementation cost
Length of learning curve
Investment may not be exhausted by current usage (stage 2 /
ERP2 etc…)
Whose benefits are those anyway?!?!
Case of the multi-national
Case of a dominant coalition
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe

Partial preview of the text

Download Benefit Realisation and IT Project Management: A Comprehensive Guide and more Slides Business Administration in PDF only on Docsity!

Benefit realisation

• Only occurs when definitive targets sought

• Only occurs if analysis was realistic and did not neglect

downsides

• May be more intangible than measurable

  • Head count
  • Upfront implementation cost
  • Length of learning curve
  • Investment may not be exhausted by current usage (stage 2 /

ERP2 etc…)

• Whose benefits are those anyway?!?!

  • Case of the multi-national
  • Case of a dominant coalition

Team Characteristics

• Typical size: 25 to 60+ FTE

• Team leads: 10 to 20

• Functional area experts

• Special roles:

– Project manager

– Integration manager

– Data conversion and migration

– Training manager

– Hardware / IT specialist

– Platform expert

– Communication about project (internal & external)

Overall Scope arbitration

• Time and cost often already decided

• Time boxing used to segregate

• Trade off with having to do it again next

year

• Arbitrate between requirements

– Out of scope

– Conflict between areas

– Conflict with proposed project scope

• Steering committee (Director level)

The ITT

• Trade off between detail and speed of

processing of information

– Cover everything

– Sample the functionality

– Buy on faith

• Available in generic format (see handout)

• But always better when tailor made to fit

business goals

• See notion of fit in previous notes

• Also prepare ITT to facilitate analysis

• But some vendors will ignore the format

Shortlisted firms

• On or off site presentation

• Intense meeting

• Any item unclear in ITT

• Any contentious point

– User requirements

– Price

– Support / maintenance contract

– Technical characteristics (eg: response time)

• Then leave lawyers finish it off

• Don’t expect a clear cut answer

• Recommend for board level decision

Next steps

• Agree on exact schedule

• Freeze scope again

• Schedule participation of all required users /

technical staff

• Communicate communicate communicate

• Run awareness workshops etc…

• Negotiate re-skilling arrangements

• Ring fence resources and budgets

• Prepare for IMPLEMENTATION

ERP roll outs

• Core team (global)

• Local implementation teams

• Roll out step:

– Initial meeting with local pm

– Local team set up

– Bringing local team up to speed

– Understand implications of template at local level

– Create additional workarounds

– Define criteria for acceptance / rejection of additional

demands

Factor Input values Decision Comment

1 - Scope Global / Local Only global changes will be considered

Global changes are implemented at local level primarily

2 - Impact on Business High / Medium / Low Only high impact changes will be considered

Difficulty in ensuring consistent reporting of impact

2a – Savings Quantified Number of transactions * time saved per time interval

See point 9 below Full justification for perceived saving must be presented

3 - SAP standard functionality Yes / No Only standard functionality will be considered

Except for “must have” additions **

4 - Support Project Business objectives

Yes / No / Maybe Only unambiguous Yes will be considered

5 - Impact on project Yes / No Only changes without overall impact on the project will be considered

Impact on Alliage project focuses on the impact on time of delivery of deliverables

6 - Risk High / Medium / Low Only low risk changes will be considered

trade off to point 4 above

7 – Change in SOP Yes / No / Minimal Only properly documented And QMS approuved changes

Reference of QMS approuval document required

8 - Training Yes / No / Minimal Only changes with minimal training requirements

bullet points max

9 – Costs Number of man days

  • IT
  • Users
  • QC

Project requirements to be checked against accumulated usage of key resources.

In case where total resource usage goes beyond Alliage budget, steering committee may recommend scope enlargement in special cases

10 – Pay back / Return on Investment

Duration of payback period (comparison of 2 and 10)

Only changes that pay for themselves within 12 months

Also take intangible benefits

into account Docsity.com

Data transfers into an application

  • First time system implementation
  • Data warehousing projects
  • Database version upgrade
  • ERP projects
  • Move to new version
  • Called a migration
    • From a manual system
    • From old to new system

Data transfers between systems

• Static data (eg. Customers)

• Dynamic data (eg. sales orders)

– Additional problems with a live system

• Open items

• Balances

• Conversion or interfaces often required