David's Blague

Inspired by a veritable outpouring of interest (by which I mean a coworker mentioned to me that he had read at least one of my posts on the topic), today is the continuation of an occasional series on project management. It is my profound hope that by posting my thoughts here, I would be less likely to pontificate in person, when someone asks me an innocent question such as "So, project management..."

Today, I want to start with the short version of an exchange I once had with Richard Stallman (RMS), whom I idolize. I was tasked with making a piece of software, and RMS, who was looking over my shoulder, asked what I was making. I responded, "it's a content management system."

Stop me if I've told this story before.

RMS responded, "That's like saying you're doing something with stuff. What is it really?" A short chain of questions and answers followed, after which we decided I was writing a piece of software to publish news articles on the Internet. We called it an "Article Publisher." RMS talked a little more after that about how important it is to use the right words to describe software.

In that vein, the word "project" is one we should be careful with. Typically, outside of software, a project is something one does, and then one is done with. In software, however, that is called a "release." I like the word release a lot. It signifies the point at which a piece of software is let go. The word project is ambiguous: sometimes used to talk about a release, sometimes to talk about a product, sometimes to talk about something-someone-is-working-on.

On that topic, I want to offer clarification to one thing I mentioned to the coworker in question. I told him I was unsure how much common ground there is between building a tank and releasing software. In particular, I mentioned that too often people think of a release as incorporating both a scope and a deadline (when in fact it can be only one or the other).

The clarification is this: when building a tank, it's done when you've got a tank. Even if one really wants the tank very soon (which I presume is often the case), it's done when the tank is done, deadline be damned. Software, however, may be quite useful long before the full scope is completed. In fact, once a minimal set of functionality is achieved, release becomes more a matter of negotiation than of reality.

The mistake made when planning a software release is to presume this means we can have a fixed scope and a fixed deadline and necessarily stick to both of them. That's just silly, and over the long term the only thing it achieves is to get programmers to excessively pad estimates.

We get either one or the other: fixed scope or fixed deadline, and recognizing that at the outset makes the release run a lot more smoothly. There is, of course, software which has neither fixed deadlines nor fixed scope, and that software is either the best, or the worst, but certainly a topic for another day.

Labels: project management, scheduling

Managing software projects involves a great deal of scoping. I like that word: scoping. It brings to mind the microscope we had when I was a kid, which my dad had when he was a kid, which is very much like the one my own kids have now.

Scoping, for those new to the conversation, is the act of describing a feature and subsequently deciding whether it will be included in a given release. If it's to be included, it's in scope. Otherwise, it's out of scope.

I like this metaphor in part because there's no presumption that it's something done at the outset; rather, it's a continuous activity throughout the course of the project. A good project manager will be managing the scope in such a way that features bringing very little benefit for a great deal of risk can be scoped out. Alternatively, features with a great deal of benefit requiring relatively little work can be scoped in, but that's a topic for another day.

Today, I want to make only one subtle point, which is that when an actual, physical scop is in use, the activity of narrowing the scope is called "focusing." And it's not something to be avoided- it's something to be embraced.

The end of a release cycle can be a stressful time, and it is made even more stressful by managing it as if the scope and schedule are fixed. Only one of them can be, and in general, I recommend fixing the schedule rather than the scope. There's nothing like a real deadline to bring focus.

And by focus, I mean both clarity, and reduction of scope.

Labels: project management

Project managers have a single superpower: to cause an incomplete project to be complete, without accomplishing any tasks. This is done by convincing stakeholders they are satisfied with the work that has already been done, and declaring it ready for launch.

But let me back up. Project managers only ever get asked two questions: "Is it done yet?" and as a follow up, "When will it be done?" The entire profession sprung into existence because this question was asked so frequently and ardently it merited a person dedicated only to repeatedly explaining that no, it is not done yet, and here's why.

So on one side, project managers have an irresistible force: curious stakeholders. On the other side, they have an immovable object: programmers. When we do our job well, we keep both sets of people happy, with some help from both sides.

Communication. Let's say a programmer hasn't finished a task, because she got drunk at 10AM on a Tuesday, and passed out on her couch. Huge problem. Unless... let's say that programmer told her project manager the week before that she was planning to get drunk and pass out on her couch on Tuesday, and that the task scheduled for that time was likely to go uncompleted until it could be rescheduled the following Tuesday.

No problem! The project manager will then send an email that says something like, "Due to an unavoidable conflict with another project, a critical task will be delayed for a week, causing one week slippage to the final schedule." And nobody will care, because they are finding out ahead of time, and can, in turn, do whatever it is they do with this kind of information when they receive it.

Which brings up a second: planning.

Project managers function best when everyone else does just a little bit of planning. We don't expect people to plan things like car wrecks or deaths-in-the-family, but we do expect people to plan things like Christmas or hiking the Appalachian Trail. Some discretion is involved, obviously.

With that, I now intend to arbitrarily and capriciously demonstrate the superpower that I explained earlier. This is my last post about project management, because the series is finished. Four posts were planned, and four posts were made. Great fun was had by all. The project was a success.

Yay!

Labels: programming, project management, scheduling, software

A second, and dramatically less useful abstraction The Meeting. Ah, meetings. Meetings are easier to define than tasks, and on some project teams, more frequent. As with tasks, I offer a definition:

meeting (n): a scheduled event, in which attendees follow an agenda

Meetings kind of suck. I think this definition gets that point across. However, there are both social and technical reasons for them. The social reason is that many programmers dislike having to tell a group of people they haven't completed a scheduled task, which is a stupid, sucky reason to have a meeting, but there it is. The technical reason is that meetings are high-bandwidth and low latency, which is sometimes needed.

A few words on how project managers can make meetings suck less... send out an agenda ahead of time. Put items on the agenda, with approximate times next to them, and people's names. If a person's name is on the agenda, attendance in mandatory. Otherwise, it's not. Start meetings on time, and end them early. Socialize afterward. Make announcements via email: announcements do not require low latency or high bandwidth. If there's nothing requiring low latency, and nobody needs to be shamed into completing a task, cancel the meeting. I don't do that nearly often enough.

And a few words to the programmers... don't be a jerk, not even if you really hate being in the meeting. Either come and act like a competent grown up, or show some intestinal fortitude and blow it off. If a programmer's name is on the agenda next to an unresolved item of business, one way to miss the meeting without making the project manager go insane is to resolve the item prior to the meeting, and let everyone know.

And a few words to the stakeholders who will inevitably also be in the meeting... if you want to ask a question or discuss a topic in the meeting, email the project manager and ask to have it on the agenda. The project manager can probably make sure there will be a good answer waiting in the meeting, and may be able to pose it in a way that doesn't piss off the programmers.

Lastly, ten words from Despair, Inc. about meetings that should always be in the back of everyone's mind when deciding whether to have one: none of us is as dumb as all of us.

Labels: programming, project management, scheduling, software

(editorial note: despite my previous post complaining about the term Project Manager, I'm still going to use it. For what it's worth, it makes me feel slightly dirty)

Tasks are one of the most useful abstractions in the project manager's toolkit. Unfortunately, they are also one of the most poorly understood. With the hope of easing some of this confusion, I propose the following definition:

task (n): scheduled work, assigned to a person, for a purpose

In my initial writing of this post, I expounded quite a lot, and realized all my explanations were detracting from, rather than adding to the clarity of that definition. I think I'll save muddying of the waters for subsequent installments.

Labels: programming, project management, scheduling, software

The title "Project Manager" brings to mind an interaction with rms several years back. I was working on a "Content Management System" for a mutual acquaintance, and he asked me (seeming innocent):

"What are you working on?"

"A Content Management System." Simple enough.

"What do you mean?"

"Well, it's a system that manages content." I hadn't known Richard long at the time.

"That's like saying you're 'doing something with stuff.' It doesn't make any sense." Richard had a very good point, but I was still stuck. "What kind of content?"

"Mostly news articles, I guess."

"What are you doing with them?" he continued.

"Uhhh... publishing them to a website?"

"So you're writing a piece of software to publish articles? Why don't you call it an 'article publishing tool'?"

Using the title Project Manager is like saying I'm somebody who does stuff with things. I've spent a while trying to come up with a better alternative, and last night while I was putting the kids to bed, it was stuck in my brain for some reason.

What I do, is schedule. It doesn't sound glamorous, and much of it isn't. I write meeting agendas and send email and set up conference calls. I am tasked with guessing when it's going to be done, for some arbitrary values of "it" and "done". Most of all, I try to figure out the sometimes complex interdependencies between tasks and personalities.

What I schedule, is software. I don't know if scheduling a tank or a road or a rocket launch is really the same. Project Management Professionals [sic] treat them as similar problems, but I don't ever run out of steel or tar or hydrogen fuel, and so far I have never run out of bits, either.

I am a Software Scheduler. Since that job title still sounds like I'm someone who predicts the future and bends the space-time continuum, I hope to make this into an occasional series about how software gets scheduled.

Labels: programming, project management, scheduling, software