Earned value, XP and government contracts

© 2003 CH2M HILL Communications Group
Page 1
Earned Value, XP and Government Contracts
Can XP live in an Earned Value
reporting government contracting
environment?

Data contained on this sheet is proprietary; use or
disclosure is prohibited. Page 2
BD02005 A 08/29/02
What’s the Issue Here?
 Earned Value Management is the standard reporting method for many
government and large infrastructure projects.
EV has little exposure in commercial software development
 Agile software development methods are entering this business domain.
Just now being understood in government contracting
 Merging the two “cultures” would seem to be undesirable by both parties
In fact both cultures have much to offer each other
 To quote Kent Beck
“Optimism is an occupational hazard of software development, feedback is the
cure.”
Earned Value is the feedback in “units of analysis” understood by the funding
agency.

BD02005 A 08/29/02
Basic EV versus Agile Processes
Earned Value Agile Development
A Big Picture of the project from a
starting baseline.
Continuous production of useable
software at fine grained iteration
boundaries
Accurate estimates at completion
as early as 15% from the start
using “earned” value for each
deliverable.
Prediction of the next iterations
effort, with a fixed duration using
“yesterday’s” weather as a
measure of tomorrow’s progress
End–to–end value production
tracking using variable units of
production and measure.
Iteration–to–Iteration productivity
tracking using fixed units of
production and measure.

BD02005 A 08/29/02
Earned Value in a Single Slide

BD02005 A 08/29/02
Some Fundamental Concepts of Earned Value
 Never relate what was planned to be spent (BCWS) to the actual amount spent
(ACWP).
This tells us nothing of value
It can even warp our thinking into attempting to under–spend our allowed amount
to report favorable numbers.
 Cost Performance (CV) must focus on what has been accomplished (BCWP)
versus what was invested to accomplish that work (ACWP)

BD02005 A 08/29/02
The Realities of Government Contracting
 Traditionally a “linear” development process rooted in CMM
Many of the linear aspects are critical to the success of the project.
Nuclear work processes, mission critical support, fault–tolerant applications
 High–ceremony work artifacts
Department of Energy is the customer
They get to say what artifacts are needed
 Formal “project controls” and “program management”
EAI–748A defines the earned value deliverables
This is “baked” into the contract
More importantly, it’s how we get paid – by reporting “earned value” to plan.

BD02005 A 08/29/02
Our Formal Project Delivery System
 XP–like development process
“Like” since we don’t perform all 12 practices
“Like” since we don’t call it XP, but we do call it “agile”
 Balanced Scorecard strategy and objectives
This is an IT governance process widely used in large organizations
It is supportive of teams, projectizaiton, and agile processes
 Project Portfolio Management
Traditional PPM, with weekly reporting of progress to plan
PPM management team defines projects and marshals the “customer”
 Team Based delivery systems
Teams are everything
Projects are the deliverables from teams

BD02005 A 08/29/02
Our Challenge and Opportunity
 Most experience with Earned Value is on large projects.
>$100M
Newer experiences on “smaller” projects – “micro EV” is the term used in the
industry.
 CMMi Level 3 or 4 is the “norm”
Our mission is to provide applications and infrastructure for an $11,000,000,000
de–construction project of critical importance to the nation.
Evidentiary materials are still in three–ring binders for assessment and certification
 Introducing agile methods into this environment is a challenge
Not because of the processes
But because of the financial reporting requirements, CMM compliance, and
operational security requirements

BD02005 A 08/29/02
XP Practices Deployed at RFETS
XP Practice Our Deployment
Planning Game Biweekly planning session
Small releases Biweekly iteration releases with full integration with Configuration
Management, SQA, and IV&V
Metaphor Not used
Simple Design Forced on team by “time boxed” schedules
Test First Design No test fixtures yet, but 100% UT is our goal
Refactoring Not a major impact yet, since system are early in lifecycle
Pair Programming Not usually allowed because of code access security requirements. Some
PP in small groups
Collective
Ownership
Not usually allowed due to Configuration Management and Cyber Security
requirements
Continuous
Integration
Heavy investment in tools appears to be needed, but some progress for
daily builds
40 Hour Week Mandated by contract, actually 80 hours in two weeks
On Site Customer Customer Relationship Manager (CRM) with detailed process knowledge
Coding Standards Inherited from CMM

BD02005 A 08/29/02
Project Profiles
 Nextel secure voice provisioning system
Inventory control
Phonebook management
Order management
Billing distribution
 IT Department Portal development
.net based system
Integration of legacy and new systems
User supplied connections of other sites and applications

BD02005 A 08/29/02
Drivers for Agility
 Continuously changing regulations and agency orders
 Changing customer representatives
 Limited funding sources
 Fluid workforce with multi-project assignments

BD02005 A 08/29/02
EVMS at the Iteration Level
BCWS – from Work Authorization, linear spread or manual by period
ACWP – from ETS (time cards)
BCWP – from “testable requirements”
Start Month 1 Month 2 Month 3 Month 4 End
Week 1 Week 4.3Week 4Week 3Week 2
Month 5
BCWS – Linear distribution from WA budget
BCWS – User defined over duration of the WA
ACWP from ETS
BCWP from “testable requirements”
Iteration Iteration Iteration
Stories = BCWS
Tasks = BCWS in more detail
Assignments = ACWP
Velocity = BCWP
Testable Requirements = 0%/100% BCWP

BD02005 A 08/29/02
EVMS at the Iteration Level
 Integration of Earned Value Management and XP takes place at the iteration
boundaries
 Each iteration forms a min-EVMS cycle
BCWS is the estimate of the effort for the iteration
BCWP is the “value” of the testable requirements
ACWP is the actual effort to deliver the testable requirements
 The challenge is to define the BCWP as a percentage of a large set of
deliverables
“Re-baselining” is major challenge since a “fixed” baseline is normal for EVMS
Dividing the project into major sections is the approach to “stabilizing” the baseline

BD02005 A 08/29/02
Three Critical Success Factors
 The quality of the baseline
Iteration boundaries need to have good estimates of effort
Macro level estimates of project variables – cost and schedule
 The performance against the baseline
Capture actual labor hours against budget
Accurate estimates of “value” (BCWP) from testable requirements
 Management’s determination to influence the results given performance indices
Full by-in of processes and outcomes
Willingness to “let the process evolve”
Incorporation of agile processes with CMMI Level 4 framework

BD02005 A 08/29/02
Our current approach
 Replace XP’s velocity with Earned Value metrics.
 Create fine–grained measures of BCWP using “testable requirements.”
 Establish the BCWS baseline at the beginning of each iteration.
 Capture ACWP through a time keeping system.
 Compute Cost Variance, Schedule Variance from the three base earned value
metrics
 Compute Estimate at Completion (EAC) and Estimate to Completion (ETC)
from these base metrics as well.

BD02005 A 08/29/02
Embedding XP in a Large Context
 Much of the “noise” in XP is how to position these practices in a larger context.
 We take the position
XP is about writing code
Providing supporting processes for writing code
Delivering code to the customer
 There are other activities in the software business though
Project management
Funding management
Regulatory and Order compliance
SV&V
Cyber Security
SQA

BD02005 A 08/29/02
Embedding XP in a Large Context
XP Delivery
Solution
Architecture
Delivery Management
 Solution Architecture – is business focused
 XP Delivery – is code focused
 Delivery Management – is cost and schedule focused
 Schedule management –
creation and maintenance of
top level schedules
 Budget and Finance
management – financial plans
and reporting to the funding
agency
 Scope management –
interactions with external
dependencies
 Change control and integration
disposition

BD02005 A 08/29/02
Our Current Problems with This Approach
 Dedicated customer
 Customer with consistent vision of the outcome
 Middle management resistance
 Culture of “agile” versus “command and control”
 Integrating EV tools with XP practices
 De-programming senior management of the term “extreme”
 Multiplexing team resources to higher priority projects
 Moving from maintenance and operations to process improvement

BD02005 A 08/29/02
What We’ll Do Different in the Next Round
 Dedicated resources – no shared anything
Our current environment multiplexes development resources
 “Single Voice” customer – too many good opinions of an outcome
All “voices” have validity
Single “chartered” outcome prior to XP project start
 Simple project – pick a “no brainer” project
Too much “discovery” as well as process deployment
 Clearly define outcome – pre-defined requirements
“Pre packaged” requirements
 Much higher visibility with middle management
Continuous training effort

BD02005 A 08/29/02
What’s Next
 Increase UT tools
 Roll out EVMS to all software projects
 Produce a “working example” for everyone to see
 Education of modern processes and their value to our contract
 Incorporating agile practices in CMMI Level 4 framework

Earned value, XP and government contracts

More Related Content

What's hot (20)

Similar to Earned value, XP and government contracts (20)

More from Glen Alleman (20)

Recently uploaded (20)

Earned value, XP and government contracts