Project Planning

1. Project Planning Wendell Ocasio, M.D. Greg Pfister

2. Project Planning The purpose of Project Planning is to establish and maintain plans that define project activities The Project Planning process area involves the following: • Developing the project plan • Interacting with stakeholders appropriately • Getting commitment to the plan • Maintaining the plan (source: CMMI-DEV v1.2)

3. Commonly-seen Project Lifecycle • Phase 1-Project Initiation • Phase 2-Wild Enthusiasm • Phase 3-Disillusionment • Phase 4-Chaos • Phase 5-Search for the Guilty • Phase 6-Punishment of the innocent • Phase 7-Promotion of the Nonparticipants • Phase 8-Definition of the Requirements Gen. Dwight D. Eisenhower: “Plans are nothing. But planning is everything.”

4. Controlling Processes PMI view of project processes Executing Processes Closing Processes Planning Processes What How Why Do It Did It Planning Initiating Processes Executing

5. PMI View of Project Planning

6. SEI CMMI View of Project Planning • Establish Estimates • 1.1 Estimate the Scope of the Project • 1.2 Estimate Estimates of Work Product and Task Attributes • 1.3 Define Project Lifecycle • 1.4 Determine Estimates of Effort and Cost • Develop a Project Plan • 2.1 Establish the Budget and Schedule • 2.2 Identify Project Risks • 2.3 Plan for Data Management • 2.4 Plan for Project Resources • 2.5 Plan for Needed Knowledge and Skills • 2.6 Plan for Stakeholder Involvement • 2.7 Establish the Project Plan • Obtain Commitment to the Plan • 3.1 Review Plans That Affect the Project • 3.2 Reconcile Work and Resource Levels • 3.3 Obtain a Plan Commitment

7. Waterfall Lifecycle Methodology

8. Pitfalls of Waterfall Methodology • Software creation is inherently difficult to predict • Requirements are rarely well-understood up front by the end-users • Different definitions of “requirements”: • High-level vs. low-level • Functional vs. technical • Is something “requirement” or “design” • Does any of this matter?

9. Some alternatives to waterfall • Spiral or iterative development: • Many definitions • Problem: is spiral just sequential waterfalls? • DoD Military Health Service experiment: • “Integrated Requirements-Design” • Agile • Examples: Scrum, Extreme Programming

10. Military Health System Integrated Requirements-Design Paradigm

11. Current MHS challenge • IT products do not meet the needs of the enterprise • Poor integration – continued stovepiped systems • Lack of agility – takes a long time to add new functionality • One common root cause: • Lack of proper design

12. Current State REQUIREMENTS DEVELOPMENT Future State INTEGRATED REQUIREMENTS DESIGN • Solutions: • EA as the “Glue” • Tied to Strategy from Beginning to End • Becomes True MHS blueprint • Results: • IM/IT Products that Satisfy Mission Priorities • Enables Full Life-Cycle Portfolio Management • Problems: • Disconnect between strategy & solution • EA non-guiding • Result: • Sub-Optimal IM/IT Products MHS Enterprise Goals S E G M E N T Functional Requirements Enterprise Architecture System Development & Acquisition MHS Capabilities / Portfolio / Acquisition Balanced Scorecard (BSC) BSC Outcome Measures • Enterprise Architecture • MHS Capabilities Categorized by BSC • Direct Connect to MHS Strategy & Reality • Process Focused • “The System Shall . . .” • Few System or Technical Requirements • Limited Architecture • Narrow Scope in Individual CONOPs • Minimal Enterprise Context • Rare Integration and Interoperability focus • Integrated Requirements Design • Enables Incremental Subject Area Design within Context of Master Plan • Implementable Systems Requirements • Supports Migration to Service-Oriented Environment / Netcentricity • Used for Certification rather than design constraints • Non representative of MHS • Activity-Focused • Optimal IM / IT Solutions • IM / IT Solutions Meet End-User Needs and Users Willingly Use Them • IM / IT Products Evaluated by BSC Outcome Measures System Development & Acquisition IM / IT PRODUCTS

13. MHS Capability Lifecycle Perceive Needs 1.1 Process Submission Triage Decision 1.2 Prepare IRD Package for Investment Decision Generate Exhibits for Acquisition Documents Integrated Management Repository 1.3 Investment Decision 2.0 Acquire Build Implement Sustain 1.4 Prepare IRD Package for Execution Decision 1.5 Execution Decision Integrated-Requirements Design (IRD) Process

14. Integrated Requirements-Design • Integrated is more than simply requirements and design are both included • Many artifacts include requirements and design elements together in a single view • Integration across multiple views – all the elements in the package are connected in multiple ways (described in our architecture framework / metamodel). • The architecture repository will keep all these relationships • Each view/product will be a slice of the repository • The elements in the repository and their relationships are the fundamental pieces, not the views

15. Scrum Development Methodology

16. Typical DoD Software Process • Software Development inside ‘The Black Box’ • Requirements go in  Product comes out… later • All the while we’ll see: • Requirement Specifications • Design models (PDR/CDR) • Monthly Status Reports • Other work products…. Assures us that something is happening, but not sure what exactly • Probability that Requirements will change increases when the length of a release/dev cycle increases • Wait and Hope that we meet the customer expectations, our own expectations. • Hope is not very repeatable…  16

17. Typical ‘Project’ perspective 17

18. Software Management • What is needed: • A way for customers to see and evaluate progress before it is too late • A process that is more agile and responsive • Provide stakeholders visibility early and often • Provide visibility into the solution in its current state • Provide visibility into the process used to create the solution • A process that accepts change while having sufficient rigor to yield a quality solution 18

19. Achieving Visibility • We can address visibility through • More adaptive software management practices • More transparent management practices • Increased visibility for key stakeholders • Primary Objectives of Agile Process • Develop usable software more quickly • Provide timely and regular visibility of the solution to customers, product owners and other key stakeholders • Incorporate Quality throughout the process • Shorten feedback loops “If we can see early, we can know earlier. If we know earlier, we can adapt” 19

20. Scrum Development Process Diagram 20 Scrum is an agile management process for developing software. Scrum is an empirical process that uses frequent inspection, collaboration, and adaptive responses.

21. Agile Method Overview • Scrum • Developed by Jeff Sutherland and Ken Schwaber in 1993 • Presented at OOPSLA ’96 (Object-Oriented Programming, Systems, Languages & Applications) • Key Practices include: • Sprints are iterations of a fixed duration • Work within a sprint is fixed • All work to be done is characterized as ‘product backlog’ • Requirements, Defects, Infrastructure, Design, etc • Scrum Master mentors/manages the self organizing and self accountable teams that are responsible for the delivery of successful outcomes at each sprint • A daily standup meeting is a primary communication method • A heavy focus on Time Boxing. Sprints, standup meetings, release review meetings, sprint planning meetings and the like are all completed in a prescribed time • Scrum also allows requirements, architecture and design to emerge over the course of a project • Anticipates change rather than anticipating no change. 21

22. Scrum Definitions • Participants • Product Owner – Typically someone who is responsible for the feature set for the product • Scrum Master – Owns the process. • Scrum Team – represents the collective group of various players (developer, designer, tester, etc) that is committed to complete the set of work agreed to within the sprint. • Chickens – Stakeholders, but no direct responsibility to producing the software • Pigs – Development team responsible for building the software • Sprints • A short period of time (i.e. 2-4 weeks) where the team is focused on completing the Sprint Backlog. • Product Backlog • Represents the list of ‘all’ known requirements/features for the product. • Sprint Backlog • The subset of requirements to be accomplished for the sprint. • Daily Scrum Meeting (Daily Stand Up) • Daily call at the same time 22

23. Scrum provides visibility • A Process with consistent iterations provides: • Near term visibility • Objective evidence • Immediate feedback for both product and process • Early feedback provides us more options • Observable and Measurable increments of software on a frequent basis • Embraces change 23

24. Comparing 24

25. Conclusion Scrum is not a silver bullet Defining Done for a sprint is critical Self-adjusting through retrospective High Communications High Focus Customer involvement Transparent 25

26. Contact Wendell Ocasio, M.D. Chief Medical Officer Agilex Technologies wendell.ocasio@agilex.com 1-888-3AGILEX