What is the difference between Smart Goals and Deliverables?

Question

I understand that deliverables are tangible outcomes while goals are generic. But when we craft SMART goals they sometimes resemble deliverables. I am not able to get my head around separating SMART goals and deliverables sometimes. It becomes very confusing to differentiate whether this is a goal or a deliverable. For example: we want to reduce a waiting time in queue of theatre's canteen. Now this is a simple goal. But when I say by end of q2, I want to reduce waiting time by 2 mins per person then this becomes SMART goal. Then what would be a deliverable over here? A happy customer which may find from the feedback? I think 2 mins reduction is itself a tangible outcome while what I mentioned above is something subjective outcome?

Answer 1

A deliverable is a contractual item, whether it is a formal contract between a buyer and seller or simply a promise of a product or service delivery. A goal can become a deliverable by simply putting the goal under contract. However, the taxonomy I prefer is: Goal (an abstract, strategic thing for which we are trying to head) leads to Objective (a more concrete, specific, measurable, and tactical thing we work towards that will help achieve that goal) leads to Deliverable (a contractual promise that is a tangible product or service that, when delivered, will help achieve the measurable objective that, when achieved, will help us inch closer to the goal).

This is the mental model I use to help break down a mission from something that is abstract and strategic to something more tactical and measurable.

EDIT: Using your comment as an example:

Goal: Increase profit by 30% in five years;

Objective: Increase profit (Specific, Relevant to the goal) this fiscal year-end (Time) by 10% (Measurable, Attainable) (I would apply the SMART acronym to the objective. It can also be applied to the goal but I personally am okay with the goal being more ambiguous. My personal opinion.);

Deliverable: Introduce xyz functionality to ABC system / capability.

Answer 2

SMART and WBS/deliverables are two different analytical frameworks. It is like asking whether my daughter is a female or a relative.

• SMART is (IMO) a quality standard for goals (SMART goals are better than simple velliative goals).

• Deliverables are a WBS tool; as far as I know there is no formal theory underlying deliverables. There are a variety of heuristics, but not formal quality standard. Deliverables are usually empirical and value driven.

Applying SMART to deliverables may help you to refine bad deliverables and clarify your project plan, but frequently top level deliverables are not Specific, assignable. Frequently they are empirical rather than measurable. As you descend the WBS, the probability of accountability/assignability etc. increases

OP asks if applying SMART to deliverables wouldn't make them value driven - might happen; sometimes when I want to understand my daughter I have to think of her as a female. Sometimes that helps. But value is not a SMART criteria. I just sat through a briefing on our new status dashboard that includes boatloads of very lovely professional pictures that are SMRT. They are appropriately specific, very measurable, unquestionably realistic and quite timebound. The designers think that they are actionable, because they are built on underlying data. But the data doesn't allow anyone to make a decision or to advance the organization's mission. The tragic flaw is that for the graphic designer, this is a deliverable, but for the organization, it provides no value. This is a failure of the project manager to develop and maintain a high quality plan and to continuously enforce quality on deliverables. We should have curtailed this effort when we realized that the developers/designers were creeping scope upward because they could.

Aside: I'm afraid that I'm unclear above because I can't really discuss customer data. Let me offer a metaphor (noting Box's Rule) Imagine that you're looking at a dashboard of my health and you notice that high cholesterol has been a finding for 19 of the last 20 years and dropped off the dashboard this past year. It would be tempting to make the conclusion that cholesterol has improved and we should stop prescribing the statin used to control the cholesterol. But what actually happened is that the cholesterol test requires a blood draw and we stopped doing the blood draw during COVID. The dashboard designer delivered the product, and from that perspective, they've achieved a SMART goal. But the value to the customer is the ability to manage health risks, and that goal isn't being met. The deliverable is "Reduce risk of a heart attack."

Several other other related concepts/frameworks for analysis that may help with perspective.

• value engineering (that's an adequate link, but I'm sure someone can suggest a better one). I'd suggest applying value engineering to your deliverables as a tool to refine them. Make sure that the deliverable has value to your enterprise. Understand the value of that deliverable. Refine the deliverable so that it is as abstract as possible, but no more abstract, and then break down the WBS so that every WBS reifies the deliverable
• Polishing chrome (can't find a good link), which references continuously improving something that has already passed the point of diminishing marginal returns.
• in software and security , "security capabilities" (particularly when compared to "security controls") that represent a desired outcome. At least to me, "capabilities" are similar to "Deliverables" (unfortunately, they are also similarly recondite and abstract) They are both related to Terminal Objectives; the ability to do something in some context, without reference to a standard.
• Various PMI discussions about the distinction between quality and suitability

All of the above are different lenses/analytical tools you can use to refine your deliverables/your WBS to improve the quality and improve the chance that you'll close the project within the constraints of scope/schedule/quality. Not all of them will apply to all environments/domains.

Take, just as an example, assignability/accountability. High level WBS items (e.g. 1.x), will have very low accountability because they require cooperation from multiple teams - as you decompose the deliverable into lower level WBS (1.1.x, etc.) specificity and assignability will increase. That doesn't mean the WBS 1.x is lower quality. That's the wrong analytical framework to appply.

(sorry - somewhat incoherently dashed off because I keep getting interrupted by things that people pay me for.)

Answer 3

To echo the above:

• A "goal" is exactly that – a goal. All planning needs to lead "from goal to goal," and then to periodically produce "deliverables."

• A "deliverable" is a contractual, binding obligation. Articulation of such a thing demands not only rigid specification of the "final state," but also a consideration of contingencies – "what might go wrong and what we'll do about it."

• From a software perspective, a deliverable is "something that will be put into actual service, in front of paying customers, and which must deliver satisfactory performance and results to them 'from this point forward' until it is superseded.

• "S.M.A.R.T" is a clever-and-marketable acronym for key points that any "goal" ought to have, in order to help you create better and more-actionable goals. It's cute, "it has a nice ring to it," and each letter really does correspond to a useful metric which will help to "hammer down" the goal into something that isn't pie-in-the-sky but instead can actually lead to deliverables.