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

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

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)

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

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

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

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 ?

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

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

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

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

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

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

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

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

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

Case Example President Students Board Client Volunteers

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.

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

Case Example

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

Are you a risk?

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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.

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

None of this please Picture of bad Gantts

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

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

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

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

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)

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