Transcript Software Project Management Intro to Adaptive Project Framework INFO 638 Glenn Booker INFO 638 Lecture #7 Adaptive Project Framework  Adaptive Project Framework (APF) uses selected portions of traditional project.

Software Project
Management
Intro to Adaptive Project
Framework
INFO 638
Glenn Booker
INFO 638
Lecture #7
1
Adaptive Project Framework
 Adaptive Project Framework (APF)
uses selected portions of traditional
project management (TPM)
 Focus is on planning just-in-time, rather
than planning the entire project from the
start
 APF is client-focused, and expects
constant change
INFO 638
Lecture #7
2
APF Structure
 APF uses five phases





Version Scope
Cycle Plan
Cycle Build
Client Checkpoint
Post-Version Review
 Planning is based on functionality,
and is kept high level until each cycle
INFO 638
Lecture #7
3
APF Structure
 APF is iterative, both within a cycle,
and between cycles
 {Cycle Plan – Cycle Build – Client
Checkpoint} is iterative
 Within Cycle Build is also iterative; there
may be many builds within that phase,
each time it occurs
 Now examine each phase briefly
INFO 638
Lecture #7
4
Version Scope
 Version Scope is much like high level
planning for a TPM project
 Need to identify project scope, conditions
of satisfaction (COS), assess project
risks, etc.
 A Project Overview Statement (POS) is
written
 Describe problems & opportunities, goals,
objectives, risks, assumptions, obstacles,
etc.
INFO 638
Lecture #7
5
Version Scope
 This phase also produces a prioritized list
of functionality
 This is key to setting up the cycles
 The third output from this is a high level
WBS (2 or 3 levels of breakdown)
 Main goal is to plan the order in which
functionality will be implemented
 Finally, prioritize the cost, schedule,
quality and scope – what’s critical?
 Will be used to manage the cycles
INFO 638
Lecture #7
6
Cycle Plan
 Cycles are 2-6 weeks duration
 This phase plans this cycle in detail
 Fill out the WBS down to tasks, identify
task dependencies, and allocate resources
 Duration is agreed to by the customer
 Typically people work in small teams
in parallel, working on various kinds
of functionality
 Critical path and chain aren’t used
INFO 638
Lecture #7
7
Cycle Build
 The duration of this cycle is limited
to the planned duration
 The cycle plan is followed; as much
functionality is developed and
implemented (as fits into the
time allowed)
 Monitor task status daily
 Corrective action is taken as needed
 Record change requests in a Scope Bank
 Record problems in an Issues Log
INFO 638
Lecture #7
8
Client Checkpoint
 This is a joint customer/team quality
review of functionality finished in this
cycle
 Compare to expected business value
 Adjust business plan, and amend the
next cycle’s scope as needed
 Might adjust functionality priorities,
add new functions, etc.
INFO 638
Lecture #7
9
Post-Version Review
 This checks the whole project against
the success criteria established in the
scope phase
 Might need to kill the project, if severely
below expectations
 Document lessons learned for future
versions of this product, or new projects
 Plan future versions of this product, if
applicable
INFO 638
Lecture #7
10
APF Core Values
 APF is based on six core values,
which help define how APF thinks






INFO 638
Client-focused
Client-driven
Incremental results
Continuous questioning
Change is progress
Don’t speculate
Lecture #7
11
APF Core Values
 Client-focused
 View the system from the client’s
perspective
 Needs and best interests of the client
come first
 Client-driven
 Keep the client involved in the project as
much as practical, in order to share in
the project’s success
INFO 638
Lecture #7
12
APF Core Values
 Incremental results
 Like use of prototyping, deliver a
working application as soon as
possible…in the first cycle if possible
 Then expand on its functionality with
subsequent cycles
 Continuous questioning
 Encourage creativity, and keep looking
for product and process improvements
 Failure to share an idea is anathema
INFO 638
Lecture #7
13
APF Core Values
 Change is progress
 …to a better solution
 Iterative development will lead to a
product that is changing, but always
improving
 Don’t speculate
 …too much on the future
 Avoid excess planning, and other tasks
which don’t add value to the project
INFO 638
Lecture #7
14
Version Scope phase
INFO 638
Lecture #7
15
Version Scope
 This phase sets the stage for the
project
 It can be done by the requestor
(customer) and provider (project
manager)
 Preferably done in person
 Make sure agree on terminology
 Prepare the POS, much like done
in TPM
INFO 638
Lecture #7
16
Version Scope
 It is particularly important to define
the vision of what the product will be
 Need a consistent point of reference for
changing scope during the cycles, and
during evolution of the product
 The overall budget and schedule
(timebox) of the project need to be
clearly defined
 Version timebox should be <6 months
INFO 638
Lecture #7
17
Version Scope
 The WBS needs to be defined to
“mid-level” – 2 or 3 levels of
structure
 Down to the scope of functionality
planned and implemented within
each cycle
 Focus on higher risk elements first
 Gives more time for corrections if
problems emerge
INFO 638
Lecture #7
18
Version Scope
 Likewise, higher complexity functions
should be developed early, as should the
highest business value functions
 If customer is impatient, plan short
duration features first
 Naturally, dependencies among
features may influence the above
guidelines
INFO 638
Lecture #7
19
Prioritization
 Can use various methods to
determine the priorities of features
 Forced Ranking approach:
 List the features, and have several
stakeholders rank them on a 1-10 scale
(high to low priority)
 Add rankings for each feature
 Features with lowest total score are
highest priority
INFO 638
Lecture #7
20
Prioritization
 A simpler approach is to group
features into high, medium, and low
priority buckets
 A.k.a. Must have, should have, and niceto-have
 Nice for small projects
INFO 638
Lecture #7
21
Prioritization
 Or use the Q-sort method
 Divide list into high and low priority
 Then within each list, divide again into
high and low priority
 Keep repeating until enough buckets
have been defined to make each one
manageable within one cycle
INFO 638
Lecture #7
22
Balancing Project Scope
 Recall the scope triangle
 Cost, schedule, and resources are the
variables you control to result in product
features (scope) and quality (p. 292)
 The scope and quality determine how
big the triangle is; you need to
balance the other three factors to
produce it
INFO 638
Lecture #7
23
Balancing Project Scope
 So if any of the constraints on the
project change (e.g. cost, time, or
resources available), that will affect
the other two
 If none of the possible solutions fit,
might have to change the scope
and/or quality requirements to
change the size of the triangle
INFO 638
Lecture #7
24
Number of Cycles
 Once we have a handle on the project
objectives and scope, need to
establish the preliminary number of
time boxes, and how long they are
 Try fixed duration for all time boxes; may
tweak later
 Might use development time of the most
complex cycle to set the time box size
 Consider client attention span too
INFO 638
Lecture #7
25
Assign Functions to Cycles
 Map the functions to cycles, based
on implementing the highest priority
stuff first
 Focus on the first few cycles
 Balance resource needs for each cycle as
needed
 Make sure key stuff gets delivered early
on
INFO 638
Lecture #7
26
Cycle Objectives
 Finally, prepare objective statements
for the first few cycles
 Tell customer what they should
expect from each cycle (deliverables)
 Keep focus on business functions and
value to the customer
INFO 638
Lecture #7
27
Wrap it Up
 This concludes the Version Scope
phase
 The scope of each cycle will be
subject to change, depending on what
actually happens
 But you want to tell the customer
what the scope of the project is, and
what the first few cycles will bring
(hopefully)
INFO 638
Lecture #7
28