Written by Bill Snow.
Filed under practicality; process.
Monday, August 17 2009
I decided to write a blog post about project management in software design projects because, for the most part, it pisses me off. That isn't to say that the people who do it make me angry, or that projects shouldn't be managed or something. But far too often businesses and software developers fall into the same old myths and traps that Frederick P Brooks tried to dispel around 1970 in The Mythical Man-Month.
Designing something new is a creative process. Figuring out how something works is like that, and figuring out how something works for you is just as complex and creative. That's a good thing. Everybody likes creative solutions to problems, and that's what smart software developers are all about (like us, wink-wink).
Managing that creative process, understanding it, taming it, and making sure that essential creativity is applied to problems that matter is what project management is all about. Where Gantt charts fit into that, I have no idea, but I guarantee you they don't make software projects get delivered on time.
I'm a cranky guy, but I'm not going to just whine about problems, I'm going to tell you ways they can be solved. Here's a toolbox of a few patterns of human-human communication that we sometimes employ at Tiny Planet to make sure projects run on time, and everybody is happy. We didn't invent any of this stuff, but we use what works in a particular context.
Take the two-week tempo. Whenever possible, we like to move projects forward bit by bit, in two-week bits. At the beginning of each cycle, you decide what the goals are for that two-week interval, and at the end of it you demo what you've got. As a client undertaking an important and potentially expensive software project, this gives you control over product development by allowing you to make those critical minor adjustments in direction as they happen. As a developer, this keeps you motivated and confident that you are on the right track. Two weeks is enough to really get something done, but not long enough that you can seriously lose track along the way. Having relevant not-too-distant deadlines is a good thing because it keeps you focussed. Deadlines that are 6 months away are much harder to concentrate on, and in reality most people do a heck of a lot more work in the second half of a deadline time interval than the first half. I'm guilty of that, even though I try to stay consistent and organized all the time. When do you think I write blog posts that are due Fridays? Not Monday, that's for sure.
Some great ideas about how to manage projects have come not coincidentally from an attention to realism and what seems to be essentially an acceptance of unfortunate character traits. I think the two week tempo is like that in some ways because we have to drop the ideal notion that we can plan our time for the next six months accurately and precisely throughout a creative process. It also relates to the perspective that written specifications are always ambiguous. We need those meetings every two weeks so you can tell us if we read your specs right! It's a funny thing about language and the written word. The same words always seem to mean different things to different people. There are a few ways that people try to eliminate ambiguity from the written word. In contract law there are all kinds of seemingly circuitous phrases, paragraphs and idioms that occur over and over again, just because they are used to eliminate ambiguity in some sort of agreement between two people. If we - society - were completely successful in developing unambiguous contracts, then a judge's job would be very easy, and there would be basically no need for law suits. Sure. The other set of unambiguous languages are programming languages. These really are unambiguous in a way, but the process of specifying what you want a computer to do using this sort of unambiguous language is called "programming." Typically you have to be pretty specialized to do it. So why do software people so often write books of program designs and specifications that detail everything that a program should do? Don't ask me, I don't think it works. There's too much ambiguity in screenshots, flow charts, and descriptive text. If you want that much detail, write the code. If you're not a programmer, work closely with one so that when each individual exceptional case comes up, you're the one that provides the answer about what to do.
Get rid of those book-length specification documents and get a two-week tempo going. That doesn't mean you don't write anything down, it means you write down the very specific stuff only two weeks ahead. You write all your ideas about how things will work and interact as user-stories. If you want a web site that someone can use to play games, write that down. Write down the steps they take to do what they're trying to do. If you need to revise your business process for onboarding clients, write that down. How are they supposed to come on-board, and how do you see the computer system relating to the handoff from sales to support? What steps do the sales and support teams take? Worry about what the screens look like later, when it fits in with other parts of the system and starts to make sense, otherwise you're going to write a spec in the context of the isolated case of a specifc customer's handoff details, and it's going to be interpreted differently in the context of web-app design that considers lots of other stories too.
I'm leaving you with procrastination, short attention spans, poor communication skills. What does this have to do with answering the question "how long will that take?" True, that's kind of a big deal that needs an answer, and project managers very often have that answer. It comes off the gantt chart. I'm saying "it depends" which is always the worst answer to anything. The project manager's job is way more complex and important than just cranking a meat grinder where estimates go in one end, and the delicious sausage of a deadline comes out the other. The project manager is responsible to manage expectations, communication, and progress. He chooses the communication tools and how they'll be used, and sets up the context that makes everybody confident they know what's going on, and when to expect what.
Sometimes people ask me "when is it going to be done?" and I sure as hell want to tell them "here's what we have now, which is pretty good considering. So we need to do x,y and z and we're confident we can do that by the deadline." Kind of like "it depends" but way more confidence-inspiring than "in about two months, give or take two months."
