SGIs Auto Fund Redevelopment Project - PowerPoint PPT Presentation

1 / 61
About This Presentation
Title:

SGIs Auto Fund Redevelopment Project

Description:

The Auto Fund is financially self-sustaining, operating on a ... Centric. View. Auto Fund Redevelopment. New System. The Project Structure. Business. Analysts ... – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 62
Provided by: dona193
Category:

less

Transcript and Presenter's Notes

Title: SGIs Auto Fund Redevelopment Project


1
  • SGIs Auto Fund Redevelopment Project

2
Who we are
  • SGI was created in 1945 and has evolved into two
    distinct operations.
  • The Saskatchewan Auto Fund is the provinces
    compulsory auto insurance program, operating the
    drivers licensing and vehicle registration
    system. The Auto Fund is financially
    self-sustaining, operating on a break-even basis
    over time. It does not receive money from, nor
    pay dividends to, the government.
  • SGI CANADA is fully competitive, selling property
    and casualty insurance products such as home,
    farm, business and extension auto. SGI CANADA
    currently operates in Saskatchewan, Alberta,
    Manitoba, Ontario, Prince Edward Island, Nova
    Scotia and New Brunswick.

3
Auto Fund
  • Responsible for Driver Licensing, Motor Vehicle
    Registration, Highway Permits, Traffic Safety
    services

4
The Project
  • Replace the legacy Systems for the Auto Fund
    Division of SGI

5
Vision
  • Develop a system that makes it easy to do
    business with SGI.

6
Agenda
  • Background on SGI
  • Auto Fund Redevelopment
  • Project Objectives
  • Current System
  • RFP Process
  • Pre-work to an RFP
  • RFP Approach
  • RFP Evaluation
  • Conceptual Design
  • Release Strategy
  • Complete Budget and Time Line

7
Agenda - Contd
  • Project Organization
  • Managing Risks
  • Top Ten reasons Projects Fail
  • Staff Involvement at all levels
  • Release 1 - Permit System
  • Lessons Learned
  • Adjustments Made

8
Legacy Systems
  • Vehicle Registration System
  • Driver Licensing
  • Driver Programs
  • SAM
  • Highway Permits
  • International Registration Program
  • Driver test Scheduling System
  • Driver Written Test System

9
Analysis Phase
  • What we wanted to accomplish
  • How we wanted to do it
  • What we knew needed to be done
  • What we did not know

10
Analysis Phase
  • Selecting business partner
  • RFP for a business partner
  • How we selected the partner

11
Conceptual Design
  • What was delivered
  • Decisions made
  • The next Phase

12
SGI Auto Fund Redevelopment
  • Redevelopment will
  • Retain the best of the existing system
  • Create a new system that responds faster to the
    changing demands of business
  • Ensure the system is maintainable over the long
    term
  • Make it easy for Customers to do business with
    SGI

13
Customer Centric Design
Customer Centric View
14
Auto Fund Redevelopment
15
New System
16
The Project Structure
BusinessAnalysts
ApplicationDevelopers
Acceptance Manager
Delivery Manager
17
(No Transcript)
18
One Integrated System
19
Existing System
20
After Release 1
21
After Release 2
22
After Release 4
23
Release 2 Co-existence
24
Internet Strategy
  • Strengthen the Relationship between the Licence
    Issuer and the end-customer by offering a new
    delivery channel
  • Provide choices for the Customer for all SGI
    Products and services

25
Targeted User InterfaceCommon Business
Functionality
S e c u r i t y
Vehicle Registration
Monthly Renewals
Driver License
Customer Data Driver Data Vehicle Data Financial
Data Product Data Common Data
Apply for PAC
Point of Sale Issuers
Calculate Fees
Permit Admin
Safety Rating Factor
Driver Admin
Payment Process
Internet Customers
User Interface
Business Logic
Data Base
26
Highlights-Product Management
  • Business areas will be able to modify
  • Product Lines
  • Product Names
  • Business Features
  • Prices, Rates
  • Fees
  • Business Rules
  • The system will not be the barrier to business
    change

27
Large Software Development Projects
  • 9 per cent on time and on budget
  • 73 per cent never finish
  • 94 Restarts for every 100 starts
  • Major financial losses are common
  • Few survivors (Project Managers) Standish
    Group

28
Top Ten Reasons Why Projects Fail
  • Entertaining Tips Designed to Help!

29
10 - Changing Technology
  • Your shop is very familiar with a certain
    development environment, set of languages,
    methodologies etc.
  • A more exotic technology is making the
    headlines
  • Developers tell you the estimates can be reduced
    with this new technology

30
10 Changing Technology
  • Only Change if there is a Compelling Business
    Reason to do so
  • If you still insist...
  • Secure TIME and MONEY to account for the
    increased risk including learning time for the
    developers

31
Number NineFailure to Stick to the Plan
  • Must use formal change requests
  • Non adversarial
  • Based on change in intent
  • Dont try your first CR without establishing a
    good relationship first
  • Formal decision requests
  • Failure to respond means acceptance

32
9 Sticking to the Plan
  • Dont combine
  • The Plan used for communications
  • With the logistic plans used to help out your own
    personal planning (i.e. Project Planning tool)

33
Number EightGold Plating
  • Idealistic developers
  • Design for total flexibility??
  • Add really amazing features!!

34
7 Lack of Relevant Measurement
  • Requires a lot of detail
  • The team must own the measurement!
  • Developers must have the freedom to report the
    truth!
  • The measurement must focus on end results

35
Simple Measurments
36
(No Transcript)
37
7 Measurement
  • Always measure the amount of work left
  • Standardize on
  • Business Processes - early phases
  • Screens, Reports and Functions - later phases
  • ONLY measure things in Client Terms
  • Dont measure too much!

38
6 Scope Control
  • Functionality at the expense of
  • Performance
  • Data Integrity
  • Reliability
  • Conversion
  • Project Deadlines
  • Project Costs

39
6 Scope ControlPredictable Behaviours
40
5 Lack of End User Involvement
  • Front line staff
  • Those that will be using the system as a
    fundamental part of their job
  • Input required from Managers, Business Analysts,
    and End Users
  • Dont assume the users all think alike

41
5 End User Involvement
  • The Busiest are the Best
  • Take whatever time you can get
  • Dont depend on that business analyst that has
    spare time to give you all the requirements

42
Number FourInsufficient detail on requirements
  • The amount of detail required is always
    underestimated
  • Requirements are a function of what is perceived
    to be possible
  • There is no single correct answer

43
The Analysis / Design Process
  • Listen to the End User
  • Dont do anything Just listen
  • Understand the business problem
  • Think through a workable design
  • Review with other designers
  • Present / sell the workable solution
  • Let the user build more detail around that
    solution

44
Minimizing Delivery Risks
  • Pro-actively look for delivery stress points
  • i.e. Programmer might not make it
  • Remember all business solutions dont involve
    total automation
  • Explore creative new business solutions
  • Semi-Automated or Manual
  • Sell back a workable solution to the Customer
  • Might be less than ideal

45
3 Lack Of Experienced Resources
  • Scars are a good thing!
  • Its almost impossible to visualize the detail
    required for a successful implementation without
    experiencing it

46
3 Experienced Resources?
  • Secure your resources before you finalize your
    estimates!!

47
2 Unclear Objectives
  • Well thought out Project Initiation
  • Manage expectations early
  • Re-engineering what??
  • The Business?
  • The Technology?

48
1A Breakdown of Trust
  • It can happen in, or between, several areas
  • End Users
  • Developers
  • Client Managers
  • Delivery Managers

49
1 A Breakdown of Trust
  • How does it happen?
  • You screw up in any one of the other 9 areas!
  • You had a bad Contract ...

50
Trust and the ContractScenario One
  • Clients business is riding on the project
    completion date
  • Delivery team is being paid on time and materials

TRUST
51
Trust and the ContractScenario Two
  • Delivery team has a fixed price and a fixed end
    date
  • Client hasnt decided when to implement and/or
    requirements are still floating

52
A Good Contract
  • Helps to clarify expectations
  • What am I going to get for the money?
  • Assists in communications
  • Assists in creating a WIN WIN environment
  • Helps to prevent hidden agendas
  • Ensures you have a beginning and an end

53
Top Ten Summary
  • 10 Changing Technology
  • 9 Failure to Stick to the Plan
  • 8 Gold Plating
  • 7 Lack of Relevant Measurement
  • 6 Scope Control

54
Top Ten Summary
  • 5 Lack of End User Involvement
  • 4 Insufficient Detail on Requirements
  • 3 Lack of Skilled Resources
  • 2 Unclear Objectives
  • 1 A Breakdown of Trust

55
Summary
  • Dont Count on a Quick Shake
  • Increase your ability to Influence
  • Sales training
  • Effective Negotiating
  • Behavioural Psychology
  • Leadership Skills
  • Relationship Building
  • Constantly focus on the end result
  • Develop a Vision and start working towards it

56
Summary
  • Focus on the Fundamentals
  • Communicating with the end user
  • Thinking about the business problem
  • Worrying about the end result

57
Staff Communications
  • Communications strategy
  • Ask the Redevelopment team
  • staff presentations
  • change management
  • Lunch and Learn Sessions

58
Release 1 Lessons
  • What went well
  • Where we need to improve
  • Actions taken

59
Project Milestones
  • Release 1 Completed on time
  • Release 2 Some components delivered early
  • Release 2.1 completed on time
  • Project within Budget

60
Where are we now
61
  • Questions
Write a Comment
User Comments (0)
About PowerShow.com