In Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, I explained how project risks can affect the team’s approach to the work. But project risks are not the same as product risks. Product risks are about the need for product innovation. The more innovation this product needs, the more […]
Let me set the context for this post about the project charter: By now, the team knows what it has to accomplish because they have a product vision. The next question is: How will the team manage their risks to achieve those outcomes? That’s where I recommend a team define its project driver, up to
I use many apps on my Mac, iPad, and iPhone. There is clearly something in the air because, during the past three weeks, most of them broke. Here’s a partial list: The password manager (on all three devices, with at least 4 failure modes) Two different health-based apps Various kinds of email-based apps What do
A senior leader, Jim, emailed me to clarify how to track a project’s progress. He’s a sales guy by training and is now leading a technology-based company. He’s confused. When he asks about progress, he feels as if everyone takes one step forward and two steps back, just as in the Project Kisses of Death
Susan, a senior leader of a 300-person department, wanted to reduce the risks of late deliveries, and respond to customers faster. Susan suspected the managers and teams were too wedded to their plans and not experimenting enough. That meant she needed an agile approach. But while she had been a part of several supposedly agile
One of the problems I see in projects and organizations is when people wish for certainty. Too many agile project managers and Scrum Masters want a known velocity. They don’t realize that velocity is a relative capacity measurement, not a guarantee. Product managers, the people who manage the project portfolio, all seem to want certainty
Being an Agile Leader People tell me agile is past mainstream now, into the late adopters. I don’t buy it. Oh, agile has jumped the shark and made it into our vernacular. The result: I too often see agile as something the teams should do, without management using agile to improve the environment or their
A reader asked me this question: “How do I report on the 1000 (or so) defects in our system? I have 10 minutes on the status call.” If you are working on a legacy application where the team was not able—for any number of reasons—to maintain technical excellence, you might have a problem like this. So
Iterations and Increments: For Any Project A project manager, Dave, is struggling with his project. His organization is not interested in using agile. Agile has a bad name, given their three-time attempt to adopt agile. (I’ll address that problem in another Pragmatic Manager.) That’s fine. Agile is not for everyone. However, Dave knows that prototyping
If you’ve been following the conversation, I discussed in Part 1 how I like agile roadmaps and gross estimation and/or targets for projects and programs. In Part 2, I discussed when estimates might not be useful. In Part 3, I discussed how estimates can be useful. In Part 4, I discussed #noestimates. Let me summarize