The document provides an overview of JUMP (Scalable, Successful Approach to Software Project Management). It discusses key aspects of the JUMP methodology including its iterative process, roles, phases (inception, elaboration, construction, transition), reviews, artifacts, tools, best practices, and metrics for measuring success. The goal of JUMP is to achieve project commitment and consensus through formal reviews at key milestones to align projects with organizational directives.

1. JUMP: A Scalable, Successful Approach to Software Project Management Presented By: Michael Stefanini, Jet Propulsion Laboratory, California Institute of Technology Cindy Trinh, Jet Propulsion Laboratory, California Institute of Technology

2. 2 JUMP – Past and Present

3. 3 RUP Toolset Iterative Process Time-Boxed

4. Project Strategy – The Deming Model 4 No one has to change. Survival is optional. Baseline Change Improvement over Time

5. 5 Artifacts Checklists Responsibility Reviews Components of JUMP Authority Delivery

7. There are scorecards that are individualized for each role

8. All role statements are defined and have clear responsibilities, authority, and deliverables for each phase

10. DBA

11. Training

12. Change Mgmt

13. Communications

15. Config Mgmt

16. Tech Writing

17. Scheduling

18. Dev DBA

19. Dev SADev Support Lead Stakeholders System Engineer Resp Dev Resp Line Manager Developers Dev Team Standards and Process Team Architect Analyst Technologist All Phases SMEs Ops Team Support Team Core Team Sponsor

20. 8 Inception Phase Elaboration Phase Construction Phase Transition Phase JUMP Phases

21. 9 Inception Phase Elaboration Phase Construction Phase Transition Phase RFAs Requests for Action Operational Readiness Review [opt] MMRs Δ ORR Monthly Management Reviews Conceptual Design Review [opt] CDR IncRev PDR PR ORR IOC LCO LCA Life-Cycle Architecture Review Life-Cycle Objective Review Initial Operational Capacity Project Review Inception Review Preliminary Design Review Operational Readiness Review JUMP Phases and Milestones Project Vision & Scope Requirements & Business Processes Observations and Metrics Prepare Production Quality Release of Solution Major Features SRD Baseline New Solution SRS [opt] Define Operational Processes High-Level Budget & Schedule Evaluate Solutions & Trade Study Move Solution to User Community Risk Analysis Final Project Plan

22. Inception Phase Goal One: Create Excitement for Implementing this Project The objectives of the project are stated clearly, so that the needs of every stakeholder are considered Scope and boundary conditions, acceptance criteria, and some requirements are established 10

23. Elaboration Phase Goal One: Flesh out the details An analysis is done to determine what it will take to achieve the vision and meet the success criteria of the Inception Phase The risks, details of vision, choice of architecture, and expenditure of resources are also determined 11

24. Construction Phase Goal One: Build it The Construction Phase is a manufacturing process It emphasizes managing resources and controlling operations to optimize costs, schedules, and quality 12

25. Transition Phase Goal One: Hand off to Operations Dev Team gives product to the users and the Operations Team Involves issues of education, deployment, configuration, support, and operations 13

26. 14 JUMP Reviews

27. JUMP Review Goals and Intent Goal One: Achieve Commitment and Consensus The four formal JUMP Reviews are Confirmation and Commitment Reviews, not Design Reviews JUMP Reviews will focus on the completion of JUMP Checklists and Artifacts JUMP Reviews will assure commitment from responsible team members and interfaces Reviews also align projects with the organization’s directives and enforce policies Architecture and Technology Consolidation IT Security Requirements Sustainable Operations, Architecture, and Planning 15

28. Scorecards are what count! Scorecards & Review Materials Scorecards are issued to all reviewers in order to standardize the review itself Recommendations for Action (RFAs) will be used to capture questions, concerns, and comments and are used as a change control mechanism All RFAs must be addressed promptly, can only be closed by the originator or a Board Member 16

29. Scorecard for Domain Architect

30. JUMP Tools: Issues/RFA List Purpose: Monitor and Respond to Project Issues Works like a Specialized To-Do List Used to monitor RFAs, Customer Issues, and other problems E-Mail Notification and Outlook Integration 18 Track Related Issues

31. 19 Elaboration Walkthrough

32. 20

33. Project Metrics 21

34. Kick off Meeting 22

35. JUMP Checklists Purpose: Show required and Optional JUMP Phase Requirements This checklist not only shows the required JUMP tasks, but works as an assignment sheet, notebook, and status list as well. Performance Indicators are generated based on the status of the items on this list 23 Monitor status and report on progress Adjust the list to suit your project

36. Requirements in Quality Center 24 Details of the Requirements are tracked

37. JUMP Tools: JUMP Schedule Purpose: Track major schedule and delivery milestones This list serves as a simple project schedule. A more detailed MS Project schedule is also provided as a template. The provided schedule already includes all required (and many optional) JUMP milestones – a turn-key project schedule! 25 Drag and Drop Milestones to create Schedule Add, Remove, Filter, and Report on Deliveries

38. Master Schedule 26

39. Sample Mock-Ups 27

40. Mock-Ups (Wire Framing) 28

41. Technology Positions 29

42. UX Evaluation Report 30

43. Weekly Project Status Reports 31

44. 32 Measuring Success

45. 33 Transition Schedule-Induced Delivery (De-Scoped) Each Phase Builds upon the Previous Construction Construction Elaboration Elaboration Inception Undocumented Requirements Scope Creep Build and Fix Shifting Expectations Initial Agreement Project Failure results from not being in position to meet the customer’s needs

47. Planning > 5%, but <10% of project costs 100% - 120% Overruns

48. Planning > 10% of project costs  0% - 50% OverrunsFront-End Planning includes 1. Defining the scope 2. Developing the requirements 3. Preliminary design Source: NASA study performed in 1990

49. PMI Study In the US, < 5% of total project time is spent planning with 150-200% overruns—NOT ENOUGH In Japan, > 30% of total project time is spent planning with 0-20% overruns—TOO MUCH Based on a 1995 study by C. Christensen PMI suggests >20% of total project time be spent planning Based on Generic Industry Studies 35 PMI suggests >20%

50. 36 Inception Phase Elaboration Phase Construction Phase Transition Phase Typical Resource Use by Phase

51. 37 Best Practices

52. JUMP Best Practices Develop software iteratively Software should be developed in small increments and short iterations – a Multi-Layered Phased approach Focus on risk and high value Constant user feedback and engagement Early cohesive core architecture Detailed mock-ups of functionality Take care not to confuse mock-up with product! Manage requirements and scope creep Change and Configuration management 38

53. Time Boxing: Set Expectations Early! 39 Schedule(Time) Scope(Quality) Budget(Resources) You can’t get it faster, better and cheaper!

54. Customer Involvement Keep customers isolated from development and testing efforts as well as internal policies Minimize disruptions and avoid having the customer become a member of the development team (or Management Team!) Keep the customers involved with UX reviews and screen-shot updates Conducting Training Communications and Outreach Change Control 40

55. Working with Sponsors, Stakeholder, Users, & Customers Ensure your Sponsor (or delegate) is a member of the Project Recruit anyone who judges the quality of your project Share the Vision often but don’t distract from your progress! Gold-plating is bad businesses – Foster conservative expectations Give them what they pay for Build creep into your margin 41

56. 42 Development Services Catalog

57. 43

58. 44 JUMP TOOLS

59. JUMP Tools: Risk List Purpose: Catalog and Track all identified project risks and mitigations. Severity is automatically calculated Performance indicators are keyed to react to the status and severity of risks Un-Mitigated Red-Risks are automatically identified 45 All standard risk information is tracked in this list. Status reports and views are generated

60. JUMP Tools: To-Do List Purpose: Assign and track Action Items Customize the list to meet your project needs Individual and group assignments Multiple To-Do Lists can be created for several major project areas E-Mail Notification and Outlook Integration 46 The list is pre-populated with tasks required to complete your JUMP Project Setup!

61. JUMP Tools: Estimates to Complete Purpose: Monitor budget status Designed to easily provide Estimate-to-Complete (ETC) information Auto-calculates variance and ETCs Easily allows for budget baselines and status Provides graphs Track hard and soft liens Performance Indicators keyed off of budget status 47 Automatically creates budget graphs on the resources pages

62. Key Performance Indicators Purpose: Monitor and report on overall project health Tracks 11 key performance indicators (KPI) 8 KPIs are tracked automatically 48 KPI details for key areas are provided

63. JUMP Tools: Document Tracking Purpose: Track and Control Project Documentation Directory Structure provided by section IM Integrates with Office Applications Full workflow and reporting capability A separate Documents area is provided for JUMP Templates E-mail documents directly to the site 49 Enable Drag-and-Drop, Alerts, and RSS feeds

64. 50 Tales from the Pit

65. What is Your Vision? 51

66. Communicating Vision Remember Goal One: Create Excitement for Implementing this Project Just because you see something, does not mean you see the SAME thing Communicating a vision can be difficult but must be accomplished or the project can not succeed This vision is not the same as the scope or a list of features. It is the “Elevator Speech” that describes the sponsor’s BUSINESS GOALS of the entire effort. 52

67. Scope Will Creep It’s Human Nature: The more you think about a project, the more you will discover new ways to use or improve it To manage scope creep Include only clearly negotiated features in Inception Phase Plan your resources to include Margin for these extra items Ensure constant communication with your sponsor and customers Manage your scope with a process that evaluates the impacts of new additions or changes Manage developer’s “Gold Plating” – this is self-imposed scope creep! 53

68. Example of ITIL Success Criteria 54 ITIL

69. 55 Traps

70. How Managers Destroy Projects Usually, the Managers drive to deliver on time and on budget will be at odds with the development team’s desire to create a quality product Management is well meaning and may be using proven techniques, but some have the potential for disaster Here are four ways managers may unwittingly sabotage a project 56 courtesy of the TechRepublic’s Robert Bogue

71. Trap #1: False Dates Project managers must put dates out in front of the group to motivate them but when the dates aren’t realistic and they are consistently missed, it’s time to reevaluate the plan The problem is that when a really important date comes up there will be little drive to hit it because an expectation has been set that the date isn’t important After all if the team misses 10 dates in a row, how important can the 11th date be? If timelines are being set that have no penalty behind them and people aren’t meeting them it’s time to put some teeth behind them or move the whole timeline Developers need to be able to concentrate on their work The desire to meet the date and the confusion about whether the date is real or not may lead to developers skipping critical steps in the development process and, in doing so, creating problems that will be hard to find 57 courtesy of the TechRepublic’s Robert Bogue

72. Trap #1: Solution Developers need to be involved in setting the schedule Developers need to be held accountable when schedules are missed Managers need to aggressively defend the project schedule and the developers 58 courtesy of the TechRepublic’s Robert Bogue

73. Trap #2: Pretend All Is Well When it comes to project management, ignorance is not bliss Risks turn into a reality and then panic sets in Everyone scrambles to put together the rest of the pieces of the project and the quality of the project will suffer from the hastiness of the final assembly Of course, this problem isn’t fully realized until the rush that is caused when the business learns about the true state of the project after believing that nothing was wrong for a long time 59 courtesy of the TechRepublic’s Robert Bogue

74. Trap #2: Pretend All Is Well Solution Frequent and open status reports: Try the 2-minute status report format on a daily or weekly basis Utilize Project Management Office resources or your line management to report on an issue within a project. You can report anonymously to the IT PMO if you need to 60 courtesy of the TechRepublic’s Robert Bogue

75. Trap #3: Ignoring Dependencies In software development we have a great number of techniques for delaying dependencies We can stub out functions, remove connecting infrastructure, or bypass extensive error handling All of these techniques when used correctly can be helpful to moving a project along However, when it becomes required to get the project completed and when the costs of these techniques are not factored into the planning, trouble sets in Especially when it comes to unforeseen dependencies, the clean up cost can often become a non-trivial part of the project’s overall cost—and one that isn’t discovered until the very end External interfaces pose even greater risks Project managers and developers often either defer discussing interface agreements or each assumes the other is working to ensure the interface will be ready For unforeseen dependencies, external cooperation to provide support on the project’s time-table may be tough to get 61 courtesy of the TechRepublic’s Robert Bogue

76. Trap #3:Solution The solution resides with the Responsible Developer The Task Plan should detail any internal and external interfaces that need to be managed The developers must then communicate with the project manager if they need any political support in ensuring external interfaces are ready, but the technical aspects of the interfaces lie with the development team If the Project manager ignores or defers any issues that arise, the development team must elevate the problem to another level (see Trap #2) or the project could fail 62 courtesy of the TechRepublic’s Robert Bogue

77. Trap #4: Time Boxing Getting top honors in the list of things which can destroy software quality is the practice of time boxing Used at its extreme it often means that the code isn’t complete, it’s merely pushed along the process Time boxing works—most of the time—because it does three things It forces the developer to be creative in finding a solution that fits within their budget It eliminates unnecessary frills and scope-creep that don’t necessarily add value It ensures iteration remain smaller and manageable while deferring good ideas for later The intent is to get the thing working and rely on a QA phase where detailed testing will hopefully reveal any problems that there may be with the code Time boxing doesn’t always work if The problem is unknown or the technology isn’t proven The box is made so small there’s no possible way to complete the objective within the allotted time Used for research and development, problem solving, etc. When time boxing is used correctly it shouldn’t result cut corners and poorly developed software It should be used with moderation to ensure the lowest cost, quickest and best quality software possible 63 courtesy of the TechRepublic’s Robert Bogue

78. Trap #4: Solution Time-Boxing works well when the schedule is well designed and significant margin has been allocated It is the responsibility of both the Project Manager and the Responsible Developer to ensure that the schedule and Task Plan are both realistic and have sufficient margin Sticking to a failed Time-Boxed schedule for the sake of meeting a dead-line is not a good idea Time-Boxing is used to manage scope-creep and defend the project plan – NOT to manage the schedule or deadlines Time-Boxing results in removing functionality or adding resources – not sacrificing quality If the schedule runs out of margin – Re-Plan and hold a review 64 courtesy of the TechRepublic’s Robert Bogue

79. 65 Thank You