Comments on: Knowing Your Project Management Average Is Powerful! http://pmtoolsthatwork.com/your-average-is-powerful/?utm_source=rss&utm_medium=rss&utm_campaign=your-average-is-powerful Getting to On-Time Software Projects Thu, 09 Sep 2010 20:43:50 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Project Management or Death by Detail? | Project Management Tools That Workhttp://pmtoolsthatwork.com/your-average-is-powerful/comment-page-1/#comment-517 Project Management or Death by Detail? | Project Management Tools That Work Thu, 29 Jul 2010 13:16:22 +0000 http://project-management-tools.thruhere.net/?p=82#comment-517 [...] For example, in our experience, the completion of developing chunks of software functionality are often pretty much unknown.  We could not predict with any certainty which features would be finished first or by when.  We could however, predict with a high degree of certainty when 95% of the features would be done (see avoid this trade off trap).  The same was true of fixing defects.  We could not predict very well when a particular defect would be fixed, but we could with a high degree of certainty predict when just about all (e.g. around 95%) of the defects would be fixed. (For more see knowing your project management average.) [...] [...] For example, in our experience, the completion of developing chunks of software functionality are often pretty much unknown.  We could not predict with any certainty which features would be finished first or by when.  We could however, predict with a high degree of certainty when 95% of the features would be done (see avoid this trade off trap).  The same was true of fixing defects.  We could not predict very well when a particular defect would be fixed, but we could with a high degree of certainty predict when just about all (e.g. around 95%) of the defects would be fixed. (For more see knowing your project management average.) [...]

]]> By: Bruce Bensonhttp://pmtoolsthatwork.com/your-average-is-powerful/comment-page-1/#comment-413 Bruce Benson Thu, 03 Jun 2010 15:56:27 +0000 http://project-management-tools.thruhere.net/?p=82#comment-413 Jim,Yes, a priority ordering is normal. The priority is often set by how "bad" the problem is, such as "death screens" being first, and "cosmetic" issues in the GUI being the lowest.While one would think that this would change how fast a defect is fixed, it is not quiet as obvious as it would seem. What we've found in large projects is: 1. If it is readily reproducible and it is a "death" defect, it gets fixed real fast. This one is pretty obvious. 2. If is is readily reproducible and it is a failure of major functionality, again it will be fixed very fast. 3. If it is hard to reproduce (such as an intermittent issue) and is a "death" defect, it will probably not get fixed as quickly as #1 or even #2. 4. If it is hard to reproduce (such as an intermittent issue) and is a failure of major functionality, it will probably not get fixed as quickly as #1/#2 5. If it is readily reproducible and is any other kind of failure, it will often be fixed faster than #3/#4 above ....You can see the pattern. It becomes more the ease of reproducibility that drives the overall speed and not the severity/badness of the issue. This again is pretty obvious - but to many people this is a source of frustration. What we found is programmers will generally fix things - lower priority issues - that can readily be fixed, at a faster rate than the harder issues that are difficult to isolate or reproduce. The response to this is usually to increase the priority or visibility of the hard issues (reviews, priority lists, meetings, etc.) to make sure everyone is working on the highest priority issues first, not those that are easiest to fix.This seems logical, but often does not work as well as expected. I've seen a lot of "forcing" techniques used, but in general the "hard" issues got fixed at their *own* average/normal rate regardless of how hard we pushed or how high we prioritized them (or how many people we assigned to them). Telling programmers that they could not fix anything else until they fixed the "hard" issues, for example, did not result in the hard issues getting fixed any faster and only resulted in significantly fewer easier issues getting fixed in the same period (this also suggests that Kanban techniques may not be as efficient as expected). This drives many folks absolutely crazy.To many it just does not seem logical or reasonable and there must be something wrong they think, when lower priority issues get fixed faster than higher priority issues. I've watched teams lose significant productivity (and morale) because someone was trying to "fix" this "problem."Thanks for the comment!Bruce Jim,

Yes, a priority ordering is normal. The priority is often set by how “bad” the problem is, such as “death screens” being first, and “cosmetic” issues in the GUI being the lowest.

While one would think that this would change how fast a defect is fixed, it is not quiet as obvious as it would seem. What we’ve found in large projects is:
1. If it is readily reproducible and it is a “death” defect, it gets fixed real fast. This one is pretty obvious.
2. If is is readily reproducible and it is a failure of major functionality, again it will be fixed very fast.
3. If it is hard to reproduce (such as an intermittent issue) and is a “death” defect, it will probably not get fixed as quickly as #1 or even #2.
4. If it is hard to reproduce (such as an intermittent issue) and is a failure of major functionality, it will probably not get fixed as quickly as #1/#2
5. If it is readily reproducible and is any other kind of failure, it will often be fixed faster than #3/#4 above ….

You can see the pattern. It becomes more the ease of reproducibility that drives the overall speed and not the severity/badness of the issue. This again is pretty obvious – but to many people this is a source of frustration. What we found is programmers will generally fix things – lower priority issues – that can readily be fixed, at a faster rate than the harder issues that are difficult to isolate or reproduce. The response to this is usually to increase the priority or visibility of the hard issues (reviews, priority lists, meetings, etc.) to make sure everyone is working on the highest priority issues first, not those that are easiest to fix.

This seems logical, but often does not work as well as expected. I’ve seen a lot of “forcing” techniques used, but in general the “hard” issues got fixed at their *own* average/normal rate regardless of how hard we pushed or how high we prioritized them (or how many people we assigned to them). Telling programmers that they could not fix anything else until they fixed the “hard” issues, for example, did not result in the hard issues getting fixed any faster and only resulted in significantly fewer easier issues getting fixed in the same period (this also suggests that Kanban techniques may not be as efficient as expected). This drives many folks absolutely crazy.

To many it just does not seem logical or reasonable and there must be something wrong they think, when lower priority issues get fixed faster than higher priority issues. I’ve watched teams lose significant productivity (and morale) because someone was trying to “fix” this “problem.”

Thanks for the comment!

Bruce

]]> By: Jim Foxhttp://pmtoolsthatwork.com/your-average-is-powerful/comment-page-1/#comment-412 Jim Fox Thu, 03 Jun 2010 09:07:44 +0000 http://project-management-tools.thruhere.net/?p=82#comment-412 What I find interesting here (by the way this is a very interesting discussion) is that I haven't seen one person weighting some of these errors into PRIORITY categories. When faced with these kinds of problems in real world situations you are working through these in a priority order because of resource constraint. After all, if all of the errors were in the area of "look and feel" and not in wrong calculations or "death screens" appearing at a point in time, the pressure and use of resources would change would it not? And, would that not adversely effect the time from discovery to fix of 'simple' problems? And, it would follow that the numbers for each type would skew? What I find interesting here (by the way this is a very interesting discussion) is that I haven’t seen one person weighting some of these errors into PRIORITY categories. When faced with these kinds of problems in real world situations you are working through these in a priority order because of resource constraint. After all, if all of the errors were in the area of “look and feel” and not in wrong calculations or “death screens” appearing at a point in time, the pressure and use of resources would change would it not? And, would that not adversely effect the time from discovery to fix of ‘simple’ problems? And, it would follow that the numbers for each type would skew?

]]> By: Bruce Bensonhttp://pmtoolsthatwork.com/your-average-is-powerful/comment-page-1/#comment-411 Bruce Benson Thu, 03 Jun 2010 00:39:57 +0000 http://project-management-tools.thruhere.net/?p=82#comment-411 Another approach to estimating:http://www.galorath.com/wp/the-estimate-maturity-model-can-improve-project-success.phpI like the notion of a maturity model for estimating. I'm not quite convinced this is it, but it is a good reminder that we just don't get good at something, we incrementally improve and get better with time. Another approach to estimating:

http://www.galorath.com/wp/the-estimate-maturity-model-can-improve-project-success.php

I like the notion of a maturity model for estimating. I’m not quite convinced this is it, but it is a good reminder that we just don’t get good at something, we incrementally improve and get better with time.

]]> By: In Project Management 9+3 Is Not 12 | Project Management Tools That Workhttp://pmtoolsthatwork.com/your-average-is-powerful/comment-page-1/#comment-392 In Project Management 9+3 Is Not 12 | Project Management Tools That Work Tue, 25 May 2010 13:02:28 +0000 http://project-management-tools.thruhere.net/?p=82#comment-392 [...] What is useful about this observation is that it explains why Agile methods such as Scrum (or possibly Agile PM) can work well.  Scrum for example uses a simple velocity, computed from previous completed sprints, to determine what the average capacity in a given sprint will be (think of a sprint as a sub-project; the velocity the number of requirements that can be accomplished in a fix time such as 2 weeks).  It just captures history without trying to explain it, justify it or adjust it. I love it.  The use and computation of velocity is a brilliant way to capture and use the experience I mention above.  I know from use of what I call “past performance” that this works very well in software and non-software projects, even as folks often can’t believe something that simple could really be useful (for more on simple averages see your average is powerful). [...] [...] What is useful about this observation is that it explains why Agile methods such as Scrum (or possibly Agile PM) can work well.  Scrum for example uses a simple velocity, computed from previous completed sprints, to determine what the average capacity in a given sprint will be (think of a sprint as a sub-project; the velocity the number of requirements that can be accomplished in a fix time such as 2 weeks).  It just captures history without trying to explain it, justify it or adjust it. I love it.  The use and computation of velocity is a brilliant way to capture and use the experience I mention above.  I know from use of what I call “past performance” that this works very well in software and non-software projects, even as folks often can’t believe something that simple could really be useful (for more on simple averages see your average is powerful). [...]

]]>