I've written a fair amount about software project management in this blog. I've also written a short book about it. Like the software quality book, so far I've only distributed it privately. But also like that book, I'm thinking of publishing it as a Kindle book.
Tid-bits on the blog
It's hard to be seriously involved with software and avoid run-in's (not to mention complete co-option) with project management. You can hardly start to think about writing some code without someone popping out with "how long do you think it will take," the question of estimates. If you resist or act uncomfortable, you're put on the spot. Everyone, you see, wants their software group to be as predictable as though it were a software factory. The people who talk this way clearly don't understand that dates are evil, but there are so many of them, it's like you live in a land of zombies.
While many programmers resist it, they most often accept project management as a necessary evil, as something that they can't avoid. As they age, sadly, most programmers accept this perverse thought as though it were a natural accoutrement of adulthood: wild young programmers may resist the bridle, but mature ones accept that it's part of life.
I too resisted it, and I too came to appreciate some of the rhetoric of software project management. But then reality intervened.
A bit more than 20 years ago I ran a small software group doing pioneering work in document imaging and workflow. A new management team took over, and were appalled that we just wrote code. I was guilty of about the worst thing a manager could be accused of (in their eyes): running an out-of-control, seat-of-the-pants operation in which people just did stuff, without the comfort and support of project management.
Things changed. Expensive project management software got bought.
Expensive consultants came in and lots of formerly productive people sat in excruciatingly long training classes. For days! Then we settled into a regimen in which lots of reports and dense charts
were generated regularly, and we threw around terms like "critical path."
Well, we "got under control." And stopped writing much code. And fell behind the market.
As we became more predictable, we became more inflexible. Timelines stretched out so far that sales people lost heart. It was sad.
After that baptism by torture, which was followed by many more, I really began to think about what was going on when I got involved with Oak. I had a chance to see lots of companies producing software with varying doses of project management involved.
I noticed that the Indian Outsourcing companies were pushing project management big-time, and winning business with it. It must be a good idea, right? When you dove into the details, they did not win by being faster and more flexible. They were completely rigid and slower. But predictable and marginally less expensive. Here's the bottom line: they won business by costing less. They cost less because they paid their programmers only about one tenth of the equivalent programmer in the U.S. But their methods had so much overhead that they staffed every project so much that the final bill to the customer ended up being only about 30% less than doing it in-house. So, oddly enough, the Outsourcers with their devotion to project management proved the point of how bad it is.
On the positive side, I saw entrepreneurial companies doing more work with less, having more flexibility, less overhead, and shorter cycle times. Had they found clever new ways to implement project management? No. They just found better ways to develop better software with fewer bugs, more quickly. That's all!
Systematic Thought about Project Management
These experiences led me to try to understand what project management was really all about -- why everyone kept trying to apply it to software, why it never works (except if you don't care about time or money), and what the alternatives are.
It was a long journey, and I was surprised that I ended up with a short book. As I state in the book:
“Project management” is as effective at guiding software projects to success as hopping and grunting is at helping pool balls to drop in the intended pockets – it may be entertaining to watch, but it has no constructive impact on the outcome. More important, to the extent that we focus on our hopping and grunting technique, we fail to pay attention to what really matters – hitting the ball correctly with the queue. Similarly, in software projects, the more things get off track, the more we seem to focus on project management hopping and grunting activities, so much so that the shaking floor actually makes things worse.
Project Management needs to be taken down a few notches
Part of the problem is that it just doesn't work. Another part is that everyone with experience knows it doesn't work. The crowning part of the problem is that even people who know it doesn't work and put it to the side when they really have to get something done, continue to kow-tow to it. This is illustrated by a story I personally experienced that I tell in the book.
I recently spent some time with the seasoned, non-technical leader of one of our portfolio companies, and some of his lead technical people. We discussed one of their most successful products. The CEO described how he got involved with a couple customers who had a problem that no one could solve, how he promised them a solution and got his programming team to throw something together that sort of worked. They then scrambled, fixing problems and coming out with a flurry of new releases, always listening to the customer and evolving their code until things settled down, the customer’s needs were met and the company had a new product line.“Of course,” said the CEO, glancing over at his technical people, “that was the wrong way to do things. Later, we settled down and got back to proper project management.” Of course – the CEO had to intervene and make sure something important actually got done. Later, “project management,” i.e., doing very little but trying hard to do that little on time and on budget, could be allowed to return.
Again, I'm thinking of pulling the trigger on the Project Management book. But first I need to finish formatting it.
Trigger pulled. Book available.