Some Examples of Who
From simple to complex, every project should begin with identifying its key stakeholders...
“[Starting a Project] without the audience in mind is like writing a love letter and addressing it to ‘to whom it may concern.’” — Ken Hamer, AT&T
Over the past couple of months, we’ve looked at the various Initiation/Planning steps of a project. To help clarify and put a bow on all of this, I now want to look at a few examples that illustrate the steps, ranging from the absurdly simple to the highly complex: a) baking a cake; b) writing a book; c) designing a house; and d) constructing a new nuclear power plant.
As we saw, the first step of any project is establishing Who are the stakeholders, especially the so-called “key” stakeholders. Who wants and/or needs this project? Who will use it? Who is paying for it? Who is the customer? Said another way, who has a strong, positive interest in the project, and of these people, which have powerful influence or power of the project? That is to say: Who are we ultimately trying to serve and satisfy with the project?
Example A: Let’s Bake a Cake
Imagine we’ve been asked by a friend to bake them a cake. Before we run out and buy ingredients and start warming up the oven, we need to establish some basic information. First of these is uncovering who the cake is for. Who will eat the cake? Who is paying for the cake? Who wants or needs our cake? If this is an event like a birthday party, who is the host/organizer? What guests will be there?
Taking the time to understand this will help immensely with all the other Initiation/Planning step questions, such as how important this cake is, what type of cake it should be, how we should make it, when it’s needed, and so on. Is this cake for someone’s birthday, a wedding, or a retirement party? Or does our friend just want to eat a cake for no other reason than they’re craving one?
At the heart of these questions is understanding who wants the cake. Is the cake for a child with severe food allergies, a bride and groom with strong “buy local” beliefs, or an elderly relative who loves all things chocolate? And who else will eat the cake at each of those events? We cannot plan the creation of a cake without starting with the fundamental question of who will eat it.
Example B: Let’s Write a Book
If we’re writing a book, we should always start with who we’re writing it for. Who will read and consume the information? A fiction romance novel written for a feel-good seeking homebody will differ greatly from a non-fiction technical how-to book. The same applies to a memoir written for public consumption, or a private collection of diary entries that is intended just for ourselves or close family members.
We can’t write a useful book unless we fully understand who wants/needs it. And we also need to identify other key stakeholders, such as agents, publishers, editors, et al. Who will proofread the book? Are there marketers that have to be consulted with? Booksellers that need to be considered? Will we have a co-author? And so on.
Like the cake example above, to make our book writing project successful, we must start with the book’s stakeholders.
Example C: Let’s Design a House
Like the previous examples, a house design project should always begin with identifying and documenting the key stakeholders. Who is the house for? Is the project to deliver generic tract-housing for a subdivision, or is it a bespoke project for a specific family? We won’t be able to establish even basic things like the size or style of the house until we take this step.
Further, we need to identify other important stakeholders, such as neighbors (e.g., is there a homeowners association with design rules we must abide by) and local government and permitting agencies (that will have their own specific code requirements we must meet). We cannot start the design of the house unless those stakeholders are identified and, later, interviewed and interrogated.
Example D: Let’s Go Nuclear!
Finally, let’s imagine we've been tasked with constructing a new nuclear power plant. While clearly more complex (and serious) than our cake, book, and house examples above, the same basic principles apply. Before we can begin the design of the power plant and build/buy reactor components, we need to establish some fundamental information. Foremost is identifying who the key stakeholders are. Who will benefit from this power plant? Who is funding the project? Who wants or needs this energy source? Which regulatory agencies are involved? What communities will be affected? And on and on and on.
Taking the time to identify the project’s stakeholders will help immensely with all other initiation and planning steps, such as determining the plant's capacity, choosing the reactor technology, deciding on the location, and establishing the project timeline. Is this power plant meant to replace an aging facility, meet growing energy demands, or transition to cleaner energy sources? Or is it a research reactor designed to advance nuclear technology? At the heart of these questions is understanding who wants and needs this power plant.
We cannot plan the construction of a nuclear power plant without starting with the fundamental question of who will be impacted. Is this plant for a rapidly developing region with increasing energy needs, a country aiming to reduce its carbon footprint, or a remote area lacking reliable power? And who else will be affected by the plant's construction and operation? From local communities and environmental groups to regulatory bodies and future plant operators, each stakeholder brings unique perspectives and requirements that must be carefully considered throughout the project lifecycle.
Bonus Example: Inertial Simulator
I’d like to close out this post with a real world example that I was directly involved with. This was the very first project that I was ever put in charge of. Or, I should say, it was a project I had no business being in charge of. See, I’d just graduated with a shiny degree in mechanical engineering and was starting my career as an aerospace design engineer at Lockheed. My boss (who, in hindsight, was an amazing mentor) basically set me up to fail—and learn. He threw me into the deep end of project management and watched me struggle and sink. Let me explain.
The project centered on designing and building an inertial simulator. Imagine an Olympic barbell and weight plates mounted to a vertical shaft that could spin on bearings. The shaft was driven by an electric motor, and rotational position measured by a digital encoder. The purpose of the device was to test satellite control systems. We could bolt on heavy plates to simulate a large satellite, and then see how well a control system could drive, position, stop, and reverse the spinning barbell. We’d then remove weights and test its ability on a smaller simulated satellite.
My boss explained all of this to me in his office (along with some basic engineering criteria)—and then sent me on my way. As a design engineer, I rushed back to my office and begin sketching up ideas—in total isolation. Then I booked a CAD station and went to work fleshing it out. I picked a motor, bearings, encoder, nuts and bolts and so on from a catalog. I designed and analyzed the bar and weight plates and support stand. I even ran a couple of simulations. A few weeks later, I proudly took my design drawings into the boss’ office and showed my work.
He immediately deflated this pumped-up engineer by asking a couple of simple questions: What did the controls engineers think of it? Uh, I didn’t talk to them. Did I consult with the lab manager to ensure the unit would fit in the available space? Uh… What did the safety group think of it? Well… What about the machine shop personnel? And so on.
I got carried away with the excitement of designing something new without first talking to the people that would build it, assemble it, and test it. They were my customers, and I had (stupidly, in hindsight) never really considered their needs. My boss had given me some design parameters, but now I recognize they were just part of the requirements. To really understand the needs of all these people… well, I first had to identify them. And then talk to them. And document their wants, needs, requirements, and constraints.
The Bottom Line:
Stakeholder identification is the first crucial step in initiating and planning any project, as it helps ensure all relevant parties are considered throughout the project lifecycle. Even a simple cake-baking project clearly has stakeholders that must be satisfied. And that means we must first identify those stakeholders. Failing to identify even one key stakeholder until late in the process can have major deleterious effects. You and your team will waste effort, time, and money. You’ll also harm project morale and potentially insult some key stakeholders. Trust me: this is not a good place to find oneself; i.e., with a with a design for a spinning barbell that no one is happy with.