Breakdown #3: Deliverables-based planning

Projects produce things like: plans, documentation, new processes, manuals, new products/applications, new code, test scripts, lists of issues and risks and changes, statements of work, contracts, etc. My plan is driven by identifying the chunks of work (the tasks) necessary to create, validate, and accept those deliverables. It is used to manage those things.

My plan is not used to manage the resources that will complete that work. How do I mean that? Let’s walk through an example.

Deliverable: Business Requirements Document for Widget Alpha
The deliverable that needs to be produced is a BRD for Widget Alpha. The person assigned to do this task is a business analyst. In a typical plan I would create a section called “BRD-Widget Alpha”, assign it a task ID similar to BRD-WA, and assign it to resource BA-1. Underneath that section would be the following sub-tasks: Draft, Review, Finalize.

I wouldn’t go any lower than that and there’s a reason for this decision.

BA-1 (or his/her manager) should tell me how long each of those sections take, let’s say 2 weeks to write the draft, 2 weeks to review it with the actual users and do updates and changes, and another week to finalize it and get formal approval. That’s what goes into my schedule. It is outside my purview to track things like:

  • How many meetings are you scheduling during the draft period and who is attending?
  • What sections are in the document and how will you be completing them?
  • Day-by-day detailed status on the deliverable

Now this is not to say that if a BA wanted to volunteer that information I wouldn’t hear it. Or if I was asked to help schedule or attend some meetings, I wouldn’t. Or if I was asked to get a final list of reviewers/approvers (and manage that as part of the overall project governance process) I wouldn’t obtain that information and help move the formal approval process through. No, I could, I would, and in certain cases I actually do, those things but the key point is this: they do not belong in the project plan.

There is a difference between a work plan and a project plan – I am very careful to separate the two. In smaller organizations and environments, people where lots of hats, and the understanding of the delineation is helpful in making sure you’re aware of what hat you’re wearing when. In larger organizations where there is significant role differentiation, this delineation is necessary for good relationships between functions.

My plan is based on the deliverables required to complete the overall project. It shows the individually assignable tasks to support the deliverables. It is not a functional plan; it is not a resource plan (even though that feeds into it); it is not a glorified workplan.

It’s a simple, no muss and no fuss, project plan.

Please share this with a friend or colleague who you know would benefit from it and follow me on LinkedIn where I post other items similar to this.

Also, let me know how well the above helped you! Please comment below or send me an email at

If you would be interested in me coming to work with you or your company on solving a wicked problem you have, please take a look at my background and send me a message at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s