Project Planning Wendell Ocasio M D Greg Pfister

Project Planning Wendell Ocasio, M. D. Greg Pfister © 2008 Agilex Technologies, Inc. www. agilex. com

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 v 1. 2) © 2008 Agilex Technologies, Inc. 2 www. agilex. com

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. ” © 2008 Agilex Technologies, Inc. 3 www. agilex. com

PMI view of project processes © 2008 Agilex Technologies, Inc. 4 www. agilex. com

PMI View of Project Planning © 2008 Agilex Technologies, Inc. 5 www. agilex. com

SEI CMMI View of Project Planning § Establish Estimates – – § Develop a Project Plan – – – – § 1. 1 Estimate the Scope of the Project 1. 2 Estimates of Work Product and Task Attributes 1. 3 Define Project Lifecycle 1. 4 Determine Estimates of Effort and Cost 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 © 2008 Agilex Technologies, Inc. 6 www. agilex. com

Waterfall Lifecycle Methodology © 2008 Agilex Technologies, Inc. 7 www. agilex. com

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? © 2008 Agilex Technologies, Inc. 8 www. agilex. com

Some alternatives to waterfall § Spiral or iterative development: – Many definitions – Problem: is spiral just sequential waterfalls? § Do. D Military Health Service experiment: – “Integrated Requirements-Design” § Agile – Examples: Scrum, Extreme Programming © 2008 Agilex Technologies, Inc. 9 www. agilex. com

Military Health System Integrated Requirements-Design Paradigm © 2008 Agilex Technologies, Inc. 10 www. agilex. com

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 © 2008 Agilex Technologies, Inc. 11 www. agilex. com

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

Perceive 1. 1 Process Needs Submission MHS Capability Lifecycle Triage Decision 1. 2 Prepare IRD Package for Investment Decision Generate Exhibits for Acquisition Documents Integrated 1. 3 Investme nt Decision Management Repository 2. 0 Acquire Build Implement Sustain Integrated-Requirements Design (IRD) Process 1. 5 Execution Decision 13 1. 4 Prepare IRD Package for Execution

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 © 2008 Agilex Technologies, Inc. 14 www. agilex. com

Scrum Development Methodology © 2008 Agilex Technologies, Inc. 15 www. agilex. com

Typical Do. D 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… © 2008 Agilex Technologies, Inc. 16 www. agilex. com

Typical ‘Project’ perspective © 2008 Agilex Technologies, Inc. 17 www. agilex. com

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 © 2008 Agilex Technologies, Inc. 18 www. agilex. com

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” © 2008 Agilex Technologies, Inc. 19 www. agilex. com

Scrum Development Process Diagram § Scrum is an agile management process for developing software. Scrum is an empirical process that uses frequent inspection, collaboration, and adaptive responses. 20 © 2008 Agilex Technologies, Inc. 20 www. agilex. com

Agile Method Overview § Scrum – Developed by Jeff Sutherland 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. © 2008 Agilex Technologies, Inc. 21 www. agilex. com

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 © 2008 Agilex Technologies, Inc. 22 www. agilex. com

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 © 2008 Agilex Technologies, Inc. 23 www. agilex. com

Comparing © 2008 Agilex Technologies, Inc. 24 www. agilex. com

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 © 2008 Agilex Technologies, Inc. 25 www. agilex. com

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