1. Inception Phase - Analysis
Risk Management
Inception Phase - Analysis
Steps – overview
Risk Evaluation
Risk Monitoring
Exercise 8 – Risk Analysis for Latinitas

2. MIS 374 SDLC*-- Inception Phase tasks
Final
Construction
Phase(s)
Inception
Phase(s)
1. Determine project scope, objectives, constraints, performance criteria & risk.
2. Identify organizational impacts.
3. Prioritize Requirements
4. Build a development team and create a work plan.
Task order, iteration, and collaboration with users will depend on project characteristics.
This project life cycle is the required model for planning assignments that are part of Group Project 2 and the Client Project.
* SDLC: System Development Life Cycle 2

3. Inception phase review
Techniques & Tools
Stakeholders, Roles, and Responsibilities (SRR) Table
Root Cause Analysis (RCA)
Modeling (DFDs, Business Process, etc…)
Organizational Impact
Non-functional Requirements (NFR)
Risk Management
Cost/Benefit Analysis—ROI (will come later)
Goal: Evaluate feasibility of project and get consensus between client and team to proceed (scope)

4. Let’s start with this question…
Do you like surprises?
Did you have any in K?

5. Risk Management Techniques
Sources of risk for IS projects
The organization
The proposed system
Developer expertise
User characteristics
Risk analysis
Risk reduction strategies
Then…we continuously monitor the risk level

6. Risk Analysis Steps
Consider all parts of projects in which risk can occur
Identify parts of projects as either risky, not risky, or maybe.
Score total risk of project
Determine risk reduction strategies to lower the likelihood of each risk.
Review Risk score week to week to ensure reductions are working

7. Risk Assessment Factors
Organization
A. Clear, stable objectives?
B. Has a Strategic Plan for Info Resources (SPIR)?
C. System fits into objectives?
Information System
A. Clear requirements ?
B. Structured business process ?
C. Affects only one business area? (not cross functional?)
D. Completed in less than three months?
E. Stable, proven technology ? Or technology too old?
F. Install at one site?
Developers
Experienced with chosen development methodology?
Skilled at determining functional requirements?
Familiar with information architecture ?
Users (more than one type)
Experienced with proposed application area processes ?
Familiar with systems development process ?
Users and management committed to success ?

8. Risk Evaluation form High point total = Low Risk
3 months?
High point total = Low Risk
Lower point total = Higher Risk
*1 = yes, 0= maybe, -1=no

9. Risk Evaluation form 1st Factor (3 items) 3 months?
*1= yes, 0=maybe, -1=no

10. Risk Evaluation form 2nd Factor (6 items) 3 months?
*1=yes, 0=maybe, -1=no

11. EMS Scheduling Project
This was a project to automate scheduling of drivers and medical staff for the City of Austin’s Emergency Medical Services.

12. Objectives Automate scheduling Alert managers to scheduling conflicts
Staffing reports
Create an electronic scheduling form

13. Payroll Procedure Daily Schedule
Monthly
Schedule
Overtime
Payroll
Procedure
Daily
Schedule
Trades
Leave
Reports

14. Payroll Daily Procedure Schedule OJI Monthly Schedule Payroll Overtime
Training
Monthly
Schedule
Mandatory
OT list
Reassignments
Leave
Data
Vacation
Payroll
Continuing
Education
Overtime
Workload
Rule
Payroll
Procedure
Daily
Schedule
Trades
Leave
Leave
Accrual
Holdovers
City
Certification
Reports
State
Certification
Callbacks
Sick
Time
Leave
Cap
Unfilled
Positions
Overtime
Per Shift
OJI

15. Risk Evaluation form EMS realized they needed a SPIR & hired
consultants.
DFDs illustrate problems with lack of modeled requirements or routine, structured procedure.
3 months?
The EMS team presentation used DFDs to illustrate problems with Risk items 2a & 2b. In fact EMS decided a couple semesters later that they needed to hire consultants to create a multi-year information resources plan.
1=yes, 0=maybe, -1=no

16. Risk Evaluation form Items 2 c, d, f focus on size & complexity
3 months?
*1= yes, 0=maybe, -1=no

17. Case Example
President
Students
Board
Client
Volunteers

18. Overview of 3-semester plan for EMS
This slide shows the work to be completed by 4 teams over 3 semesters:
Spring 1998 – the original EMS team would complete a requirements specification and design for an internal system to be used by the main office.
Fall 1998 team 1 – implement the internal system to be used by the main office using the analysis and design specifications provided by the spring 1998 team
Fall 1998 team 2 – complete a requirements specification and design for the distributed portion of ARMS to allow the Mobile Medic Units, Medic Stations, and Banner System to interact with the internal system
Spring 1999 – implement the distributed portion of the system based on the analysis and design specifications provided by the fall 1998 team 2.

19. Item 2f is related to technology complexity
3 months?
Item 2f is related to technology complexity
*1=yes, 0=maybe, -1=no

20. Case Example

21. Risk Evaluation form (figure 1,page 58)
3 months?
3rd risk factor (3 items)
Take 5 minutes to fill out, then discuss
*1=yes, 0=maybe,-1=no

22. Are you a risk?

23. Risk Evaluation form (figure 1,page 58)
Reminder: this includes the “developer” who will maintain (aka enhance) the system, even if that “developer” is mainly a system user.
3 months?
How many teams are affected by this issue?
How do you know you are affected?
*1=yes, 0=maybe, -1=no

24. Risk Evaluation form (figure 1,page 58)
3 months?
Usually there are several “kinds” of users – consider them separately
*1=yes, 0=maybe, -1=no

25. Risk Analysis Steps
Consider all parts of projects in which risk can occur
Identify parts of projects as either risky, not risky, or maybe.
Score total risk of project
Determine risk reduction strategies to lower the likelihood of each risk.
Review Risk score week to week to ensure reductions are working

26. Possible Risk Reduction Strategies
Reduction Strategy
Poorly defined objectives
Develop a strategic business plan.
No SPIR
Develop a strategic plan for information resources
System not focused on organizational objectives
Conduct a JAD session with managers from the organizational unit.
System requirements are unclear
Engage in requirements prototyping.
Unstructured system procedures
Document the procedures with such a top-down structured tool as DFDs.
Multiple business areas involved
Conduct a JAD session with managers from the organizational units.
Project estimated at longer than 3 months
Subdivide the project into smaller projects.
System uses unproven technology
Use prototyping to prove the technology as the design evolves.
Multiple system sites involved
Implement the system with a pilot installation or a phased approach.
Developers inexperienced in methodology
Have developers work closely with experienced instructors.
Developers unskilled at determining functional requirements
Train developers in use of the systems approach.
Developers unfamiliar with information technology architecture
Have developers work closely with experienced instructors and utilize self-study materials.
Users have little business area experience
Design system for inexperienced users.
Users have little system development experience
Conduct on-site classes in system methodologies.
Users are uncommitted to the project
Conduct JAD sessions with committed top-level managers present.
Table 4.2, p. 254

27. Risk Evaluation form (figure 1,page 58)
What risk reduction strategies are
good for a high risk on 2a?
3 months?
*1=yes, 0=maybe, -1=no 27

28. NOT this Prototype by showing existing sites
----- Meeting Notes (9/24/12 16:20) -----
COACH REGISTERS. KIDS COULD LOOK UP STATS AND TEAMS
AT THE DELIVERY 1 MEETING (CHARTER MEETING) 4TH OR 5TH MEETING WE SHOWED THE TOP RIGHT.
CLIENT WAS NOT HAPPY. IT HAPPENS BUT WOULD HAVE BEEN BETTER TO FIND OUT EARLIER
NOT this 28

29. Yes, this Reduce risk by prototyping early
----- Meeting Notes (9/24/12 16:20) -----
THEY WANTED SOMETHING LIKE NIKE.COM
PROTOTYPING AND PULLING OUT REQUIREMENTS FROM CLIENT EARLY IS VERY IMPORTANT.
DELIVERY 1 - YOU CAN SHOW PROTOTYPING AND PROGRESSING OF ITERATIONS TO SHOW YOU'RE FINDING WHAT THEY WANT. 29

30. include in appendix Evidence of Prototyping in Project Charter
This example is posted on the Client Project web page in the appendix section for the Project Charter. 30

31. Risk Evaluation form (figure 1,page 58)
What risk reduction strategies are
good for a high risk on 2c?
3 months?
*1=yes, 0=maybe, -1=no 31

32. Phased Development with multiple releases
Advantages:
(1) an early cost-benefit payoff; (2) effective test of analysis, design, and construction before the entire project is finished.
Phase #1
Preliminary Investigation
Phase #2
Analysis
Phase #3
Design
User
Analysis
Design
Construction
Construction
Review
User
Phase #4
Analysis
Review
System Test and Installation
Design
Phase #5
Phased development. Phase in the requirements so the scope grows.
Adapted from: Russ Pearlman, Tactica Technology Group
Ready aim fire, ready aim fire…..
User
Construction
Final Construction
Review
Phase #6
Release 1 Cut Over
System Test and Installation
Note: Repeated tasks for Testing & installation
(or deploy new releases)
. . .
Release 1 Cut Over
Release 2 Cut Over 32

33. Phased Development: Risk Reduction
Preliminary Investigation
Phase #2
Analysis
Phase #3
Design
User
Analysis
Design
Construction
Construction
Review
User
Phase #4
Analysis
Review
Phase #5
Design
Phased development. Phase in the requirements so the scope grows.
Adapted from: Russ Pearlman, Tactica Technology Group
Ready aim fire, ready aim fire…..
Or Fire, review, re-aim, fire, review, re-aim,
User
Construction
Final Construction
Review
Repeated user reviews are critical to success
even without early releases.
Phase #6
System Test and Installation
. . .
Release 1 Cut Over 33

34. System Development Life Cycle (SDLC) Preliminary Construction
Analysis
Inception
Release 1 R
User
Review D
Design
Release 2
Release 3
Release n… C
Preliminary Construction
Large scope and high risk -- manage with phased development and add resources when possible.
Split into multiple projects, if possible—per recommendation by Zakria Malik of HP last class.
Iterative methodology with multiple releases

35. Risk Summary All projects have risk
You may not meet the criteria expected – cost/benefit, number of resources, time, etc
You may not achieve established goals – functionality or scalability or commitment
Risk occurs in proportion to the scope of the project
The key is to identify and manage the risks.
LASTLY – Monitor risk level each week! Make it a weekly agenda item!
Large scope and high risk -- manage with phased development and add resources when possible.
Split into multiple projects, if possible—per recommendation by Zakria Malik of HP last class.

36. Reminders Group Project 2 – NDB Tonight: Due Monday, Feb 22nd, 5pm
Peer reviews due same day at 3pm (if you don’t do peer review you get a 25% discount on GP grade)
Tonight:
Pizza with Clients – 6:30pm
Double check with clients if you have already about them attended. Help them out if they get lost.

37. Group Project 2 – Report outline
Delivery One-page executive summary
Delivery Strategy discussion
Delivery Organizational Impact Statement
Delivery Functional Requirements Summary
Delivery Non-Functional Requirements Summary
Delivery Project Risk Evaluation and Risk Reduction Strategies
Delivery Milestone summary (summary of phases)
Delivery Network diagram (overview of your phases)
Delivery Gantt chart

38. Group Project 2
10. Complete a Gantt chart that shows your plans for completion of the system, tested and installed. Create a work breakdown structure (clear simultaneous phases with A-D-C-R loops), assign team members, and estimate times and dates for each activity. Assume you may not add team members, but must allocate all tasks among the team members assigned in class and the relevant staff at Global Logistics. For full credit you need at least 100 detailed activities.
And, yes, we understand that you don't have enough knowledge of this project and the environment to make realistic detailed plans. This is an assignment to force you to practice detailed planning techniques with the limited information you have.  Be as realistic as possible.

39. Group Project 2 tips Index at the top Clint & Bruce think so
Look for example documents on the Resources page
Index at the top
Are multiple releases a good idea?
Clint & Bruce think so
Look at Gantt Chart tips
Printing large formats
Taped together is marginal BUT must be clean and easy to folder and grade – see video on Canvas

40. None of this please
Picture of bad Gantts

41. Client Project tasks Have you contacted your client?
contact your client to set meeting for next week— 2/22 to 2/26
Class work day on Wednesday, Feb 24th

42. Take Charge because I’m not
Picture yourself as a consultant
You’re main goal is to add value to your client. Not complete your assignment requirements
Remember that your client is on your team. You’re not their boss and they’re not yours but their happiness matters
Take charge, set the agenda, set the time (with the client of course)
Have one person as PM / communicator with the client as least for now

43. What is immediate priority?
Start research, put together list of questions, and start gathering info
Everything you do now leads to figuring out the complete scope and prepares your charter. Make this clear to client so they know the direction
Setup client launch meeting
Setup preferred communication methods and standard meet times
Charter Meetings – March 23 to 27th

44. What is the Charter?
“Official” start of build loops and end of inception but…
…can you finish inception sooner?
You bet! Frankly you should!
It’s merely a checkpoint to review plan and agreed upon scope
Your communication and meetings should be working to finalize the charter doc asap
Don’t drag inception on for 4 weeks if you don’t have to
Explain here how we want to start off on the right foot and begin working towards a comprehensive document that we’ll review with client and team after Spring Break. That doesn’t mean we aren’t coding until then but we should be meeting many times between now and then to determine scope and start project. The Charter is the official point where we have completed inception and are fully into build if NOT ALREADY

45. Risk Evaluation--Exercise 8
In pairs or alone, use web resources, books, internships & past classes to fill in as many ideas as possible in the Risk Evaluation form.
Assume you have completed the DFDs and plan to find open-source software.
Give risk reduction suggestions for all “-1” ratings on Risk Reduction Strategies form (on back)

46. Possible Risk Reduction Strategies
Reduction Strategy
Poorly defined objectives
Develop a strategic business plan.
No SPIR
Develop a strategic plan for information resources
System not focused on organizational objectives
Conduct a JAD session with managers from the organizational unit.
System requirements are unclear
Engage in requirements prototyping.
Unstructured system procedures
Document the procedures with such a top-down structured tool as DFDs.
Multiple business areas involved
Conduct a JAD session with managers from the organizational units.
Project estimated at longer than 3 months
Subdivide the project into smaller projects.
System uses unproven technology
Use prototyping to prove the technology as the design evolves.
Multiple system sites involved
Implement the system with a pilot installation or a phased approach.
Developers inexperienced in methodology
Have developers work closely with experienced instructors.
Developers unskilled at determining functional requirements
Train developers in use of the systems approach.
Developers unfamiliar with information technology architecture
Have developers work closely with experienced instructors and utilize self-study materials.
Users have little business area experience
Design system for inexperienced users.
Users have little system development experience
Conduct on-site classes in system methodologies.
Users are uncommitted to the project
Conduct JAD sessions with committed top-level managers present.
Table 4.2, p. 254