It’s winter here in Massachusetts, and we’ve had lots of snow, ice, rain, snow, ice, snow, ice, rain. All that freezing and melting plays havoc with the roads. We have lots of potholes, and the local and state governments are busy doing emergency repairs all over the place. (For those of you who don’t know […]
Here’s a common scenario I was discussing with a colleague last night: They’re at the end of a project. They used some combination of a serial lifecycle, becoming more incremental as they proceed through the project. But they still have a ton of open defects, and a few not-quite-finished features. My colleague was complaining about
I’ve been teaching a project management workshop, and one of the participants said something brilliant: “If you estimate in days, you’ll be off by days. If you estimate in weeks, you’ll be off by weeks.” If you estimate in months, you will be off by months. Here’s why. The more you can break a big
Imagine you’re a project manager. You talk to your technical lead and ask how far along the team is. “Oh, we’re about 90 percent done,” he says. If you’re like most project managers, your heart sinks. You’ve been here before. Ninety percent done means the other 90 percent is left to do. But what can
Contents: This month’s Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 1 Announcements =-=-=-=-=- Feature Article: Discovering and Maintaining Your Project’s Heartbeat Some projects zoom along, making progress regularly. Others feel as if they slog along, with barely any progress from week to week, or worse, month to month. Why? The zooming projects have
I’ve been attempting to clean up my office since I moved into it. I had some luck a while ago, using emergent design techniques for cleaning up. But that wasn’t enough. I was ready for an office redesign. So that’s what I did this weekend. Here is one before picture: The rest of the
I was a fortunate young developer. In my first three months at work, I ran into the 90% done schedule game. I did it to myself. I estimated a particular task was going to take 6 weeks. Of course, being an arrogant and naive developer, it never occurred to me to break the task
I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem. So
Student Syndrome occurs when the person with the task waits until the last possible moment to start. Some people spend their entire academic career waiting until the night before a project is due and then starting it, pulling an all-nighter, and getting some (hopefully adequate) grade. Student Syndrome isn’t for me, but I know lots
I’ve noticed a common theme among the projects in trouble I’ve encountered over the past few months: functional milestones without deliverable milestones as a part of the functional milestone. Here are examples of functional milestones: “requirements complete,” “code complete.” These milestones raise these questions for me: How can you know something is complete when