Software Project Management

Project Monitoring, Reporting and Control

 Agenda
• Purpose
• When do we Monitor, Report & Control?
• Who is Responsible for Monitoring?
• What should we Monitor?
• What should we Report On?
• Status Reporting
• Project Controls
• Agile Differences
 Purpose of Project Monitoring,
Reporting and Control
• Monitoring
• Measuring project & product progress against plan.
• Reporting
• Informing stakeholders on project status, progress, changes,
issues and risks.
• Control
• Appropriate corrective actions can be taken:
• When the project’s performance deviates significantly from the plan.
• Based on the current state of issues and risks.
 When Do We Monitor, Report & Control?

• Set expectations immediately with stakeholders.

• Understand what they want & expect.
• Set up & begin monitoring and reporting early.
• Implement corrective actions when/as necessary.
• Log all reports and supporting data.
 Who is Responsible for Monitoring?
• The Project Manager is responsible for monitoring project performance
on a regular basis.
• Daily, Weekly, Monthly depending on the size and complexity of the project.
• Analyze the impact to the project.
• Determine corrective actions and assign resources.
• Track and report progress.
 What Should We Monitor?
• Are we doing the right thing?
• Alignment with business strategy and value
• Are we doing things right?
• Schedule
• Budget
• Resources
• Quality
• Changes
• Risks
• Issues
• Team Morale
• Etc.
 How Often Should We Monitor?
• Monitoring rates
• Daily, weekly, monthly
• If problems occur – then adjust
• You may have to monitor problem areas more closely for some period
of time.
• It’s OK if there’s one or more areas under closer scrutiny at any given
time.
• Status Reporting
• Part of the communications plan
• Daily, weekly, monthly – Negotiate with your stakeholders
 What Should We Report On?
• No Set Rules
• Find out what your stakeholders want
• Recommended
• Summary
• Schedule
• Budget
• Resources
• Defects
• Enhancements
• Risks
• Size
• Issues
• Morale
• Until Issues and/or Morale become a problem
 Project Summary

• Useful as a reminder of project background & purpose

Project Summary (2)
Schedule - Project
Schedule - Release 1
Schedule - Release 2
Schedule - Release 3
Schedule – Release 4
Schedule - Bulls Eye Chart
 Schedule - Milestones
• Completed High Level Design milestone.
• Met cost target at 2nd month of project.
• Assembled low level design team with sufficient
resources, meet hiring target.
Budget
Resources
Change Requests - Defects
Change Requests – Enhancements
Size
Reporting Key Risks
Risk – Summary Status
 Issues
• Definition:
• Things that are in dispute between two or more parties that
will impact the project.
• If not resolved by a certain date, most issues will escalate or
have consequences.
• Example:
• High (40% annually) project turnover rate. If not resolved
within 30 days the delivery date will slip by 2 months.
• Development network is not stable. This will result in an
average delay of 5 days/month for all deliverables.
 Project Morale
• Is your project team a high performance team?
• Work well together & support each other
• Communicate
• Cooperate
• Or is your team dysfunctional?
• Burnout
• High turnover
• Don’t work well together or support each other
 Reporting Issues
• Content (we’ve discussed)
• Format
• Is it easy for the consumer to use?
• Can they manipulate the data to meet their needs?
• Timeliness
• Accessibility
• Is everyone (with a need to know) using the same data?
• Quality
 Project Control
• Project control:
• Is guiding the team to meet an objective.
• Is not abusing power and authority, or using domination.
• What’s needed to control your project:
• A plan, schedule, budget and a control process.
• Measuring status of work performed.
• Comparing to baseline to generate variances.
• Taking corrective action as needed.
• Prerequisite to good control is a good plan.
 What if You’re Behind Schedule?
• Often there is conflict between:
• “Commitment” (also known as the “Target”) – what was originally
scheduled.
• “Current Plan”–What the team currently thinks is realistic.
• Strategies if your customer and/or management won’t change
the commitment date:
• Set expectations at the start of the project about whether the goal is to:
• Finish as fast as possible.
• Finish as estimated.
• Continue to track and report progress against both.
• Describe both in terms of probabilities.
 Agile Differences
• Planning next iteration(s) versus planning project.
• Earned Value versus Burn Down Charts:
• Essential difference
• Agile projects: credit is given when code is integrated and tested.
• Traditional projects: credit is given when task is complete.
• If based on story points, features or some other size
estimate, Burn Down Charts can show the 100%
(project complete) mark raising and lowering.
Burn Up Chart with Raised Ceiling
 Summary
• “The only thing worse than being late is not knowing that you’ll
be late” – Anonymous.
• You won’t be able to monitor, report or control your project
without:
• A plan
• Accurate & timely measurement of progress against the plan
• Agreement with your stakeholders regarding what is to be reported
• Plan & implement your measurement and reporting
mechanisms at the beginning of the project.
• Analyze the data you receive, and communicate your analysis
with your stakeholders.
Software Project Management
Project Monitoring, Reporting and Control