So far, I’ve addressed how a project charter can help a team start a project fast and well. That’s why the project charter must clarify product vision, the various project risks, and product risks. And, it’s equally important to know what done means. If the team does not know how little they can do to […]
This is Johanna Rothman’s July 2025 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom of this email. Mike, a new senior leader, wants to know when Engineering will deliver specific projects. He would prefer more accurate estimates, but he’s okay with relative sizing, such as: Small projects: Not more than a quarter (12
I’ve been working with a new-to-the-organization senior leader, Steve, who struggles with this challenge: He wants to capitalize some operational expenses. (That’s a move from OpEx to CapEx.) He is convinced that will give him some freedom to change things while everyone is still working hard. So they’ve asked all the technical people to fill
Your managers want to measure all kinds of interesting pieces of data to run the company well. Much of that is reflected in your organization’s Profit and Loss (P&L) statement. (There’s a great site with an explanation of a P&L statement.) Notice any organization’s three big numbers: Revenue, all the operating expenses, and net earnings.
This is the March 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email. Susan, a product leader, has a big problem. One of the senior managers, Tim, often wants to know the cost (or time) required for a new feature or a new product. So he asks
In my first post, Why We Have Too Much Pressure and Planning & Too Little Delivery, I discussed the issue of too much planning and how that reduced delivery. In this post, I’ll address how to increase delivery by planning less. (I have a draft post of the system view of how too much planning reduces
I work with many teams that have extensive product backlogs. Each iteration has a backlog of more items than the team can typically finish. Worse, some organizations want many quarters’ worth of backlogs, as in the image in this post. There are several problems with long and extensive backlogs: They tend to be wishlists of
At a recent conference, one of the attendees, Dave (not his real name), said, “I really liked some of your answers at the panel this morning. How much do you charge to speak?” I said, “Thanks. I charge based on several factors—” He interrupted me and said, “No, it’s an hour—or maybe, a half-day max.
I’m excited to be part of TheAgileNetwork.com. That’s where people with significant expertise in agility gather to share their expertise. While frameworks and methods are useful for some people, my clients find them of limited value. My clients—and I bet many of you, my readers—need practical and pragmatic ideas rather than a specific agile framework
I discussed how to calculate the Costs of Delay in the previous three posts, and then offered an example in Part 3. Notice that the example uses cycle time or how the team feels about the remaining time to think about the value in order to rank the work. (The links to all the posts