rss feed
Putting aside for the moment the unintentional implication that "project management is a problem", I'm immediately reminded of a particularly appropriate example of this sort of project management problem at my last coding job.My team was working on a big, important release. Our project manager had this Agile project management reporting tool that ostensibly tracked bugs and development tasks. At the start of the release cycle we had written out all our tasks on 3x5 index cards. (Yes, this was Agile with a capital A. Well, except for the whole lack of communication part.)As the dev cycle progressed, we handed this manager cards for completed tasks as we finished them. All she had to do was input this data into the project management reporting tool, and it would magically crunch some numbers and show a big green, yellow, or red light depending on whether the numbers indicated that the project was on track, veering off course, or crashing and burning, respectively.Wait, that sounds familiar. What exactly was it that Reg was developing?
Now I'm sure Reginald's project was much more sophisticated than the crappy little web-based Agile reporting tool that my manager was using, but the difference doesn't matter, because analyzing all of the information that a project produces really is only a tiny part of the problem. The rest of it is actually coming up with and communicating the information you're going to analyze.So, back to the story. My manager, after crunching the numbers and coming up with a shining green light, scurried over to her own manager and proudly displayed the good news. Green light: the project is on track! The software says so! Nothing to worry about! Everyone was happy. That is, everyone in management was happy.Fast forward several weeks. The release was late. Very late. And the end was still not in sight. My manager's manager was furious. He had been shown green lights every day up until the very date of deadline. Why was my manager reporting that the project was on track if it so obviously wasn't?Ah, and therein lay the problem. Up until the end, it was anything but obvious that the project was veering off course. It may have been obvious to a developer or two that there was this or that problem, this or that unmitigated risk. But since no one was really communicating via anything other than hastily scrawled notes on 3x5 index cards, none of this distributed knowledge was really captured. Any good, meaty project management information such as potential risks and areas of uncertainty were simply not gathered together into one person's head. No amount of analysis would've helped because, well, garbage in, garbage out.Long story short, my manager was unceremoniously fired soon after the release. Not because the deadline was missed, but because the deadline was missed while she was telling everyone that the project was on track. She definitely had a hand in the poor communication, but the developers were at fault too. Everyone was too blindly following the "process" without really thinking about anything that might lie outside of it. Like, say, communicating their own perception of whether things were actually on course.I am continually amazed at how, after a project fails, anyone bothering to do even a cursory post-mortem can easily pick out many of the warning signs in retrospect. Such as.. The new platform hadn't been tested at all a week before the release. Or, one of the riskiest parts of any project, integration of software from different teams, wasn't included at all in original time estimates. Or maybe a major bug that QA found early on wasn't getting any attention from developers.In fact, it's often the case that these warning signs are actually acknowledged by developers or testers during the release cycle as potential trouble areas, but for whatever reason (social, political, or cultural), these people fail to report the risks upward to the managers responsible for gathering and analyzing all of this data. In other words, at any given point during development, all the information you need about whether a release is on track is out there distributed among the minds of the developers and testers. It's just not being communicated.Reg's post suggests that prediction markets may be the solution:
That would actually be pretty cool: Setting up a prediction market within an organization to represent everyone's collective confidence in the release being on course. However, I think there's an even easier solution. Simply ask people what they think! No need for fancy buying and selling of virtual shares. If the project manager just went around periodically asking people working on a release about their opinion on the state of the release, a lot of the bottled-up warning signs and valuable risk information could actually be communicated appropriately, well before the post-mortem.With this approach there's still the potential of social and cultural factors getting in the way of communication. People rarely like being the bearer of bad news, and some corporate cultures go out of their way to discourage anyone from piping up. But despite these challenges, simply asking people their opinions on an upcoming release would yield a hell of a lot more valuable risk information than hoping that index cards or Bugzilla tickets can accurately capture and communicate this sort of data. As most projects are run now, people might grumble that this or that risk isn't being addressed, but unless they're directly asked for their opinion, they'll continue filling out 3x5 cards and writing code without mentioning a word about their concerns.The other side of this is that any manager polling the opinions of the populace has to actually be receptive to what he or she discovers. If three people say that the Foobar component isn't getting sufficient testing and could very well blow up right before the release, well then the manager has to be willing to turn the green light to red and make sure something's being done about the problem.Because project management is a social problem, everyone needs to be part of the solution. Not just managers, not just devs. Solving communication problems falls on everyone's shoulders.
blog - project management is a problem
posted by witten on June 10, 2007
In a recent post, Reg Braithwaite shared a post-mortem on his software designed to help project managers, and in the course of doing so, opined about what's wrong with project management (http://weblog.raganwald.com/2007/06/still-failing-still-learning.html):
Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem.
Putting aside for the moment the unintentional implication that "project management is a problem", I'm immediately reminded of a particularly appropriate example of this sort of project management problem at my last coding job.My team was working on a big, important release. Our project manager had this Agile project management reporting tool that ostensibly tracked bugs and development tasks. At the start of the release cycle we had written out all our tasks on 3x5 index cards. (Yes, this was Agile with a capital A. Well, except for the whole lack of communication part.)As the dev cycle progressed, we handed this manager cards for completed tasks as we finished them. All she had to do was input this data into the project management reporting tool, and it would magically crunch some numbers and show a big green, yellow, or red light depending on whether the numbers indicated that the project was on track, veering off course, or crashing and burning, respectively.Wait, that sounds familiar. What exactly was it that Reg was developing?
So I set out to write a piece of software that, pure and simple, would look at a software development project and show you a traffic light: a green light would mean that the project looks like it's on track, a yellow light would mean that the project needed help, and a red light would mean that there is no hope.
Now I'm sure Reginald's project was much more sophisticated than the crappy little web-based Agile reporting tool that my manager was using, but the difference doesn't matter, because analyzing all of the information that a project produces really is only a tiny part of the problem. The rest of it is actually coming up with and communicating the information you're going to analyze.So, back to the story. My manager, after crunching the numbers and coming up with a shining green light, scurried over to her own manager and proudly displayed the good news. Green light: the project is on track! The software says so! Nothing to worry about! Everyone was happy. That is, everyone in management was happy.Fast forward several weeks. The release was late. Very late. And the end was still not in sight. My manager's manager was furious. He had been shown green lights every day up until the very date of deadline. Why was my manager reporting that the project was on track if it so obviously wasn't?Ah, and therein lay the problem. Up until the end, it was anything but obvious that the project was veering off course. It may have been obvious to a developer or two that there was this or that problem, this or that unmitigated risk. But since no one was really communicating via anything other than hastily scrawled notes on 3x5 index cards, none of this distributed knowledge was really captured. Any good, meaty project management information such as potential risks and areas of uncertainty were simply not gathered together into one person's head. No amount of analysis would've helped because, well, garbage in, garbage out.Long story short, my manager was unceremoniously fired soon after the release. Not because the deadline was missed, but because the deadline was missed while she was telling everyone that the project was on track. She definitely had a hand in the poor communication, but the developers were at fault too. Everyone was too blindly following the "process" without really thinking about anything that might lie outside of it. Like, say, communicating their own perception of whether things were actually on course.I am continually amazed at how, after a project fails, anyone bothering to do even a cursory post-mortem can easily pick out many of the warning signs in retrospect. Such as.. The new platform hadn't been tested at all a week before the release. Or, one of the riskiest parts of any project, integration of software from different teams, wasn't included at all in original time estimates. Or maybe a major bug that QA found early on wasn't getting any attention from developers.In fact, it's often the case that these warning signs are actually acknowledged by developers or testers during the release cycle as potential trouble areas, but for whatever reason (social, political, or cultural), these people fail to report the risks upward to the managers responsible for gathering and analyzing all of this data. In other words, at any given point during development, all the information you need about whether a release is on track is out there distributed among the minds of the developers and testers. It's just not being communicated.Reg's post suggests that prediction markets may be the solution:
Sitting here typing this, I think the company who can do the best job of predicting the outcome of software development projects is Inkling Markets. That's because their entire business is about finding a way for people to communicate what they really think of something, not just what they think other people want them to say about something.
That would actually be pretty cool: Setting up a prediction market within an organization to represent everyone's collective confidence in the release being on course. However, I think there's an even easier solution. Simply ask people what they think! No need for fancy buying and selling of virtual shares. If the project manager just went around periodically asking people working on a release about their opinion on the state of the release, a lot of the bottled-up warning signs and valuable risk information could actually be communicated appropriately, well before the post-mortem.With this approach there's still the potential of social and cultural factors getting in the way of communication. People rarely like being the bearer of bad news, and some corporate cultures go out of their way to discourage anyone from piping up. But despite these challenges, simply asking people their opinions on an upcoming release would yield a hell of a lot more valuable risk information than hoping that index cards or Bugzilla tickets can accurately capture and communicate this sort of data. As most projects are run now, people might grumble that this or that risk isn't being addressed, but unless they're directly asked for their opinion, they'll continue filling out 3x5 cards and writing code without mentioning a word about their concerns.The other side of this is that any manager polling the opinions of the populace has to actually be receptive to what he or she discovers. If three people say that the Foobar component isn't getting sufficient testing and could very well blow up right before the release, well then the manager has to be willing to turn the green light to red and make sure something's being done about the problem.Because project management is a social problem, everyone needs to be part of the solution. Not just managers, not just devs. Solving communication problems falls on everyone's shoulders.
1 comment
Write a comment!-
Re: project management is a problem posted by ckponnappa on June 12, 2007 05:02 AM
Interestingly, I've found that simple things like ensuring that the manager is a working member of the team and isn't only superficially involved in reporting helps a lot.
As for the PM tools, ThoughtWorks is also coming out with mingle ( http://mingle.thoughtworks.com ), a pretty decent project management tool. I've been trying out the alpha release and it's quite interesting. The idea is that the ability to change your process is built into the tool. It expects you to change your process after every retrospective and it takes no more than a few seconds to do it. And the reporting is powered by a DSL called MQL (Mingle Query Language) which allows you to do stuff like "select all cards from iteration 0 to current where status is 'In Development' or 'Completed'" and have this render as a cross tab or a graph. Super flexible.