Your Project Descriptions Tell a Story, Just Not the Right One

Pick up the average A/E firm proposal or visit their website, and you'll likely find descriptions of projects the firm has performed. These write-ups tell a story, but rarely about the project. Instead, they tell a story of a profession that tends to sell itself short.

Keep in mind that these project descriptions (or case histories, if you prefer a term that further obscures their value) are intended to impress others, prospective clients in particular. They are offered as evidence of the firm's expertise and experience. From our perspective, they describe solutions we delivered.

But solutions are overrated. An article in MIT Sloan Management Review went so far as to suggest that the term solution should be retired from the business vocabulary. Why? What was "once a meaningful, buyer-defined term that meant 'the answer to my specific problem' is now generic jargon that sellers have co-opted to mean 'the bundle of products and services I want to sell you.'"

Hmmm. Let's examine the typical A/E project description in light of that criticism. What do we find? Not really an answer to a specific problem; the problem is often not even mentioned! Instead we find a description of tasks that were performed, along with some information about the site or facility in question—often expressed in quantitative descriptors such as lineal feet, cubic yards, or gallons per minute. In other words, what might be fairly called a "bundle of services."

What's missing? The results. You don't have a real solution without a favorable result. As Peter Drucker once observed, "What the customer buys and considers value is never a product. It is always utility, that is, what a product or service does for him" (emphasis added). I've probably read thousands of project descriptions over the years, and seldom do I find a meaningful description of project outcomes. Doubt me? Read your firm's project descriptions.

Let me be clear: My real concern is not the quality of our project descriptions. It's what they tell us about our perspective of our work and our understanding of value. Do we want to be known as people who perform technical tasks or who deliver business results? If the latter, then I would suggest that how we describe our work matters. It's an expression of how we think about what we do—and ultimately what we're able to deliver.

Why do we tend to promote tasks over results? I suspect it has to do with our place in the project delivery process. We plan and design facilities; we don't build them. We perform studies and write reports recommending specific actions, but we usually don't implement them. From our perspective, a successful project looks like a completed scope within budget and schedule, especially when we had to overcome some technical challenges.

I'm convinced we need to do a better job connecting our work to its true value—the ultimate client (and societal) outcomes it enables. It's important to recognize when the client realizes the return on investment. It's not when we complete our scope, unless we're involved through construction and startup. It's when our solution begins delivering the results the client needed, often well after we have done our part.

Hence, our project stories need a conclusion—what the project achieved or is intended to accomplish. To better make this connection, I advise using this simple project story spine:

Problem > Consequences > Solution > Results 

Now, this isn't just a literary device to write better descriptions. It's a framework to conceive and deliver better projects. Use this in uncovering needs in the sales process, in writing your proposal, in planning the project, in reviewing project progress, and in evaluating the project's ultimate success. Then, and only then, will you be positioned to write or tell a compelling project story, one that truly attracts the interest of clients.

A few tips:

• Delineate the why behind the project. What does the project need to achieve? This is where your planning needs to begin and where your assessment of success needs to finish. A compelling project story must clearly reveal the project's purpose.

• Define needs at three levels: strategic, technical, and people. This helps you better align your project perspective with the client, for whom the project isn't just a technical scope of work. Identify the client's desired outcomes at the same three levels.

• Don't overlook the consequences of the problem you're solving. In many cases, the consequences—such as budget overruns, delayed project, strained relationship with regulators, a disapproving public, political pressures, disruption of client personal lives—create a greater urgency than the technical problem itself. The greater value is thus in relieving the consequences.

• Develop an integrated solution. This means that your solution incorporates strategic and people elements, not just technical features. Your project story should describe how business value is delivered and people are served.

• Quantify the results to the extent you can. How do you know the project fulfilled its purpose? There should be some objective measures, ideally at the strategic, technical, and people levels.

So what's the story behind your projects? A completed scope or the fulfillment of the client's needs and aspirations? If you're looking for a meaningful differentiator, this is a good place to start. Tell clients not what you've done, but what you've accomplished in strategic and human terms. Then describe how you're going to deliver similar results through their project.