Defining "Good Enough"

Okay, I lied. I stated in my last post (here) that I was going to move on to a topic different than Scope in my next blog post. Well, I can't quite honor that commitment, at least not yet. The reason for this stubbornness has to do with a conversation I had with a coworker last week. We were, ahem, "vigorously" discussing one of my favorite guiding principles in life and work: "Better is the enemy of good enough." I won't go into the difference of opinion we had about the validity of this adage, but underlying everything we were batting back and forth between us was the definition of "good enough." Let me explain:

You cannot manage a successful project without defining what the actual end goal of that project is. In other words how do you know whether you've succeeded unless you know what you were shooting for in the first place? When exactly have you achieved "good enough" status? Whether you're managing a software develop effort with a small team, writing a manual all by yourself, or overseeing the construction of a major infrastructure project with a large distributed team, you have to define the end goal right up front in the project. I.e., what is it that you are actually tasked with delivering? If you can't completely answer that question, then by definition you're going to fail.

Fine, fine, you say, rolling your eyes. We've talked incessantly about this over the course of the last 5 blog posts. It's all about defining scope, right? How about something new?

Okay, here goes: Defining the scope of a project actually entails more than just breaking down all the work into constituent sub-components and work packages and then adding all these pieces up. Doing this breakdown is vitally important, but it's just the start. Yes, it's an absolutely important start, but there's a lot more work to do up front before the end goal of "good enough" can be targeted. You have to define the requirements of each of the WBS components and sub-components. If you don't do this, then you can't actually know what it is you're tasked with building. Which in turn means you can't accurate schedule, resource, or cost your project. You also can't fully define project risks, nor can you decide on an procurement strategy.

For example, let's say you've been asked to manage a new design-build apartment building project. One of the first things you and your team do is break the project up into its constituent components. For example: land acquisition, permitting, infrastructure improvements, excavation and foundations, structural framing, interior partitions, windows, doors, roofing, insulation, siding, electrical, plumbing, HVAC, fit-and-finish, etc.. These are the key WBS areas that then get further subdivided, along with other important items such as Project Management, Architecture & Engineering, QA/QC, Safety, and so on, of course. We can then break these things down further and further until we're at the lowest work package level. The result of this of course is a WBS that fully details what is to be delivered.

This should be pretty well understood by now, but we're nowhere near finished defining the deliverables of this project. To do that, we have to define the  form, fit, and functional requirements for each one of the individual WBS building blocks. For example, under the category of windows, we can't just say we are going to have 100 windows. We actually need to define just how nice those windows are needed to be. Single pane, double, or triple? Standard sizes and shapes or specials? Aluminum, steel, or wood trim? Off-the-shelf or custom units? Hardware choices? Paint finishes? Inert gas fills? Warranties? Thermal performance? And so on.

Until you define the specific key requirements for each element of the WBS, you cannot accurately cost those elements. Nor can you fully understand the schedule implications of sourcing them, estimate the risks associated with procuring and installing them, decide on the manpower required to install, or even determine if you can get units that match your requirements or not.

In other words, defining scope is not just providing an answer to what and how many, but also answering the equally important question of "how good?"

As a project manager, I fully believe in the adage of "better is the enemy of good enough." I'll discuss this concept in a future post in a lot more detail, but for now just recognize that one of your chief jobs as a project manager is identifying exactly what is "good enough." Doing this step means you know what the end target of the project is supposed to look like and how it's supposed to perform. Failing to do this means you're just shooting in the dark without an actual set of requirements you're supposed to meet.

In the next installment, I'll talk about about something called a V-diagram, and how it can be used to help define all these requirements (as well as test them). Stay tuned...

© Copyright 2014 Mark H.Warner. All rights reserved.