I spent two days last week facilitating a planning session for a
software project. I was working with a team from a functional organization with a pretty heavy phase-gate process, and a waterfall way of building. The team was fininsh their “definition” stage, and planning for a 3-month construction and test phase.
Most of their planning has been driven by their scheduling tool and senior managers’ desire for a sense of comfort and control, which pushes them towards high-level Gantt charts. (One of the sub-project managers came in saying that he already had his plan: it showed five (5) activities with durations in months.)
Well, that may be comforting to executives, but its useless for managing a project.
So for our planning workshop, we mapped deliverables.
Here’s why I pushed towards deliverables, rather than tasks:
Once we had a first-cut at deliverables, we started looking at risks.
We looked for areas where we could build out prototypes and tests parts of the system early, and defined deliverables for those.
We looked for all the points where we’d get significant new information that would affect the technical approach, the timeline, or overall project goals. We marked those to highlight them as points where key people will need to get together to review the new information, assess impacts, and replan.
We looked at how all the parts fit, and made adjustments.
We made a list of key decisions necessary to keep the project moving forward. We identified who would make recommendations, who would make the final decision, who would use the decision, and when it was needed.
By the end of the planning session, most of the deliverables were chunked up. The only areas that weren’t are still unknowable — areas related to areas where they’ll be using prototypes, tests, or other avenues to gain information.
It’s impossible to guarantee that this project will meet their date. But they’re in a better position to know what to look out for, stay on top of decision-making, and manage emerging information that will affect the project.
Even when projects don’t use Agile Methods there are ways to plan for new information and learning within the project, deliver small chunks of useful material (though not always working code) and acknowledge that not everything is knowable from the outset.
