Years ago, I was the expert for two specific products in a small development organization. When it came time for my manager to divide up the work, I always got those products to add features to, or maintain. That was fine for a while, until I got bored. I went to my boss with a request for different work.
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’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
In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision. Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop.
In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk. Sometimes, you don’t have short projects, so projects
Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development. One of my managers many years ago had a back of the napkin approach to cost of delay. “Johanna, we want to ship this product in the second quarter this
“George is on his offshoring rampage again,” Cindy said as she slumped down in Ted’s visitor chair. Ted saved his document and turned around. “Oh? Want to tell me about it?” “I need more testers for the feature teams we’re starting, right? I told him. I showed him the project portfolio and the projects we
Workshop Objective: If you’re dreading the next project—because you know it will be a disaster, or at the very least uncomfortable—it’s time to think about designing your next project. We’re accustomed to thinking about designing products or tests, but projects? Is it really possible to design a project? Yes. Lifecycles, those idealized approaches to organizing