A while back I was helping a friend and neighbor research web-based construction management software. While home construction and project management are not my fields, I do have similar business challenges, so the research was educational for both of us.
During that process I came across the concept of a Work Breakdown Structure, a tool used in project management to define discrete work elements. The basic concept is to define planned outcomes, not planned actions. It sounds like simple semantics, until you actually try to think from two perspectives at once.
If you've ever planned or tracked a project with task or to-do lists, you've probably run into the same problems I have - too many tasks, undefined or overlapping tasks, and greater difficulty estimating time and costs. Using a WBS instead forces you to focus on results, leaving the implementation methods flexible.
(My ignorance disclaimer: these concepts are likely basic and obvious, to anyone formally trained in project and program management. If you'd like to share some of that knowledge, please do so in the comments...)
An upcoming series of network projects is a perfect example. Just to generate a quote, I need to break everything down and estimate times and costs. The projects aren't big enough to benefit from classic project management, with milestones, Gantt charts and reporting - that's just too much overhead and gets in the way.
On the other hand, breaking them down by tasks creates an ever-changing monster of an outline, the to-do list from hell that'll be deserted well before the projects are complete. So it's time to try something different, and from the opposite perspective.
As a provider of services, I naturally see these projects from a design and implementation standpoint - things to do and dependencies to identify. The client CFO and Executive Committee don't want or need those details - they want deliverables. Instead of a list of actions, they want
4. Automated VPN Backups In Production
That's a deliverable - a result of the project that is intended to be delivered to a customer. The work breakdown structure behind it must be based on outcomes (or interim deliverables), which is the opposite of a provider's natural perspective. Yet that customer perspective is the foundation - the WBS drives the scope of work, which then feeds a project management system if needed.
Here's an example from one of the projects, in a three-tier structure. The first tier are projects with limited or no inter-dependencies:
- Hub Site Firewalls Cutover
- Five Sites WAN Upgraded
- Hub Site Internet Migrated
- Automated VPN Backups In Production
- Email Migrated to New Firewalls
- Management Tools Updated
And one last example, as much to get me back to work as for illustration:
- Quote Sent
- Purchase Order Received
- Work Completed
- Invoices Issued
- Payments Received
