BuiltEnvironment

When being selective about pursuits seems to backfire

Sometimes you have to pursue a project you really don't want to win.

REALLY!

My employer was a large national A/E firm. I worked in their Dallas office. One day, our municipal engineering department manager brought me an RFP from Dallas Water Utilities (DWU).

"I need you to write a good proposal, but not a great one," he said. "We don't want to win this project."

"Why not?" I asked.

"It's going to be very controversial, for a number of reasons, and we just don't want the firm name associated with the project," he said.

"Really?" I asked. "So why are we submitting on this one?"

"DWU is kind of funny about the RFP it issues. If we don't submit on a project when they know we can do the work, they might decide to act as if we no longer want to work on any projects with them."

I wasn't sure whether or not I believed this. Maybe it was something one of our guys heard someone say when he was wandering the halls at the City's engineering office. It certainly couldn't be anything official, I thought.

Anyway, I wrote the proposal. I made sure we we gave them our "B" team of technical staff and a group of projects that were relevant but not overly impressive. In other words, what I wrote was solid, but there was no "WOW!" factor.

And just our luck, we were short-listed.

The department manager commiserated with me. "Don't worry," he said. "We'll do an adequate presentation, but we'll make sure there's no "WOW!" factor."

So we put together a very "Plain Jane" slide show and presentation script, with a project approach guaranteed to raise no eyebrows--in other words, a presentation that would be standard current practice, and showing no great innovation.

Since I'm not an engineer, I have no idea just how bad the presentations of the other short-listed firms were. I only know that with no creativity or innovation in our project approach, and presenting only our "B" team--and despite my very best efforts NOT to impress--DWU selected our team to do the project.

We negotiated in good faith, and signed a contract with DWU. Now we were just waiting for Notice to Proceed.

Finally, we DID get lucky!

Before Notice to Proceed was ever issued, the City decided to shelve the project. I don't remember why. So the project never happened and our firm didn't have to get involved in what we really believed was going to be a local tempest in teapot.

Unfortunately, the municipal engineering manager wouldn't request a debrief. I was not a happy camper. I really wanted to know what the other short-listed firms had done in their proposals and their presentations that left us on top despite our best effort to not impress.

On the whole, though, I didn't complain. We won a project we didn't want to win, but the client ended up canceling the project.

Maybe it was KARMA!

Text Libraries -- Yes or No?

As we are all aware, "text library" is just another name for "boilerplate or database," information written at some time in the past for another use and now repurposed for a current pursuit. Personally, I have a few problems with the use of such a resource.

1. Knowing these libraries exist can lead to procrastination of proposal teams, or of firms making the actual Go/No Go decision, because they feel a good portion of the proposal text is already written.
2. Believing that significant portions of the text are already written may convince people to submit on opportunities that really should be a No Go for their firm because they believe the cost of (and therefore the loss due to) the effort is lower.
3. People may forget to "search and replace," so you run the risk that a section of your new proposal may reference the wrong client name, location, or project being pursued.
4. People may forget that even when you select material from the text library, you still have to edit the text to be completely responsive to the RFP. Many a submittal has been tossed because the team missed answering some questions that were not asked in the previous RFP.
5. As your text library expands, even if you have time to reorganize and update whenever needed, that library gets more and more difficult to use, especially for newcomers to the firm's marketing staff, because there is just too much similar information. 
6. People may throw in "everything, including the kitchen sink" because the material already exists, rather than limiting themselves to just what the RFP asks for, which can make the required information more difficult for the selection team to find, or give the committee the feeling that your proposal is non-responsive.

In the early 1990s, I worked in the branch office of a large, national A/E firm that had just purchased Oracle for use as a marketing database. The principal in my office was very much of the "don't give them any information they didn't ask for" school of proposal writing. However, the corporate headquarters marketing staff seemed to believe in the philosophy of "never give a man 10 pages when you can give him 110 pages." So they used a lot of information, especially resumes, exactly as they came out of Oracle, with no tailoring. One proposal that included resumes of only six people, had a staffing section of more than 75 pages (i.e. they included the firm's senior electrical engineer, with his complete 17-page resume).

In another instance, a potential client asked about our transportation capabilities. Because the client never specified a transportation mode, headquarters marketing staff included project descriptions for municipal roads, state and US highways, airports, light and heavy rail, and bridges -- and included a full dozen project descriptions for each.

We used to joke that clients didn't READ proposals or SOQs; they WEIGHED them! Whether you call the resource a text library, a database, or boilerplate, this capability to store and retrieve virtually endless amounts of information has made it possible to produce huge documents full of material that wasn't requested, in amounts sure to make the client put the document down and go on to the next submittal.

Please be aware that I'm not saying that these information repositories are not useful and beneficial, because they can be. But I do recommend that firms establish "rules" or "guidelines" for their use.

Company standard for client interaction

Let's say yours is an A/E firm with headquarters in Dallas, Texas, with six additional offices across the Southwest — Austin and Houston, Texas; Oklahoma City and Tulsa, Oklahoma; Albuquerque, New Mexico; and Phoenix, Arizona. One of your primary market sectors is land development, especially large, mixed-use residential communities. One of your biggest land development clients has offices and projects in every city where you have offices. So their local staff members deal with your local staff members in every one of your offices. Your Texas and Arizona offices each have multiple projects with the client. Your Oklahoma and New Mexico offices each have one project with the client. This client is responsible for almost 10% of your firm's total revenues. 

One morning, the president of your firm gets a somewhat disturbing phone call. It seems that some of the client's Dallas folks had occasion to visit your New Mexico office. Since they only had one small project with your Albuquerque staff, they were treated in a relatively cavalier manner—some staff couldn't take time to speak with them, people kept moving in and out of the meeting, people took personal phone calls, etc.—as if your Albuquerque folks didn't recognize the client's importance to your firm's bottom line.

As a matter of fact, they DIDN'T recognize the client's importance to the firm.

Part of this could be traced back to the information corporate thought appropriate to share with staff and the specific individuals to whom corporate shared that information. Part of it had to do with the social dynamics—the way business was done—prevalent in each city. Part of it may have been due to your accounting system, which treated each of the client's seven offices as separate, individual clients, never aggregating their business into one total number that reflected their importance to your bottom line.

And part of it came from staff in all seven offices NOT realizing that they were ALL ONE COMPANY! This is something that often happens, especially with growing companies. They don't realize that, consciously or unconsciously, they are encouraging offices to compete with each other rather than with the other firms in their market.

The overall solution to this challenge is to manage client interactions across services, departments, divisions, and offices. To have a set of standards for client interaction that can respond to the social dynamics of each city where you have an office, while maintaining the minimum level of knowledge, interest, courtesy, and respect for the client. Just like you have one set of CAD standards that all offices follow, so they can share work when workloads dictate.

In other words, TO BECOME ONE COMPANY.

Regardless of the physical or financial size of the client, the number of projects it has with each of your offices, or the percent of your firm's bottom line for which that client is responsible, there must be a minimum standard of behavior, a FIRM way of doing things, despite the local social dynamic of how business is conducted. You want to make sure that client staff can expect to be treated the same way no matter which of your offices they visit and no matter which of their offices they are from. Just like you want them to expect the same quality of work no matter which office is doing a project for them.

Differentiators and the client’s need

When I look at a firm's website and proposals, I always look to see what the firm considers its differentiators to be. I think of an informal study I did a few years ago, where I took a detailed look at the websites of the first 10 large A/E firms I could think of to see how their websites differed from each other. I found that while colors changed dramatically and layout changed somewhat, all 10 sites had the same navigation buttons and listed the firm's differentiators. And in all 10 cases, most of the listed differentiators also appeared on the lists of at least half of the other firms.

In one case, the website actually had a navigation button labeled "Why we're different," but like the other websites, the list that came up included items that were on at least half of the other firms' lists.

A differentiator IS NOT what makes you different from SOME of your competitors; it's not even what makes you different from MOST of your competitors. It's what makes you different from ALL of your competitors. It can be one specific service, or a specific combination of services. But none of your competitors should be able to make the same claim.

In other words, a differentiator should be what makes you UNIQUE, what makes you UNLIKE any other firm. It's something you can say about your firm that NO OTHER FIRM can say.

One thing that can give you a leg up in attracting new business through your website or winning new work through your proposals and Statements of Qualifications is your ability to identify, articulate, and then capitalize on your firm's true differentiators.

So you need to figure out what your true differentiators are. The following ten questions should help:

1. What does my firm do?
2. What does my firm do well?
3. What does my firm do well enough to be recognized for by past, current, and potential clients?
4. What does my firm do well enough to be recognized for by our major competitors?
5. What do our clients think we do better than other professional services firms they have used?
6. What do our usual subconsultants think we do better than other prime firms with whom they work?
7. Based on our reputation, what services would our clients pay a premium price to access? 
8. What do the public agencies who have to approve our work think we do better than other professional services firms?
9. What do we do so well that our staff are considered to be thought leaders?
10. What subjects does a local newspaper, magazine, or business publication call us for when they need a quote or a non-technical explanation of a technical concept?

It doesn't matter how many true differentiators you can identify. If you have 10, that's great. If you only have three, that's great, too. As long as you have some attribute or achievement you can claim that no other firm can.

Then, keep the list visible when you start writing or designing your proposal and/or website content. Because making your firm's true differentiators relevant to a prospective client's needs and/or RFP is a sure way to win new clients for your firm and to win new business from past and existing clients.

Preparation is everything!

More than 20 years ago, the small M/WBE/8(a) firm I worked for joined a proposal team with SAIC (Science Applications International Corporation). It was during that effort that I first heard the phrase "frontloading the agony." The phrase was used by SAIC staff to advise team members that we should always start our proposal process by determine everything that would be needed for the effort at the beginning, that the long-lead-time items should be identified and started or ordered immediately, and that short-cuts in the early stages of the proposal or project planning process could be counted on to come back later and bite the team in a most inconvenient place.

Bringing all these large and small process details into focus during the earliest stages of proposal execution minimized the potential for unhappy surprises later in the proposal pursuit and then in the actual project progress. Examples of this might include:

On the staffing side, you don't want to develop an organization chart and start writing a staffing section for your proposal, only to discover that some of the people on the chart are no longer employed (more likely to happen in larger firms with staff in multiple offices), or that the person you want to lead the technical effort will be on vacation the two weeks before the proposal due date. You also don't want to assemble your exemplary projects and write about how they relate specifically to this new pursuit, only to discover that some of those projects have a clause in their contract prohibiting your firm from using that client's project(s) in your marketing efforts. (I have actually had this happen to me on one occasion!)

In addition, you don't want to develop a project schedule for inclusion in your submittal without finding out first whether or not you will need permits, from what jurisdictions, how long such permit acquisitions are likely to take, and whether such a project will require expensive and time-consuming environmental studies. And you don't want to approve the design of a beautiful building entrance and lobby using the highest grade Italian Carrara marble without being able to justify the cost over that of more local supplies, or the amount of time it will take for your order to be processed, executed, and delivered.

The final take-away from this was that a proposal team should not do things in the order of the document's Table of Contents, but should identify those things that would take the most time and get those tasks started right away. For example, lots of work can be done while you are waiting for your permit(s) to be approved. But if you wait until late in the process to apply for such permit(s), your proposal or project effort could suffer unwanted downtime in the final stages, waiting for permits or approvals to arrive.

"Frontloading the agony"—taking care of all those (sometimes annoying) details before they turn into crises or proposal/project killers.