I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says, Management is Prediction as a inference from Deming. When I read this quote, If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming I infer from Deming that managers must […]
I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what
I sent a Pragmatic Manager email last week, How to Avoid Three Big Estimation Traps. If you subscribed, you’d have seen it already. (That was a not-so-subtle hint to subscribe 🙂 If you’re not sure of the value of being on yet-another-email list, browse the back issues. You can see I’m consistent. Not about the
How to Avoid Three Big Estimation Traps I bet you need to estimate how large your project or program will be, at the gross level: “It’s bigger than a breadbasket. It’s smaller than a person on the moon.” More likely, “It’s about x people for about y months with this percentage confidence.” Or, you use
In a recent estimation workshop, one of the participants asked, “How do we estimate something we’ve never done before?” “Is it a feature or a project?” I asked. “A feature,” she said. “How do you do things now?” Based on her previous comments in the workshop, I suspected she was pretty good at what she
One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It! It was a little serendipity; I taught an estimation workshop right after I explained how to
I’m not a fan of using schedule or cost estimate as a way to value the projects in your project portfolio. If you do, you are likely to miss the potentially transformative projects or programs. In Manage Your Project Portfolio, I have an entire chapter devoted to ways to evaluate your project portfolio: business value
I’ve outlined five potential costs of delay in the previous five posts: The delay from not releasing on time, part 1 The delay from multitasking,part 2 The delay from indecision, part 3 The delay from technical debt, part 4 The delay from other teams as part of a program, part 5 The real problem is
Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release. One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all
Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt. One of the big problems in backlog management is ranking technical debt stories. It’s even