6 ms·

The Math Behind Project Scheduling, Bug Tracking, and Triage [video]

77 points by rossjudson 8y ago

georgewsinger 8y ago
This is a great talk so far. Does anyone have any [text]book recommendations for "mathematically mature" Project Management (i.e., project management theory that doesn't shy away from using math to demonstrate its points, if needed)?
- maroonblazer 8y ago
  Goldratt's "Critical Chain" work is the closest I've seen to 'mathematically mature' project management. https://en.wikipedia.org/wiki/Critical_chain_project_management https://en.wikipedia.org/wiki/Critical_chain_project_managem...
- Jtsummers 8y ago
  Deming’s work is another good source along with Goldratt.
- efm 8y ago
  Critical Path Method + Program Evaluation and Review Technique (PERT). Figure out the shortest path to the goal (critical path) then figure out the most likely timeline, by applying a probability distribution to the weights of each connection. This highlights the truth that reducing variance is a huge factor in improving the quality of forecasts.
- mitchtbaum 8y ago
  Change Management studies cover this aspect, I believe https://en.wikipedia.org/wiki/Change_management_(engineering) https://en.wikipedia.org/wiki/Change_management_(engineering...
- triggercut 8y ago
  For probabilistic scheduling you could look at software like @Risk by Palisade. Effectively applying Monte Carlo simulation to schedules. You provide a distribution around the level of effort or duration required to complete a task/activity in your precedence network/graph. What you get after enough runs is a probability or likelihood of completion dates/cost (e.g. P50 or P90 estimates). This is extremely powerful in non-trivial scenarios where you have a properly resourced & cost loaded schedule with logical constraints.
- ivanmaeder 8y ago
  The question reminds me of this classic chart from "Rapid Development," https://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone01.jpg https://www.construx.com/uploadedImages/Construx/Construx_Co... It's a great reference for project management, but not very math heavy. More math-oriented I'd say: - "How to Measure Anything," although not specific to project management - "The Principles of Product Development Flow." Think of "product" in this context as anything you want made that is unique (not made made repetitively in a factory). E.g., software. There's some queueing theory in there. And although the math isn't always presented, you will get more out of it if you can figure out or understand the math behind the principles
jonchurch_ 8y ago
I did not expect this talk to hook me so quickly. Im still watching currently, and a thought that pops up for me as a freelancer, how can I employ some of these mental tricks (like for example estimating tasks by points while disregarding how much calendar time that is associated with) while also being the manager of myself? Im sure its simply be aware of the pitfalls of thinking in deadlines, to avoid “Student Syndrome”, to focus on the benefit and spirit behind this sort of goal setting. Im thinking it would help me if I took one day a week to put my “project manager” hat on and divy up tasks for the coming week into story points, and then kept the hat off the rest of the week to keep time based goals out of my way. Does anyone with some experience scheduling their own time using tips in the talk have any suggestions?
- erikb 8y ago
  It doesn't make sense for yourself. The idea is to have one person tracking another (group of) person(s) and thereby having some feedback and motivation. Maybe you can grow a team with other freelancers and track each other?
  - jonchurch_ 8y ago
    That makes good sense to me actually. By the time I finished the talk, I realized there were some great takeaways for me in terms of understanding product management, but that it would be foolish overtooling to try and solve for problems that I dont actually have on the scale the tools are designed for. Thanks for your input!
forapurpose 8y ago
The author, based on the technology and products he's chosen to work on, is either visionary and courageous, completely lacks foresight, or enjoys pain: Avery was the lead engineer for Google Fiber's home wifi devices, building, managing, and monitoring the whole fleet in customers' homes. ... Before that, he started startups including one that deployed Lotus Domino in 10 minutes, and one that did unspeakable things to Microsoft Access databases. Microsoft Access, Lotus Domino, and consumer Wifi (mass-deployed!)? Shoot me, please, three times. On the other hand, they are a great way to learn the challenges of project scheduling and management. (In fairness, Lotus I mostly know by reputation, but the other two are enough.)
- apenwarr 8y ago
  Of your proposed motivations, I’ve been accused of all three but it’s probably the third one :) — the author
  - w4tson 8y ago
    Good talk. I thought it was interesting what you said about student principle because I have a counterpoint to it. Which is that not carving out time day to day to tackle tech debt (via sand bagging) means the treacle gets thicker and harder to run through and the volume of bugs increases which leads to corners being cut to get features out at the old pace. So the argument to over-estimate or sand bag, and fold in better solutions with the boy scout principle seems to me the best way to make a brown field site green again. I’ve had one experience of this which totally worked. Time to implement features went from weeks to hours. I’m currently trying to apply the same method again with mixed results
    - apenwarr 8y ago
      The approach recommended in the talk is to use relative size estimates instead of absolute size estimates, which removes the possibility of over-estimating (or under-estimating) or sandbagging. During the conversion phase from relative sizes to absolute sizes (which should be based on historical measurements, not aspirations), you can choose to add a bit of extra time so that people can work carefully and fix things rather than feel rushed. That's often a very good idea.
erikb 8y ago
It sounds very attractive to developers, and I myself was a huge fan of this way of thinking for a long time. Sadly real life teams are never even close to this. And there are reasons for that, which we might like or not. But they have to be accepted. For instance most project leaders are not good developers nor good managers. And they don't really want to advertise that fact, because just like us they believe that anybody actually cares. So they get even worse by not tracking relevant metrics and instead focus (not by coincidence but by cunning) on metrics that are painful for developers, like current_open_bugs, or open_features_that_nobody_understands_and_that_where_discussed_with_nobody. They do that because it increases pressure on developers, hooks them with their desire to become better, and they provide automatic goals that can never be achieved. And these are the desired outcomes for the project leaders. Because if everybody is under time pressure, you don't need to worry that someone might steal your job, if everybody already feels bad about themselves they will not criticize you openly (and are motivated to work harder), and if there are always automatic goals you don't need to think about new goals all the time. What is interesting to me is that nobody puts these people actively at the top of the projects. It's more like they grow to these positions naturally. But now that they are there, you can't really apply the logic from the presentation to convince them. Insted you might even give them the impression that they don't apply enough pressure yet because you are criticising their job.

77 points by rossjudson 8y ago

This is a great talk so far. Does anyone have any [text]book recommendations for "mathematically mature" Project Management (i.e., project management theory that doesn't shy away from using math to demonstrate its points, if needed)?

maroonblazer 8y ago
Goldratt's "Critical Chain" work is the closest I've seen to 'mathematically mature' project management. https://en.wikipedia.org/wiki/Critical_chain_project_management https://en.wikipedia.org/wiki/Critical_chain_project_managem...
Jtsummers 8y ago
Deming’s work is another good source along with Goldratt.
efm 8y ago
Critical Path Method + Program Evaluation and Review Technique (PERT). Figure out the shortest path to the goal (critical path) then figure out the most likely timeline, by applying a probability distribution to the weights of each connection. This highlights the truth that reducing variance is a huge factor in improving the quality of forecasts.
mitchtbaum 8y ago
Change Management studies cover this aspect, I believe https://en.wikipedia.org/wiki/Change_management_(engineering) https://en.wikipedia.org/wiki/Change_management_(engineering...
triggercut 8y ago
For probabilistic scheduling you could look at software like @Risk by Palisade. Effectively applying Monte Carlo simulation to schedules. You provide a distribution around the level of effort or duration required to complete a task/activity in your precedence network/graph. What you get after enough runs is a probability or likelihood of completion dates/cost (e.g. P50 or P90 estimates). This is extremely powerful in non-trivial scenarios where you have a properly resourced & cost loaded schedule with logical constraints.
ivanmaeder 8y ago
The question reminds me of this classic chart from "Rapid Development," https://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone01.jpg https://www.construx.com/uploadedImages/Construx/Construx_Co... It's a great reference for project management, but not very math heavy. More math-oriented I'd say: - "How to Measure Anything," although not specific to project management - "The Principles of Product Development Flow." Think of "product" in this context as anything you want made that is unique (not made made repetitively in a factory). E.g., software. There's some queueing theory in there. And although the math isn't always presented, you will get more out of it if you can figure out or understand the math behind the principles

jonchurch_ 8y ago

I did not expect this talk to hook me so quickly. Im still watching currently, and a thought that pops up for me as a freelancer, how can I employ some of these mental tricks (like for example estimating tasks by points while disregarding how much calendar time that is associated with) while also being the manager of myself? Im sure its simply be aware of the pitfalls of thinking in deadlines, to avoid “Student Syndrome”, to focus on the benefit and spirit behind this sort of goal setting. Im thinking it would help me if I took one day a week to put my “project manager” hat on and divy up tasks for the coming week into story points, and then kept the hat off the rest of the week to keep time based goals out of my way. Does anyone with some experience scheduling their own time using tips in the talk have any suggestions?

erikb 8y ago
It doesn't make sense for yourself. The idea is to have one person tracking another (group of) person(s) and thereby having some feedback and motivation. Maybe you can grow a team with other freelancers and track each other?
- jonchurch_ 8y ago
  That makes good sense to me actually. By the time I finished the talk, I realized there were some great takeaways for me in terms of understanding product management, but that it would be foolish overtooling to try and solve for problems that I dont actually have on the scale the tools are designed for. Thanks for your input!

forapurpose 8y ago

The author, based on the technology and products he's chosen to work on, is either visionary and courageous, completely lacks foresight, or enjoys pain: Avery was the lead engineer for Google Fiber's home wifi devices, building, managing, and monitoring the whole fleet in customers' homes. ... Before that, he started startups including one that deployed Lotus Domino in 10 minutes, and one that did unspeakable things to Microsoft Access databases. Microsoft Access, Lotus Domino, and consumer Wifi (mass-deployed!)? Shoot me, please, three times. On the other hand, they are a great way to learn the challenges of project scheduling and management. (In fairness, Lotus I mostly know by reputation, but the other two are enough.)

apenwarr 8y ago
Of your proposed motivations, I’ve been accused of all three but it’s probably the third one :) — the author
- w4tson 8y ago
  Good talk. I thought it was interesting what you said about student principle because I have a counterpoint to it. Which is that not carving out time day to day to tackle tech debt (via sand bagging) means the treacle gets thicker and harder to run through and the volume of bugs increases which leads to corners being cut to get features out at the old pace. So the argument to over-estimate or sand bag, and fold in better solutions with the boy scout principle seems to me the best way to make a brown field site green again. I’ve had one experience of this which totally worked. Time to implement features went from weeks to hours. I’m currently trying to apply the same method again with mixed results
  - apenwarr 8y ago
    The approach recommended in the talk is to use relative size estimates instead of absolute size estimates, which removes the possibility of over-estimating (or under-estimating) or sandbagging. During the conversion phase from relative sizes to absolute sizes (which should be based on historical measurements, not aspirations), you can choose to add a bit of extra time so that people can work carefully and fix things rather than feel rushed. That's often a very good idea.

erikb 8y ago

It sounds very attractive to developers, and I myself was a huge fan of this way of thinking for a long time. Sadly real life teams are never even close to this. And there are reasons for that, which we might like or not. But they have to be accepted. For instance most project leaders are not good developers nor good managers. And they don't really want to advertise that fact, because just like us they believe that anybody actually cares. So they get even worse by not tracking relevant metrics and instead focus (not by coincidence but by cunning) on metrics that are painful for developers, like current_open_bugs, or open_features_that_nobody_understands_and_that_where_discussed_with_nobody. They do that because it increases pressure on developers, hooks them with their desire to become better, and they provide automatic goals that can never be achieved. And these are the desired outcomes for the project leaders. Because if everybody is under time pressure, you don't need to worry that someone might steal your job, if everybody already feels bad about themselves they will not criticize you openly (and are motivated to work harder), and if there are always automatic goals you don't need to think about new goals all the time. What is interesting to me is that nobody puts these people actively at the top of the projects. It's more like they grow to these positions naturally. But now that they are there, you can't really apply the logic from the presentation to convince them. Insted you might even give them the impression that they don't apply enough pressure yet because you are criticising their job.