Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do. That’s ok, as long as you plan to […]
One of my clients claimed he had ADHD. He had trouble keeping projects focused on one goal. I’ve known him for a while, and he didn’t have this problem when he was a project manager. Nope, he made sure that each project he managed had a goal, and beware any senior manager who wanted to
You and I know that the schedule is an estimate. The project schedule is your best guess about when the project team will reach which milestones, and when the project may complete. But a schedule is not a prediction; it is a guess. So when I meet senior managers who want a project team
Sometimes, I work with organizations where there’s an implicit agreement not to discuss the schedule. I’ve seen this schedule game in two flavors: the first is Dream Time, where the project team and management believe the schedule, especially if it’s in a scheduling tool with lots of graphs and different colored lines. The other is
A few years ago, a senior manager called me. “We have a project in trouble. We started off hopeful, but now it looks impossible.” I asked a few questions, and discovered they had never done a project like this before. It was bigger, in a different language, on a new platform, with a shorter
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
© 2005 Johanna Rothman. Some project managers considering moving to iterative, incremental, or agile lifecycles, stumble when it comes time to move to rolling wave planning. They aren’t sure how to start it, how to continue it, or how to see where the project is without using a more traditional Gantt chart and planning the
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
When I do assessments, invariably someone says to me, “JR, how long should the testing really take? It takes our testers (4/5/6/30 insert your number of choice here) weeks, and we need it to take less time. Why can’t it take less time and how can we tell what’s going on so we know
Sometimes I discover that one of my great ideas has already been discovered by other people 🙂 I first wrote about rolling wave planning in 1997. For those of you who can’t stomach the paper (it was one of my earliest pieces of writing), here’s an updated description of rolling wave planning: Loop: Plan what