Software Project Management

1
Software Project Management

• Intro to Adaptive Project Framework
• INFO 638
• Glenn Booker

2
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

3
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

4
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

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

6
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 whats critical?
• Will be used to manage the cycles

7
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 arent used

8
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

9
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 cycles
  scope as needed
• Might adjust functionality priorities, add new
  functions, etc.

10
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

11
APF Core Values

• APF is based on six core values, which help
  define how APF thinks
• Client-focused
• Client-driven
• Incremental results
• Continuous questioning
• Change is progress
• Dont speculate

12
APF Core Values

• Client-focused
• View the system from the clients 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 projects
  success

13
APF Core Values

• Incremental results
• Like use of prototyping, deliver a working
  application as soon as possiblein 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

14
APF Core Values

• Change is progress
• to a better solution
• Iterative development will lead to a product that
  is changing, but always improving
• Dont speculate
• too much on the future
• Avoid excess planning, and other tasks which
  dont add value to the project

15
Version Scope phase
16
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

17
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 lt6 months

18
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

19
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

20
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

21
Prioritization

• A simpler approach is to group features into
  high, medium, and low priority buckets
• A.k.a. Must have, should have, and nice-to-have
• Nice for small projects

22
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

23
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

24
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

25
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

26
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

27
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

28
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)