© 2008 agilex technologies, inc. project planning wendell ocasio, m.d. greg pfister

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

Project Planning

Wendell Ocasio, M.D.

Greg Pfister

2© 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 v1.2)


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.”


PMI view of project processes


PMI View of Project Planning


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


Waterfall Lifecycle Methodology


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?


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


Military Health SystemIntegrated Requirements-Design Paradigm


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

Current StateREQUIREMENTS DEVELOPMENT

Future StateINTEGRATED REQUIREMENTS DESIGN

Enterprise Architecture

Functional Requirements

• “The System Shall . . .”• Few System or

Technical Requirements• Limited Architecture• Narrow Scope in

Individual CONOPs– Minimal Enterprise

Context– Rare Integration

and Interoperability focus

Problems:•Disconnect between strategy & solution•EA non-guiding Result:•Sub-Optimal IM/IT Products

Solutions:•EA as the “Glue”•Tied to Strategy from Beginning to End•Becomes True MHS blueprintResults:•IM/IT Products that Satisfy Mission Priorities•Enables Full Life-Cycle Portfolio Management

MHS Capabilities / Portfolio / Acquisition

Balanced Scorecard (BSC)BSC Outcome Measures

• Used for Certification rather than design constraints

• Non representative of MHS

• Activity-Focused

Enterprise Architecture•MHS Capabilities Categorized by BSC•Direct Connect to MHS Strategy & Reality•Process Focused

Integrated Requirements Design• Enables Incremental Subject Area Design

within Context of Master Plan

• Implementable Systems Requirements

• Supports Migration to Service-Oriented Environment / Netcentricity

MHS Enterprise Goals

System Development &

Acquisition

Optimal IM / IT Solutions

• IM / IT Solutions Meet End-User Needs and Users Willingly Use Them

• IM / IT Products Evaluated by BSC Outcome Measures

IM / IT PRODUCTS

System Development &

Acquisition

SEGMENT

Integrated

Management

Repository

Generate Exhibits for

Acquisition Documents

Perceive

Needs

1.1 Process

Submission

1.2 Prepare IRD Package

for Investment Decision

1.3 InvestmentDecision

1.4 Prepare IRD Packagefor Execution

Decision

1.5 ExecutionDecision

TriageDecision

2.0 Acquire

Build

Implement

Sustain

MHS Capability Lifecycle

Integrated-Requirements Design (IRD) Process


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


Scrum Development Methodology


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


Typical ‘Project’ perspective

17

Iteration #2Iteration #3

#4#5

FCCC1

CC2

Limited testing, waiting for code to be feature complete Increased testing cyclesDaily builds increase as the project progresses, typically become daily prior to FC.

Requirements are more volatile during Iteration #1 & 2

SRSIteration #1

Sprint #1Sprint #2

Sprint #3Sprint #4

Sprint #5Sprint #6

Sprint #7Sprint #8

Testing starts early providing feedback with time to adjustDaily builds occur on a regular basis sooner.

Requirements can change because we have more chances to adjust

Scru

mEx

istin

g


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


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


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


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


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


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


Comparing

24

Iteration #2Iteration #3

#4#5

FCCC1

CC2

Limited testing, waiting for code to be feature complete Increased testing cyclesDaily builds increase as the project progresses, typically become daily prior to FC.

Requirements are more volatile during Iteration #1 & 2

SRSIteration #1

Sprint #1Sprint #2

Sprint #3Sprint #4

Sprint #5Sprint #6

Sprint #7Sprint #8

Testing starts early providing feedback with time to adjustDaily builds occur on a regular basis sooner.

Requirements can change because we have more chances to adjust

Scru

mEx

istin

g


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


Contact

Wendell Ocasio, M.D.Chief Medical OfficerAgilex [email protected]

© 2008 agilex technologies, inc. project planning wendell ocasio, m.d. greg pfister

Documents

agilex technologies

project lifecycle phase

project resources

project risks

project activities

purpose of project planning

project initiation phase

plan commitment slide