info 638lecture #101 software project management review info 638 glenn booker

INFO 638 Lecture #10 1

Software Project Management

Review

INFO 638Glenn Booker


Project Limits

Projects are limited in scope, as defined by one of these: A functional specification A Software Requirements Specification Use cases and their documentation A Statement of Work (SOW) A Mission Needs Statement (MNS)

(government term)


The Triangle

Projects generally get stuck facing a triangle Cost Time (schedule) Features and/or quality

At most, two of these points can be controlled Which one can you tolerate flexibility?


TPM Life Cycle

Wysocki has five major phases in the TPM life cycle Scope the project Develop the project plan Launch the plan Monitor/control project progress Close out the project


Risk Management Guide

Need to create a list of possible risks Describe each risk briefly Estimate the probability of the risk

happening Should be between 0 and 100%

Estimate the loss if the risk occurs How much effort will it take to recover

from the risk?


Risk Management Guide

Multiply probability times loss to get the impact of each risk Impact = probability * loss

Sort risks in descending order of impact; keep the top 10 (typically) This is prioritizing the risks

For each significant risk, assign a risk owner to look for the risk occurring


Procurement Management Procurement has its own life cycle,

which runs parallel to part or all of the project life cycle Solicit RFI (optional; and not in text) Solicit RFPs Get responses Select Vendors Manage contracts Close out contracts


Role of the POS

The POS is a communications tool among the project manager, their development team, the customer, and the project manager’s boss (upper or senior management)

The POS is a concise statement of the project, and a summary of its justification to continue


Parts of a POS

The POS has five major sections Problem/opportunity Goal Objectives Success criteria Assumptions, risks, obstacles

Each is typically a few paragraphs long


Work Breakdown Structure (WBS)

The WBS gives structure to the set of activities in a project

It expands on the POS by describing activities in more and more detail, until you get down to the smallest level of task you need to define for your project The WBS is a really big ‘to-do’ list


WBS Approaches

There are three major approaches to structuring a WBS Noun-type approaches (subsystems) Verb-type approaches (life cycle phases) Organizational approaches (who or

where performs work)


WBS Numbering

Tasks and activities are often given unique identification numbers to help do cost accounting and generate status summaries In Microsoft Project, you can add a

column called WBS which will automatically follow this numbering


After the WBS

Once the rough scope of tasks has been defined in the WBS, we need to estimate each task in terms of duration and effort From effort we’ll get the cost of each

task, and eventually the project After estimation, can start to organize

the project schedule


Creating a Good Estimate There are six techniques for

estimating the duration and effort of a task Similar activities Historical data Expert advice Delphi technique Three-point technique Wide-band Delphi technique


Estimating Resources

While ‘resources’ often refers to people on a project, it may refer to People Facilities Equipment Money Materials


Organization Chart

Since we need to define the types of staff needed to perform each task, this feeds into developing the organization chart of the project The roles needed for performing tasks

should all appear on the org chart It’s called a Resource Breakdown

Structure in the text (p. 108)


Project Network Diagram

Can present the project schedule in three major forms Gantt chart, showing bars for each task

under a timeline Pert chart, with activity on arrow (AOA)

notation CPM chart, with activity on node (AON)

notation The latter two can show critical path


Critical Path

A key output is the critical path, which can be defined as The longest duration path in the network

diagram, or The series of tasks whose early and late

schedules are the same dates, or The set of activities with zero slack


Management Reserve

At the project level, try to keep a little reserve of time (padding) to allow for likely schedule slips Don’t do this on individual tasks – tends

to bloat the schedule 5-10% is a good schedule reserve So a 6-month project might try to finish

6-13 work days early 6 months = 26 weeks = 130 work days


Leveling Resources Then need to add up the planned

resources and look for potential problems Over committing people Resources inconsistent with project

priorities Lack of management to monitor the

project resources Lack of accounting for employee

turnover


Work Packages

Earlier we defined a project as having activities, which are broken into tasks

A way to describe and manage the tasks within an activity are work packages

The work package describes the tasks to be accomplished, relevant dates, and who will do the work


Critical chain vs. critical path

The critical path is the longest duration through the project Doesn’t consider the resources needed

for tasks along the critical path Critical chain is the longest path

through the project, considering both task dependencies and resource constraints


Joint Project Planning

Joint Project Planning (JPP) uses a goldfish-bowl approach to conducting early analysis of a project

Its scope is typically to define the POS and/or PDS For software, this might include

defining the system scope and key requirements, and/or developing high level system design


JPP

All significant stakeholders in a project need to attend JPP

JPP sessions are typically held off-site to avoid distractions

JPP follows a specific agenda to reach specific goals for the session, e.g. develop a POS, describe the WBS, etc.


Monitoring Progress

By now you have been able to create a detailed project plan, including task definitions, estimates of duration, & assignment and leveling of resources

Then the project actually starts Now you need to monitor what really

happens, and control the future of the project


Control and Risk

Controlling a project is closely linked to risk management

You want to minimize the risk that the project won’t finish successfully Successfully generally means “

on time and within budget” To do so, you need measurements to

help decide if the project is on track


Controls

Without good controls, a project will wander like a 6-year-old on summer vacation

Controls allow us to Track progress – what has been

accomplished? Detect variance – have we departed from

the plan? Take corrective action – fix it!


Progress Reporting System

Some form of progress reporting system needs to be established Want timely, complete, clear, and

accurate status reported Avoid adding too much to overhead to

create the status reports Results are readily available Warns of problems with time to fix them


Variances

Variances are the difference between actual events and the project plan

Positive variances are often good They mean you are ahead of schedule or

under budget But could mean the schedule has

slipped, and little has been accomplished


Displaying Status

There are three major ways to display the status of a project graphically Gantt chart Milestone trend chart Cost schedule control chart


Cost Schedule Control

Cost schedule control refers to the system used by the many agencies called earned value or C/SCSC

We have already defined a project plan with tasks and resources

Each task therefore has some defined dollar value (its resources times their hourly rate)


Cost Schedule Control To use Cost Schedule Control, we

need to define when we get ‘credit’ for accomplishing each task Only when the task is done Half at the task start, and half at finish Etc.

The total planned value of work done on the project typically forms a long S curve over time


Change Control A change control process is needed to

manage changes to the scope of a project Describes the activities needed to

analyze a problem, estimate how much work it is to resolve, determine its priority, fix it, and incorporate it into a system change with other problem fixes

The names of the organizations which perform each of the steps may vary


Escalation

Escalation here means how a problem can be resolved Little problems might be resolved by the

project manager Bigger problems might be resolved by

getting additional resources from your organization

Huge problems might need cooperation from your customer to resolve


Motivation

Key for a good manager to recognize is that different things motivate different people And what motivates one person might

change over time One person might be thrilled to get an

award for their contribution to a project, another might prefer a check, and a third might want an extra two days vacation


Motivation

The big motivational factors for most people are: Opportunity for achievement Opportunity for advancement

Might include technical supervision Recognition Increased responsibility The work itself


Management and Motivation

Many of the motivational factors can’t be controlled by a first line manager

Key for managers to focus on are Provide challenging work Recognize your people’s work Design their job to provide a variety of

skills needed, clearly identifiable and significant tasks, allow autonomy, and provide feedback


Contract Issues Many management issues involve

contractual concerns A good resource with more detail is

On Time Within Budget, E.M. Bennatan, 3rd ed., ISBN 0-471-37644-2, Wiley, 2000.

The key contractual vehicles are RFI, RFP, and RFQ For zillions of examples, go to

www.firstgov.gov and search on those acronyms


Contract Terms

The terms of payment are clearly defined in any contract Often payments are based on meeting

specific milestones in the project Rules for handling contract early

termination, and normal closeout of the contract are also defined


Team Rules Any team needs some rules to

function effectively How will decisions be made? How do you solve problems? How do you resolve conflicts? How & when does the team meet? How does the team interact

with other projects? The customer? Who defines the answers to these?


Closeout

Normal closeout of a project typically involves six steps Get client acceptance Ensure system installed Ensure documentation delivered Get client signoff Post-implementation Audit Party!


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


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


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 Don’t speculate


Version Scope

This phase sets the stage for the project Prepare the POS, much like done

in TPM Define the vision of what the product will

be Define the overall budget and schedule

(timebox) of the project Define the WBS to the 2nd or 3rd level


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


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


Cycle Planning

Cycle planning is performed like in traditional project management (TPM), but there are key differences In APF, the planning is done in detail only

for the next cycle – not the entire project at once

APF planning may or may not use project software; it could be done with more informal tools


Cycle Build

It is assumed that Cycle Plan is done by one person or part of the team

Cycle Build requires the whole team’s presence to refine the schedule if needed

Identify specific resources for each task, and ensure conflicts are resolved and workload is balanced


Build Cycle Functionality

Start building the functionality promised for this cycle, following the plan just developed

During the cycle, daily stand-up meetings are used for status Stand up so it doesn’t drag on forever

Monitor the system scope & their priorities, and issues identified


Build Cycle

Use a Scope Bank to keep track of requirements, and an Issues Log to record and track significant problems


Client Checkpoint

The Client Checkpoint focuses on two major activities Review of the quality of work done

in the existing cycle Need planned and actual functionality

added to the system in this cycle Adjust schedule for the next cycle

accordingly Need the Scope Bank


Go back to Cycle Plan phase

After the client checkpoint, loop back to the cycle plan phase, until this version of the product has been completed Notice that we didn’t do detailed

planning during the client checkpoint for this reason – it’s followed by the planning phase

Stop loop when done with Version


Post-Version Review

There are three activities in the Post-Version Review Determine if the project has met

its business objectives Review lessons learned Look for APF process improvements


APF Variations

APF can be used for quick proof-of-concept projects

Sometimes an APF project will reveal major scope problems; have to adjust severely, or kill the project


Extreme Project Management

Extreme Project Management (xPM) is similar to APF, but is better suited to projects with poorly defined goals You don’t know what the objective is

It isn’t the same as Extreme Programming (XP), which is part of the Agile family of development methods


Extreme Projects

Extreme projects are generally fast, innovative, and ill defined High speed – must be developed quickly High change – must respond to fast

changes in the project requirements High uncertainty – must be able to

handle rapid and unexpected changes in project direction and focus


xPM vs. APF

xPM and APF have a lot in common The main differences are

xPM has unknown project goals xPM has more variability in project

scope, budget, and time xPM has more variability in cycle

duration and number of cycles

info 638lecture #101 software project management review info 638 glenn booker

Documents

project planlaunch

project managers

project limitsprojects

project schedulelecture

risk brieflyestimate

significant risk

risk owner

risk occurringlecture