April 20, 2012, 4:01 PM PDT
Takeaway: When you combine project management pitfalls with software development challenges, you have a recipe for some big (but often preventable) problems.
Project management is never an exact science, but when you combine it with the vagaries of software development, you have a recipe for disaster. I have seen a fair number of common mistakes that project managers make when working with software development projects. Some of these mistakes are not exclusive to software development, but they are especially prevalent and damaging in that context.
1: The “pregnant woman” mistake
Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again — the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true.
Every person you add to a project adds friction to the project as well – things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just can’t be split up to be done by many people or teams at once. They simply have to be done “one foot in front of the other.”
2: The wrong metrics
Managers need metrics for variety of reasons: measuring “success” or status, performance reviews and analysis, and so on. The mistake I see too often is that the easier it is to collect a metric, the more likely that it’s not measuring anything useful. Of course, the easiest metrics to collect or understand are also the most likely to be used. Let’s take “bug tickets” as an example.
It is easy to count how many tickets get entered. But that is not a good measure of quality, because how many of those tickets are user error or truly “features”? So managers often look to the next level of metric: ticket resolution rate (tickets closed per day or week or iteration or whatever). If you have ever dealt with a help desk that constantly closes tickets for things that aren’t actually fixed, causing a proliferation of tickets, you know what it’s like dealing with an organization driven by this metric!
Instead of actually getting work done or helping the user (for example, leaving tickets open until the user accepts the resolution), the organization exists solely to open as many tickets as possible and then close them as quickly as possible, so it can get its resolution rate up. A better number would be the hardest to measure: ratio of true “bug tickets” created in relationship to features deployed, changes made, or something similar. Needless to say, that is not an easy number to understand or to collect and report on. The result is that organizations choose to make decisions based on the wrong metrics rather than the right ones, due to convenience.
3: Estimating times too far out
A common problem I see with certain project management methodologies is that they like to play “just so stories” with timelines and time estimates. Project manager who honestly think they know what pieces of functionality any given developer will be working on more than a month or two out (unless it is a very large, broad piece of functionality) are likely to be disappointed and mistaken. Software development is just too unpredictable. Even if you can prevent or account for all the usual things that alter timelines and priorities, there is still little guarantee that things will take the time you think they will.
4: Estimating times too broadly
Another typical issue with time estimates involves not breaking tasks down into small enough pieces. If I’m told that a piece of work will take one week, I’ll ask where exactly that number is coming from. Unless someone has analyzed all the minor pieces of work in the whole, a “one-week” time estimate is nothing but pure conjecture and should be disregarded.
5: Failing to account for tasks
How many times have you seen a deadline blown because it was established without accounting for a critical task like testing? That is another reason why you cannot and should not ever accept a task on a timeline that is not broken down into its component tasks. There is a chance that the estimate omits something important.
6: Poor communications
It is important to keep everyone in the loop on project status, but it is easy to forget to do it. This is where a lot of the mistrust between IT and the business team comes from: The business does not feel like it has a good handle on what’s happening with its projects. And the more it feels left in the dark, the more likely it is to start trying to micromanage or force things to happen the way it feels it should be done. You can mitigate this problem by letting people know where things stand, both on a regular basis and when milestones are accomplished or the status changes.
7: Disconnected business priorities
There is often a wide gap between the priorities of projects within the development organization, the priority of the project in the view of the overall business, and the priority of the project in the eyes of the requester. A common issue is that a “high priority” project for one department is not viewed as important by the business because it does not generate revenues, and so the developers also downgrade it. Everyone needs to be on the same page with priorities, and a large part of that is to ensure that business units are not evaluated on the basis of projects that the overall business considers lower priority.
8: Constructing a wall of process
When the development team feels overwhelmed, one of the natural reactions is to establish a lot of process to slow things down. I have worked at places where even the most simple of changes required a change request form to be filled out (on paper, of course), in triplicate, physically disseminated, agreed upon, cross-signed by managers, and after all of that, there was still a 45-day minimum time until the work was to be done! Needless to say, this organization was not seen as a “partner” or an “important lever for getting work done” in the business, they were seen as a cost center and treated as such. The wall of process is typically a stopgap measure to deal with deeper issues in the process or company’s culture, and while it is easier to put up the wall than to deal with those issues (and in some companies, the issues are irreconcilable), the wall of process is counterproductive and leads to a hostile environment.
9: The “hit-the-ground-running” myth
When adding people to a project, it is tempting to assume that they can hit the ground running. No one hits the ground running in the world of software development, and those who say they do are mistaken. Every project has an acclimation period, and the farther along the project is, the longer that acclimation period is — there is more and more code to understand and get a handle on. Failing to take this into account will get you into hot water. It may take only a few days or weeks for a developer to come into the project at the beginning, but it could take months for a developer to be fully productive when added to the project long after it has started
10: Multi-tasking
This is another “skill” (like “hitting the ground running”) that people think they have, but they really do not. The more you ask people to multi-task, the worse their work will be and the longer it will take. This applies to multi-tasking at the minute-to-minute level (juggling emails, phone calls, actual work, etc.) as well as the hour-to-hour or day-to-day level (handling multiple projects). The more you demand from people, the more the wheels fall off. To make it even worse, multi-tasking not only is likely to mangle the work, but it grinds people up and sends them looking for another job eventually… forcing you to bring in new people in the middle of a project and causing even more issues.
Postingan
