In a recent conversation, I realized that very smart and experienced project managers do not always know the difference between activity-based plans and deliverable-based plans.
While activities might result in an interim or internal deliverable, activities do not result in a user-focused deliverable. The team might make some progress, but not progress users can see. That means we think the project is on track when it's not. Then, everyone is surprised when the project is late.
Here are some examples of activity-based deliverables:
- Any deliverable at one level of the architecture, not through the architecture, such as a database, or just the UI without the corresponding work through the architecture.
- Any kind of internal documentation, such as an architecture document or a test strategy document.
- All planning documents.
Your team might need these documents, especially if the people can't or don't collaborate. (Often, can't is a function of geographic dispersion. See Hours of Overlap for more details. Don't is often a function of managers thinking in resource efficiency, not flow efficiency. See the Flow Metrics for why that matters.)
Whatever you do, don't blame anyone on the team for working according to the organization's culture! Most people work according to their rewards.
Deliverable-based planning focuses on the end user (or the buyer of the product). Activity-based planning focuses on the team or managers.
You might need activity-based deliverables. But don't confuse activities with project progress. That's why I like to plan for deliveries through the architecture.
Plan and Implement Through the Architecture
Only user-focused deliverable-based planning can show you actual product progress. That's because everyone can see the value as the team produces it. That's the point of the image here, implementing through the architecture.
If we plan and implement across the architecture, we have plenty of activity. That's one reason component teams are so busy all the time. The component teams need to focus themselves to work on fewer features at a time, so they can release something useful.
However, until everything lines up through the architecture, we can't tell what value our activity brings to the product.
I much prefer deliverable-based planning to activity-based because delivery based planning allows the team the fastest possible feedback and learning. Yes, it's all about the speed of the feedback loops.
Deliverable-Based Planning Increases Learning Speed
Imagine this scenario: Your team implemented several platform-level changes in a previous iteration. (Those changes were an activity, according to my definition.) Now, 2 iterations later, you're ready to implement the middleware and the UI changes. The team starts, and on the first day of trying, they find a Big Bad Defect.
That's okay, you have time to fix it.
It takes a couple of days, because the platform people have already started something new. They stop that and return to this problem. Everyone works through the problem together. All good.
The same thing happens again on Day 4. (And again, on Day 6. Etc.)
Do not blame anyone here. The code base, and even more importantly, everyone's learning changed from the platform implementation several weeks ago to now. The team knows more now.
How could the platform team have done this differently before? Here are some options:
- Create user-focused much smaller stories.
- Swarm (or mob) over the work from UI to platform and back again as a team.
- Right-size the work or recognize it's not right-sized and manage that risk.
Activity-based planning prevents people from knowing the project reality.
Deliverable-Based Planning Might Not Work for Your Project
While I have yet to see a project or program where deliverable-based planning does not work, maybe your project is different. The higher your cost to release, the less likely you might be to use deliverable-based planning.
In my typical contrarian fashion, that's when I recommend you need more deliverable-based planning. That's because you'll get to the end of the project and realize you're not done. You're in the 90% Done schedule game.
Want to know more? See:
- Manage It! for how to use deliverable-based planning (with yellow stickies) for almost any kind of project
- Agile and Lean Program Management for deliverable-based planning for larger efforts
- Create Your Successful Agile Project for deliverables focused on agile efforts
- Project Lifecycles for how to see the feedback loops.