Docstoc

The Project Managers Perspective

Document Sample
The Project Managers Perspective Powered By Docstoc
					Traditional Software Project Management
Value-Up Project Management Practices
Monitoring Project Health
Recognizing the Warning Signs
Common Project Management Issues
What’s Wrong with the “Iron Triangle”
Exercise: Group Discussion: Project
Management Practices
          Issue                                    Consequences
                           Poor visibility
Insufficient and invalid
                           Poor planning
information
                           Poor milestone tracking
Disparate sources of
                           Difficult to capture project-related metrics
information
                           Inadequate requirements
Managing Customer
                           Poor milestone tracking
Expectations
                           Poor level of quality
                           Poor change control
Poor Communication
                           Inefficient team collaboration
                           Iterative delivery of incremental value is usually foreign to the
                           business
Funding
                           The business wants to understand the costs upfront
                           Incremental funding requires business change
This paradigm doesn’t
work well. It assumes:
  The process is running
   smoothly to start with
  Resource productivity
   is evenly distributed
  There is little variance
   in the effectiveness of
   task completion
  There is no spare
   capacity throughout
   the system
Who are the project manager’s customers? Who
are the other stakeholders?
Do we need project managers? Why?
What are the key questions you want your project
managers to be able to answer?
What metrics do you use for assessing whether or
not your projects are on track?
How do you get early warning of problems?
How and when do you capture these metrics?
Value-up Project Management Concepts
What is Variation?
Exercise: The Problem With Prescriptive
Metrics
The Fallacy of Prescriptive Metrics
Preventing the Distortion
Identifying variation to distinguish in control and
out of control projects
Avoiding prescriptive metrics for monitoring
   Number of dev tasks completed on time
   Number of bugs found
   Number of billable hours
Using team, rather than individual measurement
Using a multidimensional view of metrics to
monitor project health
The concept of natural, common cause variation is
central to value-up approaches
Monitoring variation is traditionally difficult to do
  VSTS instrumentation and reporting makes it easier
   Common-cause Variation      Special-cause Variation
    Occurs as a part of the    Occurs due to
    process                    something outside of
    The presence of            the process
    variation is predictable
    from day-to-day

Processes with special-cause variation are out of control
Consider the problems of using the following
prescriptive metrics
   Measuring programmer productivity based on lines of
   code written per day
   Rewarding programmers based on number of bugs
   fixed
   Rewarding the team for creating tests and code to
   achieve 90% code coverage
   Measuring testers based on number of bugs found
Performance Level

                                                                                             Measurement Indicators




                                                                                              True Performance




                                                                                                              Time
        Source: Robert D Austin, Measuring and Managing Performance in Organizations, 1996
Metrics are only approximations of business
objectives
Measurements are made one dimension at a time
   If you only measure one dimension at a time and
   prescribe expected results, behavioral distortion is a
   natural consequence
   Gathering data from multiple sources at the same time
   and correlating this data is normally very difficult
Metrics create disincentives
   Keep measurement at the team level
Expect common-cause variation
   Reward the team based on deliverable units of
   functionality
Answering Common Project Management
Questions
How Much Work is Left?
How Productive is the Team?
How Much Unplanned Work is There?
What’s the Quality of the s/w We Are
Producing?
How Effectively are we Finding, Fixing and
Closing Bugs?
How much work is left and when will it be done?
How productive is the team?
How much unplanned work do we have?
What’s the quality of the software we’re
producing?
How effectively are we finding, fixing and closing
bugs?
How many false task and bug resolutions do we
have?
Are we finding and triaging the right bugs?
Planned
 Work




          Completed
            Work
   Tests
Inconclusive

   Tests
   Failed

   Tests
  Passed
                        Code
                        Churn

               Active
               Bugs
Recognizing Signs of Underestimation
Recognizing Test Bottlenecks
Recognizing Sloppy Development Practices
Recognizing Scope Creep
      Slow progress leading to cuts in
     planned work, but not enough cuts




Steady rates of progress,
  but slope too shallow
    Bulge in resolved.
Insufficient resources or
 inadequate quality from
      development
Growing “Fault Feedback
 Ratio” – bugs requiring
   multiple handling
                    Falling code coverage




                    Fewer passing and more
                      inconclusive tests




Rising code churn
“Dark Matter” emerging
  during the iteration




   Planned work is
    squeezed out
Traditional software project management has
inherent problems
Benefits of value-up project management
practices
   Increased ROI, increased accountability, improved
   compliance and increased responsiveness to business
   needs
VSTS provides metrics to monitor project health
and answer common project management
questions
VSTS provides reports to help find the warning
signs of out of control projects

				
DOCUMENT INFO