Back to the Future – My Recent Experience Being Transported to a 1980s Proposal Shop




One of my favorite parts of being a consultant is having the opportunity to work with a range of different companies, proposal shops, and even other proposal consultants. This enables me to observe and learn new best practices, work across different fields, and meet a variety of interesting people with an array of backgrounds. However, I am also frequently put into situations where I am reminded of how NOT to do proposals. This week I am sharing with you a recent experience working with a team that has failed to adjust their processes to match current procurement strategies within the federal space.

Note: normally I would avoid sharing such a specific experience as to avoid potential offense, but based on conversations I had with the leadership of this group, this company is acutely aware of the need to adjust their proposal processes.

My Experience Riding in the DeLorian
A few months ago, I was asked to travel to a remote area to support a proposal effort. Always up for a new experience, I packed my bags and was on a plane within a couple of days. However, very little of my experience to date could have prepared me for what I walked into that day. It was as if I had been transported to a time in which I have never lived, but I have heard much about. I walked into a war room full of individuals that had clearly been using the exact same proposal process for the last four decades. You know the one—where 30+ contributors are locked in a room together from 7:00 a.m. to 7:00 p.m., lunch and snacks are brought in daily, each author has a physical folder to track the progress of their sections, edits are made using red line mark-ups post red team, and all formatting and graphics integration are controlled by the desktop publishers.

While I found this archaic process largely inefficient, I did note some positive features as well. So I’ve outlined the key elements of this process below, highlighting major pros and cons of each.

Where the Team Could Largely Improve
Working in a remote location. The key benefit of flying contributors to a remote area is that it forces the team to focus on proposal development. While in this remote war room, there was no such thing as a day job. Contributors were 100% focused on the proposal. The team was also less inclined to leave early. This is because there was not much to do in the town, and there were no distractions from friends and family. The biggest disadvantage? The travel costs. My recommendation? Keep the core team collocated, fly in key contributors if necessary, and allow other team members to contribute virtually.  

Collocated team. Having everyone collocated fosters in-person collaboration among contributors and encourages asking questions face-to-face rather than relying on email or telephone correspondence. But it also fosters germ and virus sharing. Since no dial in numbers were provided for meetings, individuals would show up in person, even when under the weather. And because we were in such close quarters, when one person got sick, all the other team members got sick as well. Despite the associated travel costs for geographically dispersed team members, I’m a huge fan of collocation when practical. But I also encourage virtual options to make some remote work possible.

Large, dedicated team. There were roughly 30 contributors for this proposal effort. Was this a huge proposal response? Several hundred pages? Nope! It was a 50-page response. For today’s standards, this proposal team was grossly overstaffed. However, since it was such an inefficient process, the company needed to have significantly more resources than more modern processes require. For the more standard proposal process that we see today, we could have easily developed and produced this response with about 1/3 of the resources.

Lunch and snacks were brought in. This team was still holding on strong to the old tradition of providing daily lunches and snacks in the war room. This had both positive and negative effects. Providing lunch and snacks kept contributors on site and fueled throughout the day. However, because contributors were not taking lunch and other breaks, they were likely less productive overall.

Working such long hours—7:00 a.m. to 7:00 p.m., 7-days a week—actually makes contributors less efficient and effective. This is because humans are simply not wired to work for such long durations without breaks. After about an hour or so, our productivity starts to wane. My vote on the issue? While I think bringing in lunch every day is excessive, I encourage providing snacks, allowing lunch breaks, and springing for dinner when you keep the team late. These are all easy ways to foster improved productivity while showing that you appreciate the team’s time and hard work.

Each author had a physical section folder. For tactile individuals, this physical folder structure can be a helpful process. But with the proposal collaboration tools available today, this folder structure is established electronically, versions are automatically tracked, everyone has access to other proposal sections, and the entire team has visibility into the status and the workflow. In addition to saving time and money, these tools support consistency across sections because authors can easily read other sections. With the physical folder structure, too often authors find themselves working in silos. There is a clear reason why most organizations switched to online proposal workspaces years ago.

Red team was conducted on hard copies. Hard copy red teams were being phased out when I first entered the proposal field. Today’s processes have largely moved away from this practice because conducting reviews using modern tools allows reviewers to simultaneously make comments on the same document. This creates one document that incorporates all reviewer comments without any extra steps. This saves so much time and effort for the proposal manager, proposal coordinator, and proposal authors. Because the benefits are so clear, I have long been a proponent of electronic reviews.

Edits were made using red line mark-ups post red team, and the desktop publishing (DTP) team implemented the changes. Because of the clear inefficiencies of the practice, I have never been a proponent of hand-written red lines at any phase in the proposal process. However, I do not have a problem with turning version control over to production at a certain point in the process. Once a document has gone through an edit and/or solid DTP cleanup, it is still common to keep version control with the DTP/production team. But, in today’s best practices, it is more common for this edit and clean-up to happen after red team recovery and before the gold team. Gold team comments are then collected electronically on a frozen document, and the production team integrates the changes to maintain the integrity of the formatting. This creates obvious efficiencies because red team recovery revisions can be made directly into the section templates. It also prevents incorrect edits because typed changes are much easier to read than written ones.

The proposal was formatted using InDesign. This proposal team used InDesign to format the proposal because the program provides much more control over things like kerning, tracking, and leading. But this DTP team ignored all concepts of visual appeal to jam as much content onto a page as possible—creating blankets of text with virtually no whitespace to break up the narrative. This not only made the proposal ugly, it made it extremely difficult to read. It would be hard for evaluators to not let this negative impression affect their score of the proposal.
What’s more, because this team used InDesign, graphics were developed 100% separately from the text. So it ended up being a guessing game as to whether each author had written just enough, too much, or not enough text for each section. Today’s processes largely use Microsoft Word to format proposals from the start using templates designed to the RFP’s font and formatting requirements. This creates greater efficiencies because: 1) each author can largely tell whether they have written too much content; 2) graphics can be integrated into the text more seamlessly, again, helping understand page targets from the start. Not only are most government customers today requesting the soft copies to be in Microsoft Word, many government customers have been catching on to the spacing shenanigans, so more and more RFPs are now forbidding adjustments to these advanced formatting elements.

What the Team Did Well
Despite all the areas this team had for improvement, this team also had many areas where they excelled:

Visual status of the proposal progress was readily available on the war room walls. Because everyone was collocated, the war room wall was an effective way to communicate the up-to-date status of each piece of the proposal. Whether physically displaying this on the wall, or displaying it electronically using collaboration software, I am a huge proponent of this practice. Read more on how this practice aligns with some of my recommended Agile tools for proposals.

The contributions of the team and the reviewers were clearly articulated and reinforced by corporate leadership. Following the red team, the president of the company spoke the team, genuinely thanked us, and explained how important the work this proposal was for the community where it was to be performed. He put into clear perspective how many lives would be impacted by the work. It was a very powerful message—and a very strong motivator for the team. I have found that we don’t see this level of perspective articulated as frequently in today’s market. This message is too often lost in the daily grind of the business. If you’re a regular reader of this blog, you’ll know I am a huge advocate of contextualizing the contributions of the proposal team.

The proposal manager kept things interesting. The proposal manager mixed things up by having a daily safety topic, which broke up the monotony of the proposal status update. The safety content shared each day was quite informative and generally interesting. In addition to this structured diversion, we also had one seasoned contributor who would bring levity to the stand-up meeting by including a cheesy joke along with his proposal section status. This habit of keeping things interesting is another best practice of for which I am a huge advocate. 


Back to the Future
Now I know the proposal process that I just described was popular in the heyday of proposals—when teams started working long before the RFP was released, and RFP turnarounds were at least 60 days. However, much of the proposal industry started moving away from this paper-based process years ago. When I entered the industry in 2007, I saw glimpses of this process still hanging on—and over the first few years of my career, I watched as most of these practices were slowly phased out.
At the start of my career, while most shops had started using SharePoint, Privia, or other similar proposal collaboration tools, many proposal shops were still managing graphics using physical folders. But by 2014, I stopped seeing physical folders used completely. Why? Because it’s simply inefficient. Using collaborative software to manage the graphics in, graphics out, and graphics updates processes not only saves time, it also seamlessly leaves a trail of requested changes and prevents the panic of—gasp—a folder getting lost.

So why had this team held on so strongly to a process that so many others abandoned years ago? I suspect that it had to do with the organization’s main customer. Up until recently, this particular government customer still had the same old Contracting Officers, issuing RFPs under the same old acquisition strategy. They were still releasing RFPs with very large page counts, long draft RFP stages, and 60+-day turnaround times. So, other than cost savings, there was really no benefit to this company of changing their process.

However, today this government customer has younger Contracting Officers who are implementing more agile procurement strategies. And the old process just doesn’t cut it for this type of RFP. So now, years after so many of us have phased in these changes—this company has learned that it’s time to make some major adjustments.

What the Past has Taught us About the Present and Vice Versa
Though I think we can pretty much all agree that this company will benefit greatly from adopting the best practices of today, there is still much that the company can leverage from its old processes. And as outsiders looking in, we too can learn from this little trip back in time. We can learn from the careful status tracking and information sharing of the past and make sure we are vigilant in maintaining visibility to these statuses. We can learn from the benefits of committed senior leadership and the positive impacts they bring when they clearly contextualize the contributions for the team. We are also reminded of the collaborative benefits of having a dedicated and largely collocated team. And finally, we are reminded to mix things up and try to keep things interesting for the team.

Written by Ashley Kayes, CP APMP
Senior Proposal Consultant, AOC Key Solutions, Inc. (KSI)

Comments

Popular posts from this blog

Why the Proposal Process has Always Been Agile

6 Strategies To Tackle Tight Page Limitations

An Open Letter to the Friends and Families of Proposal Professionals