A Five Minute Read
In this post, I wrote about using objectives to free up our brains to better respond to customer needs and give employees more opportunities to act creatively and achieve the operation’s goals.
It’s not just “people leaders” that gain from defining measurable results and benefits before taking Action. Project Managers and Business Process Managers profit just as much – more, probably – from asking themselves, “What Is Your Objective”?
Setting clear objectives at the start of a project is perhaps the most crucial, and most often overlooked, step. Defining and agreeing on clear results is like getting the answers to the final in advance. If the PM and the sponsor concur on the measures of success before beginning, the project team can focus its energies on actually accomplishing its goals and less on politics. There’s no end-of-project debate.
Clear objectives help maintain scope. When defining work, or when others want to include certain activities in a project, good project managers ask: “What’s your objective?”
If the proposed task’s objectives don’t match the project’s (already-stipulated) objectives, then it doesn’t belong in the project. (A corollary question: “How does this work accomplish the project’s objectives?” serves the same purpose).
Good objectives focus on the reasons behind doing the project, not re-stating the project (see “The Cocktail Party Test”, below) or dictating how you will do it. They should answer the question, “Why are we doing this project? What do we hope to achieve?”
Here’s Test for Good Project Objectives.
I call this the “Cocktail Party Test.”
Presume you’re at a cocktail party hosted by your significant other’s boss. You need to be impressive – not just to come across as a Man of Action, but also so your partner looks smart for choosing you. Between bacon-wrapped scallops, you’re asked an innocent question such as, “What are you working on?” and its “Hm. Why are you doing that?”
If you can answer “Why are you doing that?” intelligently and succinctly, you probably have decent objectives. If your reply is vague or chases its own tail, well, you’ll be embarrassed both at the party and when you ask for your bonus.
For instance, if your project charter is “Install Dynamic Cutter Heads on Frangible Boundaries” and you are asked, “Oh! Why are you doing that?”, you wouldn’t answer “Because we want to install dynamic cutter heads.” That’s what you’re doing, not why you’re doing it. Restating the project does not a good objective make.
Likewise, you wouldn’t answer, “Because we want to pour 24 concrete piers and mount ‘black’ carbon rebar”. That’s how you’re doing the work.
You would answer with the benefits of the project. “Because we want to be able to align cutting pressure with the brittleness of the ground”, “Because we want to improve our load efficiency by 20 percent”, etc. Those are the objectives. Now you’ve passed the Cocktail Party Test.
Setting clear objectives – and communicating them – in business process improvement is just as critical. The design team needs to understand what the process is trying to accomplish, in terms of results, not outputs. By focusing on “results” or “benefits”, the team has greater possibilities at their disposal.
Dictating an output at the start means the process will deliver, well, that output. (Think about a report-generating process. Setting objectives around paper size and distribution locks the team into creating printouts. What are the real results being chased? Something along the lines of “Communicating performance information”, “Maintaining a record of production”, most likely. Now the design team can explore other ways of sharing data – websites, dashboards, text alerts, and more.)
Good business processes are adaptable. Someone following a process can only be a Man of Action if she can adjust how she delivers results, based on customer needs. If she understands the process objectives, she can adapt to the customer and maintain process integrity. Communicate the process objectives! Otherwise, her options are to make something up (satisfying the customer, but failing the process) or to follow a checklist (likely failing the customer).
Here’s a Test for Good Process Objectives.
I call this the “Lil Test.”
Lil worked the factory floor, and she was, to put it politely, “a piece of work.” She showed up to do her job, full stop. She learned that job 30 years ago, and so that’s what she does. If you want to try something new (even in beta), if you want to introduce any change onto the shop floor, you need to get it past Lil. Who does not suffer fools lightly. Presume, when you are introducing a new process, you have to get Lil on board. The first thing she is going to say to you is, “I’ve been doing it like this for years. Why do I need to do it any differently?”
If you can give Lil a rational and intelligent answer to “Why do I need to do it any differently?”, you probably have decent objectives. If your reply is vague, or you end with something like, “Because I said so,” well, you will probably not get a whole lot of implementing done.
For instance, suppose you say to Lil, “I only want you to produce enough product to fill these two bins. When they’re full, stop and wait for the next department to swap out with an empty bin.” For years, she has been told to fire up her machine at the start of her shift and keep going until she runs out of material or the whistle blows.
“Why do you want me to do that? You’re paying me to not produce?”
Acceptable answers would include, “We want to make sure that we don’t make more than the packaging department can handle,” or “We want to be able to change out between different jobs, and this should help”. (In other words, “Our objectives are to minimize WIP and to maximize production flexibility.)
If you can’t pass the Lil Test, you probably don’t understand what you’re trying to accomplish, and you probably shouldn’t be implementing it.
No one should do work for the sake of doing work, either in process or in projects. Work should achieve something, some measurable value. Taking time up front to define that value saves effort over the long run, as teams now know where to focus; they can tailor how they do the work because they know why it needs to be done.