A fact that will be inescapably obvious to most who read this is: I’m a consultant. That means a couple of fundamental things. First, unlike employees, I work for a variety of different clients. And very usually, I work for a variety of different clients at the same time. Second, also unlike employees, I need to develop proposals before I usually get that work. Those proposals will include my CV, so that part is similar but they contain a great deal more beyond.
In its simplest terms, a proposal is an audition for the work. Certainly, that it is how I endeavour to approach the process. It’s the first and most prominent way to demonstrate what I do: understand and articular the requirement of my prospective client, engage in critical thinking about how to most appropriately address and respond to their needs, and make a compelling case for doing so. Do that well, and the proposal makes a compelling case for me. The recipient gets to see what I do, the quality of my written work (which is a lot of what I wind up producing) and my responsiveness of doing so.
As you might expect, I’ve written many proposals in my career. The total number would easily run into the hundreds. Some have been long, and some have been short. Some have been a joy to write, and others have been a burden. Some I have been confident of winning, and others I was reasonably certain of losing (but persisted in submitting because if you don’t submit, you can’t win the work). Every once in a while, I’ve been surprised by the result (because I won work I didn’t expect to get, or because I lost work that I assumed I was a shoo-in for).
The more that I write, the better that I get at proposal development – to an extent. I have strategies that allow me to develop a work plan relatively efficiently. I have enough examples and copy that I can often borrow from previous proposals. I’m familiar enough with the the work that I do that I can estimate with a high degree of confidence what it is going to cost and how long it is going to take.
But there are some things that remain challenging, no matter how often I develop a proposal. A big one—and it’s the heart of developing any proposal, and any project plan—is getting getting clear on what the client wants in the first place.
A large part of that is the fact that the client doesn’t always know what they want in the first place. They have ideas, sometimes. Often, what they have are generalized frustrations. Occasionally, that’s accompanied by a belief that “there ought to be a better way to get this done.” This, unfortunately, often turns into a brief google search, attendance at a conference or perusing a magazine article, and phrasing their requirement as, “I want you to do this specific thing for me.”
Most of us can recognize—at least in hindsight—that whatever that specific thing actually was, it’s not likely to solve their problem. It may not even be related to their problem. There may be tenuous, tangential threads that spiral from their problem to the particular thing that they have decided upon, but that at best often serves as an after-the-fact rationalization for why they have chosen the thing.
Digging through and getting sense of problem, requirement, want and need—and sorting out the difference between each of these labels—is the essence of good proposal development. It’s also, if we’re entirely honest about it, what constitutes good consulting. This means that the exercise of defining requirements is focussed on getting a clear enough picture to define the work that will solve their problems and write a proposal for it, not digging all the way through to the other side and doing all of the work even before we get to the proposal.
When I have the opportunity to work with clients in person, this is—or can be—a relatively straightforward exercise. I can have a conversation with them. I can explore their current reality, and I get to both listen to what they say and watch how they say it. I can probe for more details, challenge inconsistencies, question assumptions and facts being taken on blind faith, and generally dig until I’m satisfied I’ve got a relatively clear picture of what is going on.
From there, I can figure out a strategy that makes sense for them. In the context of my approach to consulting, this isn’t about picking standard consulting offering 3a off the shelf, packaging it in a nice shiny proposal, and getting ready to ship it off. It’s about genuinely figuring out where the client is, where they are aspiring to get to, and the solution that will help them move in a positive direction. It’s about designing a path that meaningfully moves them forward from where they are today, but that isn’t so far from their current reality that they can’t see themselves successfully getting there—and being successful as a result.
This is a situation that is complicated significantly once there is a formalized procurement process in place, which is something I’m encountering more and more of late. In these circumstances, a Request for Proposals (RFP)—or sometimes a Request for Information or Request for Quotations—gets assembled and put out to the marketplace. Prospective vendors download these off procurement sites, weigh the pros and cons of responding, and ship off proposals as hopeful entreaties.
The intent behind this process is that it’s transparent and objective, and creates a fair-and-level playing field for all candidates. There are evaluation criteria that are applied, proposals are scored, and an objective decision is arrived at as to who has proposed the best solution. At least, that’s how it works in theory. The reality—as you might guess—is often far more problematic.
Where the problems start with RFPs is pretty much where we came in: with the client understanding what their requirements are. In a formal procurement, this is pretty essential, because that’s what prospective vendors and consultants are responding to. So the expectation is that some time and effort has been expended in exploring and defining requirements, ensuring that they accurately reflect current reality and future aspirations, and expressing them clearly and comprehensively.
The reality is often different. In fact, I’m somewhat famous for responding to RFPs based on the requirements as defined, winning the project, and then leaving the first client meeting with a radically different scope of work to what was actually asked for. Which is theoretically contrary to both the spirit and the intent of the entire procurement process. And yet happens with remarkable frequency.
There are a number of reasons that the clarification of requirements in procurement processes is challenging. For starters, clients are often bad at self-assessing their challenges and issues and objectively identifying what they aren’t doing well. That’s one of the values of having outside consulting expertise; we are able to hold up a mirror to the organization and help them see the clear realities that they are not aware of. That gets messy and complicated when you have to define your requirements before you can engage the consultant that is able to give you a true picture of what’s going on.
A somewhat different but related problem is that clients are very often horrible at simply defining requirements and stopping there. They want to get to solution. They want to define what will address their underlying problem and respond to their requirements. Rather than saying “here’s what’s going on, what solutions do you have that might be useful and helpful to us?” they insist on framing requirements as “this is exactly what we are looking for, expressed in minute detail, and all of it is mandatory.”
Whatever the procurement requires, that’s what you have to respond to, whether or not its what you believe that the client actually needs. You may have an opportunity to express alternative solutions, but the proposal still needs to respond first and foremost to the requirements as stated. And some procurement documents provide no provision whatsoever for suggesting something else.
One of my most significant challenges in requirements-as-expressed-through-procurement-documents, however, is how impenetrably they are often defined. Figuring out what is being asked for is a process somewhere between reading-between-the-lines and reading-the-tea-leaves, in order to divine what is actually being sought. Sometimes this can be the product of unclear thinking. Often it is the result of unclear writing. And sometimes it is the consequence of incoherent organization.
A recent procurement that I responded to (the opportunity was appealing, even if the RFP was not) was an astonishing illustration of all of these things. The requirements (framed as “scope of work”) ran to fifteen pages. This was impressive, mind you; I have also had requirements—for relatively significant engagements—that struggled to extend all the way to a page.
In this particular RFP, the project was initially defined in the introduction. This was elaborated on in the first part of the requirements in a “high-level” scope. Which was followed by a more detailed scope. Which was followed by a set of requirements segmented by the outcomes that they wanted to create. And was further elaborated on in a description of the phases that they wanted to follow.
All of this would have been fine, but for the fact that there was no coherence between how requirements were expressed from one section to another. Different vocabulary and terms were used to describe expectations. Expectations that didn’t exist in one section appeared in a different section, and were framed as being essential, critical and an early priority of the project to do. Requirements of the solution got blended with requirements for the vendor which were further interwoven with requirements for proposals. The overall result felt like a stream-of-conscious meander, one that required an extensive amount of reading and re-reading in order to even begin to articulate a sense of what was required.
A final—but not insignificant—procurement challenge is the question of budget. There are two very different schools of thought on presenting budget as part of a formal procurement; some argue that you should let vendors know your intended budget, so that you don’t get proposals that are beyond affordability. The other argument is that you should keep budget confidential, because otherwise vendors are just going to bid what you’re prepared to spend.
Regardless of whether the budget is disclosed, one always exists. And this is also an area where requirements get massively misunderstood and misrepresented. Rarely, in my experience, is the budget too high. Far more often, it’s woefully inadequate for the scope of work that is being sought.
A favourite recent example was a strategic planning RFP that came across my desk a few weeks ago. The requirements were considerable, and someone had given thought to what they wanted. They weren’t just looking for a workshop with Council, a couple of meetings with administration and a document that they could publish out to the world with the label “Strategic Plan” slapped on the cover.
Instead, they wanted meaningful exploration of current realities and future opportunities. They expected a comprehensive review of current plans and organizational budgets. There would be interviews with senior management and with members of Council. Public consultation was a must, including engagement with residents, business groups and volunteer and service organizations. And they wanted a statistically-valid survey of community sentiments. All of which would serve to drive the coherent definition of future goals, strategies and initiatives to be undertaken by the municipality in the coming years.
If it’s not entirely obvious by now, a scope of work like that is catnip to this particular consultant. This type of consulting can help organizations create meaningful insight, develop compelling stories and build an aspirational vision of the future. I don’t find RFPs like that very often, and when I do they excite the hell out of me. This is the kind of work I love to do, and do very, very well.
Except for on thing. The budget. It wasn’t a big municipality to begin with, so the ambition of the RFP was a little surprising. But for all the positive aspirations expressed in the procurement document, the budget was a sharp lurch back to reality. $20,000 does not get you very far. In fact, it’ll pretty much get you the one-workshop, couple-of-meeting, slap-together-a-document engagement I so very typically avoid. With the level of detailed consultation being sought, a much more realistic budget would have been three or even four times that amount.
And so I live for another week, anticipating the day when I find another procurement that excites me enough to write another proposal. This will happen, of that there is no question. Hopefully when it does, it will clearly define the requirements. It will be open to potential solutions. It will clearly express what is being looked for and why, and will define what matters most in looking for a vendor and solution.
Regardless, I’ll do my utmost to understand, and to interpret and to create and structure a compelling story. Because getting to what matters most is how change happens. And a big part of my value as a consultant is making clear the requirements that my clients often don’t fully see or appreciate.