An exercise on Earned Value Analysis ?

EVA: Earned Value Management (EVM):(The things you earned according to

milestones and the paymants are according to finish each part of the project)
• It adds a third dimension on costs: Planned Cost, Actual Cost, Earned Value
• EVA is calculated as comparison to the Performance Measurement Baseline (PMB)
• PMB at minimum is a list of milestones with actual dates
 BCWS: (PV) Budgeted Cost of Work Scheduled (planned)
 ACWP: (AC) Actual Cost of Work Performed (burned)
 BCWP: (EV) Budgeted Cost of Work Performed (Earned)
: Cost Variance=BCWP – ACWP (=EV-AC)
• >0 Then Under Budget  • <0 Then Over Budget 
: Schedule Variance=BCWP – BCWS (=EV-PV)
• >0 Then Ahead of Schedule  • < 0 Then Behind Schedule 
: Cost Performance Index=BCWP / ACWP (=EV/AC)
: Schedule Performance Index=BCWP / BCWS (=EV/PV)
Problems are when these indexes are less than 1
: Critical Ratio=SPI x CPI = it‟s a proportional combination
• 1 = everything is on track • < 1 = worse than planned • > 1 = better than planned
• Pragmatically:
– > 0.8 and < 1.2 = acceptable– < 0.8 = too bad – > 1.2 = over-performing

• Consistent unit of measure for total progress

• Consistent methodology
– Across cost and completed activity– Apples and apples comparisons
• Ability to forecast cost & schedule
• Can provide early warnings as early as 15%

• A full WBS is required • Beware of GIGO: Garbage-in, garbage-out

• BCWS: Use „loaded labor‟ rates if possible- Consider direct pay and overhead
• Remember that EVA variables are aggregate figures
–may hide where the problem lies–counterbalancing issues - Over in one area vs.
under in another area
Requirement gathering techniques:

 Interviews
Best practice: use „context free‟ questions
• Early questions which are applicable to any project that do not imply answers, in
order to obtain „global‟ properties of the problem and solution
 Document Analysis
Review of existing documents such as: Business plans-Market studies-Contracts-
(RFP)-(SOW)-Existing guidelines-Analyses of existing systems and procedures
 Brainstorming
Idea generation & idea reduction-Through group meetings
• Minimize criticism and debate:Editing occurs at end of meeting or later
• Aim for quantity
• Mutate or combine ideas
Reduction best practices
• Voting-Blending-Applying criteria-Scoring
 Requirements Workshops
y 1-5 days with Users & stakeholders
: • Good for consensus building-Builds participant commitment-Less
expensive than interviews-Provide structure to analysis process-Involving users
across organizational boundaries-Identifying priorities and contentious issues

• Type of req. workshop using a facilitator proposed for Rapid Development

 Prototyping
When writing code, takes less time than asking question.
- Quick and rough implementation-Good communications mechanism-Can be
combined with other techniques such as JAD-Issues: creating the mis-appearance
that development is more complete than it actually is
 Use Cases

Text structure: Use case(ID)-Goal-Pre-conditions-Primary & secondary actors-

Trigger-Description-Business rules-Open issues
 Storyboards
Set of drawings depicting user activities-Paper prototyping-Drawing processes
 Agile methods, e.g., SCRUM user stories
A very high level definition of what the customer wants the system to do.
Product Backlog
dependent)As a <USER>-I want to <PRODUCT
FEATURE>-so that <ACCEPTANCE CRITERIA>-[and not <OUT OF SCOPE>]
Risk Management
 Potential Problems
 Analyze, identify and plan how to face the risk
 Goal: avoid a crisis ( every thing can happen, but we do not want to do not
know what is going to happen)
 If risk become a problem then we have lost sth.
 If a risk is not managable then avoid it

Risk Management
• Types of risk:
 Schedule:
Schedule compression (customer, marketing, etc.)
 Cost:
Unreasonable budgets
 Requirements:
• Incorrect (Wrong product)
• Incomplete
• Unclear or inconsistent
• Volatile( no body wants it any more)
 Quality Risks
 Operational Risks

Risk Identification
 Get your team involved in this process
• Don‟t go it alone
 Produces a list of risks with potential to disrupt your project‟s schedule (but
also budget, quality, …)
 Use a checklist or similar source to brainstorm possible risks
Risk Analysis
 Determine impact of each risk
 Risk Exposure (RE) = (Probability of loss * size of loss)
 Statistically are “expected values”
 (Pre risk management)Sum all REs to get expected overrun
 Estimating size of loss
• Loss is easier to see than probability
– You can break this down into “chunks” (like WBS)
 Estimating probability of loss
• Use team member estimates and have a risk-estimate review
• Use Delphi or group-consensus techniques
• Use gambling analogy” “how much would you bet”
• Use “adjective calibration”:
– highly likely– probably– improbable– unlikely– highly unlikely
Risk Prioritization
 Remember the 80-20 rule
 Often want larger-loss risks higher
• Or higher probability items
 Possibly group „related risks‟ to identify which risks to ignore

Risk Control
Risk management palaning, resolution and monitoring

Risk Resolution (5 Types)

• Avoidance (Do not do it. ex: scrub from the system)
• Assumption (just monitor and do not do anything else, it may occur)
• Control (contingency. ex:allocate extra test resources)
• Knowledge Acquisition (learn/buy/prototype)
• Transfer (off project, team, critical path)

Risk Monitoring
Top 10 Risk List
• This week Rank
• Previous Rank
• Weeks on List Rank
• Risk Name
• Risk Resolution Status
A low-overhead best practice
Interim project post-mortems
• After various major milestones
Change Control

The Feature-Creep Phenomenon:

Avg. project has 25% change in requirements during development
The longer the project, the more likely to change.
Sources of change:
• Marketing: want to meet customer‟s check-list
• Developers: want to perfect previous release deficiencies
• Users: want more functionality or now „know‟ what they want

Overly detailed specs. Or prolonged requirements phase are not the answer

LIFE CYCLES OF WORK PRODUCTS

Change control is a process:

The explanation of the graph:

Within any given project, each work product developed during the project will
progress through a series of stages from initial concept to final release.
It begins in a state of formative development. During development, changes are
made informally and work progresses using revision control.
At the end of the project, it undergoes formal review and acceptance. Once
accepted, the work product enters a state of acceptance where changes are
no longer permitted to the item without formal change control. Finally, after final
acceptance, the work product is frozen in preparation for being released.
Feature Set Control:

 Early Stages
(Building the best possible software within the available time.)
1. Minimal Specification
Too many details are not always good.

• Wasted effort-Obsolescence-Lack of efficacy -- details do not guarantee success-

Overly constrained design-User assumption that costs are equal (UI ex.)

• Improved morale and motivation-Opportunistic efficiency-Shorter req. phase

• Omission of key req.-Unclear goals-Gold plating-Used for the wrong reasons

– Lazy substitute for doing good requirements

• Used only when req. are flexible-Capture most important items-Involve key users
2. Requirements Scrubbing

• Eliminates all effort-The earlier the better- Done during or right after Req.

Eliminate all but absolutely necessary requirements-Simplify all

complicated requirements-Substitute cheaper items
3. Versioned Development
from the current version

 Mid-Project
• Effective change control
– Set up a Change Control Board- Structure: representatives from each stakeholder
- Process: perform change analysis - Like a Triage : Allocating scarce resources
– Adopt Configuration Management Tools in order to support working cycle
 Late-Project
• Determine the priorities and Feature cuts- Stabilize the requirements

3 Approaches for Project Recovery:

1. Cut the size of the software
2. Increase process productivity
3. Slip the schedule, proceed with damage control
People Dimension:

Staffing
• Typical profile:Projects do not typically have a „static team size‟
Who and how many,varies as needed

• Roll-on – Roll-off:
PM must have a plan as to how & when
-on:Hiring or „reserving‟ resources- Ramp-up time
– Learning project or company
-off:Knowledge transfer-Documentation-Cleanup
Hiring Guidelines
“Hire for Attitude, Train for Skill”-Look for: “Smart, Gets Things Done”-Balance
Team Models

• Problem resolution(Focuses on 1-3 specific issues), creativity(New product

development), tactical execution (Carrying-out well-defined plan)
????????????
:Decompose via hierarchy, into optimal sizes
4-6 developers less than 10
1-Business team:Technical lead + team; most common-Can be strong or loose
hierarchy-Democratic Team
2-Chief-programmer team:Surgical team; star at top; ego issues, Difficult to
achieve, appropriate for creative projects or tactical execution
3-Skunkworks team:Group of smart people, Off-site; pro: buy-in; con: minimal
visibility, Applicable: exploratory projects needing creativity
4-SWAT team:Highly skilled/specialized for tactical execution; Ex: security team
Resource Allocation Tools
 RAM

have totals/summary at end of row or column

(ex: total Contributors on a task)
Simple ram:

Ram with stakeholders:

 Skill Matrix

lls can be X‟s or numeric (ex: level, # yrs.)

QA & Testing

Project Control
4 primary activities:
1. Planning performance:A (SDP), schedule, and a control process
2. Measuring status of work performed:Actual
3. Comparing to baseline:Variances
4. Taking corrective action as needed:Response
Validation vs. Verification
Validation:Are we building the right product(Acceptance and external testing)
Verification:Are we building the product right(Unit, integration, system,
regression, compatibility, load&stress testing)
Software Quality

• Ability to track relationship between work products

• Ex: how well do requirements/design/test cases match

• Conducted at the end of each lifecycle phase

• Potential deliverables:
– Software Requirement Review (SRR)
– Critical Design Review (CDR)

Project Testing flow “Phases”

 Unit Testing

-box testing
• Sometimes treated black-box

• Developers
• Unit tests are written in code
– Same language as the module
– a.k.a. “Test drivers”

• Ongoing during development

• As individual modules are completed

• “Test Suites” can test a functionality

• Part of the XP methodology

• “Test-first programming”
  Integration Testing

together
ule but manifest in another
-box tests

 System Testing

-box testing

 User Acceptance Testing

-off
tests
requirements

• Conditions the software must meet for customer to accept the system
• Ideally defined before contract is signed
• Use quantifiable, measurable conditions

 Black-box

-box”
• Not concerned with how it works but what it does
• Focus on inputs & outputs

 White-box

Coverage
• Statements executed
• Paths followed through the code
 approaches: 2 types ???????

 Top down: start from structure

• Core or overarching system(s) implemented 1st
• Combined into minimal “shell” system
• “Stubs” are used to fill-out incomplete sections
– Eventually replaced by actual modules

 Bottom up: start from components

• Starts with individual modules and builds-up
• Individual units (after unit testing) are combined into sub-systems
• Sub-systems are combined into the whole

Integration Issues:
Pressure-Delivery date nears-Unexpected failures (bugs)-Motivation issues-User
acceptance conflicts
Deliverables in system testing:
Acceptance test procedure-Tested application-Integration plan-Detailed SQA test
plan-SQA test cases

Defect Metrics:

• Ranked by severity
– Critical, High, Medium, Low
– Show stoppers

 Open Bugs (outstanding defects) ????????

• Ranked by severity
 Open Rates
• How many new bugs over a period of time
 Close Rates
• How many closed over that same period
• Ex: 10 bugs/day
 Change Rate
• Number of times the same issue updated
 Fix Failed Counts
• Fixes that didn‟t really fix (still open)
• One measure of “vibration” in project
Final Steps:

-Out

Migration and Rollout

Moving users from existing system to your new one
Migration Plan:
• Description of environment,existing data needed,operational constraints
• List of affected organizations and contacts
• Plan of steps to be taken
• service interruption?
• Training?
• Is there a helpdesk?
-way communication:

• What is happening, when, and why

• “Why” should remind them of the benefits
• Not too much detail or too little
• Where do customers go for more information?

-out about customer‟s key dates

• When does the system absolutely need to be stable?
• Know about their important deadline dates
• They must buy-into the approach!

1. Flash Cut
A. Immediate Replacement
- Fastest approach
- Still want a back-out plan
B. Parallel Operation
- Mitigates risk
- Parallel to either existing manual or system process
- Cut occurs once new system “burned-in”
2. Staged
– One part at a time replacement
Back-out Plan:

• Customers already have expectations and needs as defined by their existing

system
• Must be able to restore customer‟s service ASAP

while (more than a day!)

• Management: sooner
• Technicians: one-more-fix
• Set a time limit (ex: 3 hours of start)

Most systems need this step

Most PMs forget this
Impacts both completely new and replacement systems
The “data” often more valuable than the “system”

-Out:
• Release Check-List
• Avoid activities falling through the cracks
• Activities by Group:
• Possibly sign-off signatures
-out: Must have a plan for the process
• Often on a given day (ex: a Sat.)

• More than just end-users

– Users, systems ops, maintenance developers, sales

§
• Must be ready by ship-date
• Many types: End-user, sales & marketing, operations, design

Project Recovery ???????

1. Cut the size of the software

2. Increase process productivity
3. Slip the schedule, proceed with damage control

• Morale; focus; re-assign

• Fix classic mistakes; mini-milestones

• Stabilize; trim features; take out the garbage

Post Project Reviews:

• Prepare survey form

• Email team with survey and schedule meeting
– Gather data
• Conduct meeting
• Prepare PPR report

CMM:
: (A software process framework)

1) Initial
• „Ad hoc‟ process, chaotic even
• Few defined processes
• Heroics often required here
2) Repeatable
• Basic PM processes
– For cost, schedule, functionality
• Earlier successes can be repeated
3) Defined
• Software & Mgmt. process documented
• All projects use a version of org. standard
4) Managed
• Detailed metrics of process & quality
• Quantitative control
5) Optimizing
• Continuous process improvement
• Using quantitative feedback