Project Deliverables ARE ‘THAT’ Important
EVERYONE that works on projects needs to know one thing: ‘real-world’ Project Deliverables are the key to successful estimating, statusing, and managing risk. It has even helped change the culture in my client’s organizations! Seriously, it’s that important. Done well, and your career will skyrocket; but discounting it will turn you in to a stick-toting, list-administrating gorilla. Disclaimer: No animals were hurt in the making of this article : )
Unfortunately, I won’t be able to cover everything about deliverable-based scheduling in this article, but I will show my unique approach for identifying
deliverables, which is the foundation of my ‘Fearless Project Management’ methodology.
Project Deliverables Can BE Methodology Agnostic
Before you discount this article as being ‘fake news’ LOL, let me be clear: I have PMP, CSM, ITIL and even some Lean/Six Sigma certifications. I respect the experts, but in the ‘real world’, project teams rarely have the time to implement the textbook processes and methodologies. This has forced me to adapt my thinking to create a unique approach to defining ‘deliverables’ and allows Project Managers and their teams to successfully identify scope, plan, execute, and status their projects regardless of the methodology, life cycle, department or type of project: a true, agnostic approach. …and there’s a roar from the crowd!
Learning Can Be Fun
I like to see my clients enjoying learning and ultimately build their confidence in their roles. Humor allows me to poke fun at myself and the long journey I’ve had to get where I am today. I’ve had great coaches, mentors and heroes, and one of the first things I was taught was the best way to learn is by participating in hands-on labs…and add some humor! Because I’m not THAT funny, and because I can’t get everyone in one of our workshops, I’ll share some stories and the highlights of our process, so you can get the gist.
Example Deliverable-Based Schedule Workshop
The class is usually a mix of project managers, business analysts, directors, resource managers and sometimes some VPs and C-level. This approach lets me get a sense of what everyone’s understanding of the PMBOK, WBS, WBS Dictionaries and how they apply them in their projects.
The first thing we do is get most of the students to agree on a product to build… (because we’re a democracy). We’ve had everything from a banking system, houses, airplanes to a new electric car, which was my favorite (thanks Standard Insurance). The students get into small groups, we present them with a scenario, and they have 15 minutes to identify the main deliverables.
Sample Workshop Scenario
Here’s a sample scenario that you can try with me and then compare it with some of the other students.
How to Identify Deliverables: Scenario 1: Luxury, Performance Electric Car
The leadership of our fictitious company has set a new goal that they want to move into the luxury, high-performance electric car market to compete with Tesla.
At this point I say, ok, come up with your high-level Work Breakdown Structure (WBS) but I give them up a tip to say ‘Deliverables’ (since many organizations shy away from the word WBS). Do you think everyone just starts to write away? Nooooo! They don’t because we’ve established our ground rules and the class knows that they must participate, and they must have some fun…so a barrage of questions begins. Usually, they’re the traditional triple constraint questions.
Traditional Project Management Scope Questions:
When is it due? Where will it be made? How many will we make? Who will make it? What’s our budget? On and on…
Agile or Lean Scope Questions:
Now I don’t completely agree with everything in Agile, but I can say the best questions come from the folks that have some familiarity with Agile and Lean’s Minimum Viable Product (MVP). Bing or Google it and see what you think, but, at a high-level, it’s a technique often used in software for building the most core features to provide to the customer and then adding additional features and functionality later. Whoa, what an epiphany! That’s brilliant.
These questions sound like:
- Do we need to have prototype(s) and what do we know about the type, features and size of the prototype(s)?
- Do we need a full-scale production line and by when?
Excellent questions! Notice that they’re still traditional but also include some thought towards the Minimum Viable Product (MVP) for the customer (which could be the design team, engineering, the car show participants or the owners of the production model). This is truly one of the differentiators I’ve seen with my project managers: that point in time where they realize that their customer is not just the Project Sponsor and the user of their product. It’s that point in time when a Project Manager becomes fearless (well maybe they just raise an eyebrow) and they realize they have internal and external customers.
With all of their Agile/Lean questions, I add a little clarity to our scenario…
Clarified Scenario: Luxury, Performance Electric Car
Our company wants to have a full-sized prototype for the Los Angeles Car Show 1 year from today. We are not allowed to drive the car in the building and our goal is to see what feedback is given about the car from people at the show. If we get good feedback, we’d like to have full-scale production delivering cars within 6 months of the car show. To have time to market our car to the show, we’ll need a 3d rendering within 3 months from today.
Now they have enough to make them dangerous and here’s some of the results we usually see.
Traditional Project Managers:
Electric Car Project (Team 1)
- Electric Car (Level 1)
- Project Management (Level 2)
- Quality
- Engineering
- Design
- Production
- Testing
- Project Management (Level 2)
Or
Electric Car Project (Team 2)
- Electric Car 2 (Level 1)
- Project Management (Level 2)
- Initiation
- Planning
- Development
- Testing
- Production
- Project Management (Level 2)
But what we’re really looking for is more in the lines of an Agile or Lean MVP approach, notice the deliverables are all at level 1
Electric Car Project (Team 3)
- Car Drawing (Level 1)
- 3D Car Rendering
- Miniature Prototype
- Full-Size Prototype
- Car Show Promotions
- Car Show Logistics
- Full-Scale Production Investigation
- Full-Scale Production Estimation
- Full-Scale Production (TBD)
What is a Deliverable or What it is NOT?
It may not be obvious to some about each of these, but let’s review the three options above. The first two are considered traditional PMBOK and are fine, but let’s make them a little better. We’re taught to always use nouns for our WBS and Deliverables, but I almost always see business areas such as ‘Project Management’ or ‘Quality’. I often see lifecycles and phases, too, and they’re a huge mistake. Here’s a couple reasons why:
Phases are not deliverables, and they make it impossible to do any simple Earned Value, that is to report the status of ‘Planned’ versus ‘Actual’ work. Think about how hard it is for a project manager to plan and status their activities if they all fall under ‘Project Management’. Now you can see how hard it is for developers and engineers to status and plan their work.
Improvement #1: Add project management and scheduling tasks for each deliverable. This makes it much easier to see the ‘work effort’ or hours for each deliverable, and, as I mentioned previously, easier to hand-off or outsource and easier to plan ‘when’ it needs to be done. For example, the project manager could rough the full schedule but just build a detailed schedule for the Car Drawing, 3D Rendering and a first pass at the Prototypes. This is much easier to plan, status and schedule.
Functional Areas are the same, but worse, since most teams then tend to add the phases below each of the business areas. This makes it absolutely impossible to manage a schedule/project.
Improvement #2: Just don’t use Functional Areas in the WBS. Define the deliverable and let the resource assignments show you who is working on what.
Using a Single, Top-Level Deliverable on Level 1 (like ‘Electric Car’ in the WBS examples for Team 1 and Team 2 above) and then listing the deliverables on Level 2.
Improvement #3: Don’t do this. As you have a project with the same name, just show your project summary, and it will do the same thing. It’s ok to have all your high-level deliverables on the top-level since it’s easier to see costs, durations, work, dates, and in the Gantt, it makes for a more pleasant and more easily understood view.
Love Those Deliverables
When we look at the 3rd WBS or Deliverables I feel like Pete Nelson from the show Treehouse Masters and my hands are in the air and magical music is in the air since I’ve found the right selection…ahhhhhhh yes! This has everything we need to build a contract or a SOW, and I could outsource one or all. Once I estimate them, I can clearly see durations and work effort estimates for each, costs for each…I’ve got it all right there.
Having clearly defined deliverables as you see from Team 3 is what you want your teams to strive for when they build their project requirements and project schedule. Once you have this, then it’s much easier to divide them into smaller units, identify owners, and get estimates. This method makes it much more efficient to identify project deliverables, estimate, identify risks and maintain and status a meaningful schedule.
I hope you’re starting to begin to understand how to identify deliverables for your next project or even review a current project schedule and update it. Here’s a checklist with do’s, don’ts and some tips of when to buck the traditional training.
Deliverables Checklist
- Each deliverable is a noun (just like the PMBOK and everyone else says) add the word “the” in front of it to validate
- A Deliverable can be a product, feature, feature set, services, documents, proof of concepts or demos
- Ask yourself if you look at each deliverable, “Could I hand this off or outsource it?”
- Ask yourself if you were paying for all of this, is it defined in a way that you would be able to see progress for each and know if there were variances for the triple constraint.
Non-Traditional Tips (Don’t tell anyone in PMI that I said this!)
- Don’t worry if each of the top-level deliverables does NOT have a single owner, its ok.
- It’s ok if your deliverables overlap or parallel from a ‘date’ perspective but not a ‘scope’.
- It’s ok to have a bunch of top-level deliverables. It makes it much easier to contrast, compare, and inactivate scope
- Don’t worry about your WBS Dictionary at the very beginning. Just like your requirements will evolve in detail, so will your WBS Dictionary (if it’s even required)
- Don’t hold multi-hour meetings to define scope and deliverables. Make them 20 min or less and make them visual. I like using Microsoft OneNote at the beginning since it’s FREE, I can share it in ‘real time’, remote users can update it at the same time and did I mention it’s Free? Then for the 2nd meeting I use the same technique used by one of my heroes; Tony Zink uses Smart Art (Organizational Chart) in Word. Check him out at TonyZink.com
Let me know if you gain any insight from this article
Author Profile
Latest Entries
ConsultingMay 21, 2024Startup Recommendations: Why Use Microsoft Project Online and Office 365
Project OnlineApril 2, 2024The Ultimate Guide: Benefits of Microsoft Project Online for Finance
Project OnlineMarch 30, 2024Benefits of Microsoft Project Online for Resource Managers
PMO RoadmapsMarch 27, 2024The Complete Guide: Unleashing The Benefits Of Microsoft Project Online For Team Members
