Project Management Institute

Interaction between sales, delivery and business functions during the proposal stage

Lenora Young, Director of ASP and International Operations for SupplyAccess, Inc.

Since this is being written from a Delivery perspective, I will say those of us who partner with representatives from the Sales and Business functions—on bid and proposal initiatives—probably experience a gamut of attitudes and emotions. I have a great deal of admiration for anyone who must start the day, knowing they have to make decisions that impact whether or not their business function will survive and flourish. I respect those individuals who can live with a hard and fast sales quota to meet, in order to retain their monthly draw, but have to face rejection on an ongoing basis. Conversely, when any of these individuals ask, “What comes first, implementation or testing?” or “Why do we need a Project Manager—they cost too much?” I am frequently bemused, or worse, depending upon the manner in which the question is posed.

As a vendor—a seller of services, I will say in all candor—much about responding to the proposal process is frustrating. A prospective customer issues a request for a proposal, and once received, a vendor will spend many weeks or days creating a carefully thought out, qualitative and quantitative response. Despite all due diligence, the end result may or may not achieve the desired result. If the work is not won, it may appear that the seller has just engaged in an exercise in wasted time and effort; time and effort that could have been spent elsewhere, on other initiatives.

However, as a former Information Technology manager in a large corporation—a buyer of professional services—I must admit, the process is equally challenging. The buyer has to spend a great deal of time and effort, articulating requirements on paper. In addition, the buyer must formulate fair and impartial selection criteria, designed to hold up under intense internal scrutiny. Furthermore, the request for a proposal must be written such that a wide audience understands the contents. Please keep in mind, that buyers must live with the results of their decision. A buyer's ultimate success is tied to a vendor's ability to deliver what is requested, and add value along the way.

In many respects, this two-sided perspective has made it easier for me to be involved in the proposal effort, and to navigate around the highs and the lows of the proposal process. Seeing both sides is a great equalizer. In the long run, no well-thought-out response to a proposal is really wasted, whether one wins or not. Assuming a solid, rationale process is followed, everyone on the team gains perspective, experience, and ultimately, wisdom. The key to an effective learning experience is, of course, to continually reinforce the roles and responsibilities of each member of the proposal team. Secondarily, it is important to identify the key deliverables and activities—as well as, the interactions—required of each team member. Of course, it goes without saying that it is important to make certain the final product is on point, addresses all of the questions in the proposal request, and demonstrates a clearly articulated value proposition and market savvy.

If all three functions—sales, delivery and business—contribute to the process, observe their roles and responsibilities, and leverage their knowledge and experience, they have gained invaluable experience. A distinct division of labor will prevent the tendency some of us have to respond to proposals without the intervention of the sales or business functions.

I have, from time to time, had this tendency. After all, the nexus of many proposals relates more to the actual delivery aspects of a project, than it does to the sales and business functions. For example, why involve the Sales function? Delivery, after all, comprehends the methodology, understands the requirements, and determines the staffing and skill mix. Delivery also provides an estimate for the project duration. All of this, of course, feeds into the costing model. Isn't a response from Delivery enough?

And why involve the Business function? Is a business review really required? Odds are, probably not. After all, Delivery certainly understands the required profitability percentages, branch contribution margins, hidden costs, and factors all of this into the costing model. An individual experienced in Delivery has probably written so many comprehensive and thorough “Statements of Work” they anticipate any and all constructive criticism and formulate mitigation strategies before anyone else manages to articulate their concerns.

I have embraced these prevailing attitudes for much of my career. Yet, I finally realized, after a number of years of working on proposals and winning and losing a number of them, when all is said and done, teaming results in a better product. While I did indeed provide the delivery and project management rigor, which is what I often refer to as the scientific foundation—it was Sales who made sure I didn't waste my time on unqualified prospects. Sales also helped me develop a more artistic approach to the presentation. And it was Business that provided clarity on the company, on the whys and wherefores of the financial model, and offered additional review points. Business also caught many subtle errors or omissions, which I wouldn't have caught until I was halfway through the project model I had created.

Thankfully, most corporations have enough sanctions built into the process to prevent any one function from going it alone. Because of this, I finally came to realize any effort containing combined and differing agendas, multiple business cultures— and requiring multiple skill mixes—should indeed be addressed by a joint effort between the Sales, Business, and Delivery functions. The experience may make for frayed nerves here and there, but it's worth it in the long run. The process really does result in a compelling, articulate, and comprehensive response—one that will either win the work—or sufficiently position your company, for future initiatives.

What follows, then, is a model for responding to proposals; one that requires the participation and intervention of the Sales, Business, and Delivery functions. The model is designed to work from the seller's perspective—the primary objective being to design, develop, and deliver a proposal to a prospective customer.

Sales

On balance, the Sales function is generally the first to receive a request for a proposal from a prospective customer. This is generally a direct result of their sales effort. They are, after all, the function responsible for prospecting potential customers, and for identifying whether or not a business relationship makes sense. The Sales function addresses many of the following questions: Is the prospective company a viable customer? The degree to which an organization is sufficiently mature, financially—and from an executive board of director perspective—can impact the success of any project. Does the perspective company's business objectives and ethics align with your company's own corporate values? If your company is a strong believer in supporting and preserving the earth's fragile ecosystem, and the prospective customer disposes waste into large bodies of water, a business relationship may not make sense. Is the prospective customer's company sufficiently funded from a financial perspective? This is where an analysis—of their market position, revenue, holdings, and liability—is important. As a vendor, committing to an engagement means tying up valuable resources that might otherwise be deployed. The Sales function makes certain the prospective company can pay for the services requested. Do they have an organizational infrastructure that will support an initiative such as the one they're requesting? Most engagements require intense involvement from the customer's business and technical organizations. These individuals are the ones who provide requirements, answer questions, and review test results. If the company is unwilling to commit these resources to the engagement, the chances of a successful project diminish proportionately.

Sales also makes it a point to gain a more organic view of the customer's business objectives and goals—but they do so in conjunction with the Business function. Both question whether or not the effort is realistic and achievable in the timeframe specified. In addition, and because this requires some focused and often specialized industry knowledge, both the Business and Sales functions investigate and comprehend the prospective customer's competitive landscape—the surrounding marketing forces and any industry drivers that may impact the customer and/or the success of the initiative.

Once these questions are answered, both determine whether or not there is a match in terms of the offerings and what is being requested. For example, let's say the prospective customer has a mature, well-established company, and a multitude of 30-year-old legacy systems. Let's also say the vendor's own company specializes in eCommerce and web development, but has no depth in traditional systems development and integration with back end systems. There's probably not a good match of skills and organization infrastructure. At this point, the vendor may choose to withdraw from the proposal process, or suggest a partnership or joint venture with a company to supplement the skill set. Often, this is where the Sales function gets involved; it is their job to be cognizant of other companies working in, or peripherally involved in, related arenas.

Assuming there is a match, Sales determines the prospective customer's concept of pricing, project duration, and staffing requirements. Most prospective customers have some idea of what they can and/or will, spend. They also have some idea of when they want and/or need the project to end, and what the staffing mix should be. This is largely dependent upon their own internal organization infrastructure and culture—and the degree to which they wish to complement, and/or supplement, existing staff. Part of what a potential customer is buying is transference of knowledge and expertise to existing staff.

This is the point at which the Delivery function is introduced. Delivery sanity checks the prospective customer's preliminary requirements, and balances them against his/her own delivery model and staffing plan. Granted, in many cases, individuals experienced in the Sales and Business functions can cover these preliminary discussions (project pricing, duration and staffing mix). However, even though these discussions are preliminary— prospective customers often ask a potential vendor to give them some idea of cost, duration, and staffing mixes. And customers never forget responses given to them, even at this preliminary stage. If any of these elements are underestimated, it may require force majeure to help the prospective customer re-think their established paradigm. Conversely, if these elements are grossly overstated, the prospective customer may dismiss the vendor out of hand.

What also factors into this mix is the type of relationship Sales hopes to establish with the potential customer. There are times when a particular project is a one-time initiative. More often than not, however, a vendor hopes to establish and build an annuity relationship with a prospective customer. In this regard, both the Sales and Business functions must evaluate and agree upon the actual account strategy. For example, is it appropriate, in the interest of coming up the speed, to underwrite some of the project? The underlying principle being that most first projects require a bit of extra time to become familiar with a customer's organization, infrastructure, the business model, and even the location of their parking lot (metaphorically speaking). Rather than charge a customer for this ramp up time, many vendors will partially underwrite the first project. This obviously cuts into the vendor's operating and profit margin, and is worthwhile only if subsequent business is awarded and won.

By now, the Sales and Business entities should have a pretty good understanding of a prospective customer's corporate culture. Key to this the identification of the key buyers and influencers within the corporation. Sales is in a position to separates out the formal, versus, informal, influencers. They ask, “Who is the buyer?” and “Who owns the budget?” In doing so, Sales ascertains which individuals are friendly or hostile—and which ones just need time to digest the potential relationship. It is a cardinal rule in consulting that not all employees in a prospective customer's company can award work—but anyone and everyone can hurt your chances of winning. Sales should know which customer will take the time to explain what they want, and which ones basically want you to go away and figure it out for yourself. To behave counter to their working styles means anything from merely irritating them, to courting disaster.

Sales also determines how the customer wants to receive proposal information, and in what format. Some want to receive a 100-page treatise; others prefer a 10-15-page bullet-point presentation. For example, many prospective customers require information about a vendor's systems development methodology. Some just want to see if the vendor uses one, and if so, which type (waterfall vs. iterative). In this regard, an exhibit with milestones phases, names and descriptions is generally sufficient. However, some customers are interested in the actual methodology. In this instance, it is appropriate to include more granular information including phases, activities and tasks, and associated deliverables. This is where the delivery temperament can help, or hinder, the sales process. Delivery is detail oriented by nature. To know where and when to draw the line in a proposal is a delicate balancing act—and one that should not be placed squarely on the shoulders of the Delivery function.

Where the Delivery function can mitigate some of the Sales function's—enthusiasm—is in the area of methodology and staffing. Remember the quip, “What comes first, implementation or testing?” This wasn't a quip; the individual was dead serious. Avoid at all costs the temptation to allow the Sales function to translate high-level requirements into a level of effort and corresponding time frames. Also avoid allowing them to determine which methodology to use, or to select the appropriate phases. Worse yet, do not permit them to spontaneously make up a methodology. Clearly, all of these elements impact and contribute to, the cost, and subsequent price, of the proposal. Who was it that said, “A little knowledge is a dangerous thing?” Probably someone from Delivery, describing their Sales counterpart.

On the other hand, how many times have you listened to a Delivery colleague complain about not having enough information? In the absence of facts, Delivery will merely fill in the holes because of their detail-oriented nature. When left to our own devices, we may well increase the estimates, just to make certain we can deliver on time and on budget. This may result in an increase in staffing and duration—and a commensurate increase in the total contract value and subsequent pricing. This increase may not bode well with the prospective customer.

What else does Sales contribute, at this stage in the process? Proposals are generally comprised of two parts: The actual written response to the request—and a summary of the material submitted—which is an executive level presentation. Creating an executive level presentation is, in and of itself, an art form. Regardless of how good a written proposal may be, a vendor can actually close a deal by presenting a professional, polished, compelling and engaging presentation. Conversely, regardless of how good a written proposal may be, a vendor can actually break a deal—by not targeting the presentation to the appropriate level of audience, by not telling them anything they don't already know, or by merely boring them to death. The Sales function must respond to this challenge, and should excel. Because they are not mired in detail—as is the case with the Delivery function—or consumed with business issues, as is the case with the Business function—they should be able to exercise their creativity.

A prime example of this, is the time I worked on a particularly difficult, and lengthy, proposal. Just responding to the 40 or so pages of questions was an adequate challenge. By the time I completed my portion of the document, I had no additional reservoirs of creative energy. For the executive presentation, I was ready to throw a bunch of bullet-point slides together, to essentially regurgitate everything in the proposal. Thankfully, the Sales function, who had wisely left me alone through the written response ordeal, was on hand to contribute leadership to the executive presentation portion. It was my Sales counterpart who said, “Rather than present a bunch of bullet point presentation slides, let's do a quick prototype for them to illustrate what we're proposing, and let's burn the prototype and our written response onto CDs for them.” And, it was my Business counterpart who said, “Well, that's going to cost us money—but since we're investing in an annuity relationship—the investment is worthwhile.” Of course, all roads lead back to Delivery, and so it was ultimately my responsibility to rally the troops, build the prototype and burn the CDs. Nevertheless, this combined effort, despite some of the aggravation, resulted in a much better proposal response. The customer was impressed by the creativity, and diligence behind the effort.

Business

Where else does the Business function become involved—beyond that which has already been described? Once the preliminary information is gathered, there is typically a handoff of proposal activities to the Business and Delivery functions. The Business function's role is to provide the basic foundation upon which the proposal will be built. This individual typically decides whether or not the staffing, pricing, timeframes, and legal aspects hold up from a corporate standpoint. The Business function establishes negotiation parameters, such as how high or low the profit margin must be, which results in a higher or lower price to the customer. They also determine whether or not it makes sense to start work on a Letter of Agreement, versus a Master Services Agreement—and when. Many customers are frustrated at the bureaucracy within their own company. They also bemoan the length of time it takes for their various administrative departments to issue contacts and/or Master Services Agreements. Customers often push to start a project without the appropriate legal documents in place. Starting a project without paperwork is something that is generally evaluated on a case-by-case basis.

The Business function also identifies potential deal breaker issues. If the prospective customer is unwilling to commit to participating in requirements gathering sessions, has unrealistic deadlines or goals, or is unwilling to allocate subject matter experts to the project, the Business function may decide to pass on the project. In addition, the Business function identifies appropriate risk factors, and provides contingency and profit margins. To take on a risky engagement is not good for the customer, or for a vendor who expects to be in business for the long haul. Realistically, an individual outside of the sales and delivery effort must have a good grasp of these factors and take a firm stance on just how many concessions they're willing to make. This independent review, by someone who is not concerned with a sales commission—or by someone who is not invested in their project plan and work effort—is critical.

In addition to the issues noted above, and from an overall perspective, the Business function must take into account risk elements such as patent rights, non-compete clauses or exclusivity agreements, and transitions that may obligate the company to bargain with labor unions. Other risks include exceptions to Limits of Liability, Year 2000 warranties, and rights to terminate/modify contracts.

Why are these Business and not Sales issues? Sales is primarily interested in pure revenue, so their prevailing attitudes and subsequent behaviors may lead them to exercise less caution— and to close a deal in haste. After all, their job is to sell, not put caveats around every single detail. A prudent and experienced Sales individual has learned, however—that the key to success— is a long-term relationship with an established customer. The more work one does with a given customer, and the better educated they are about the customer's business—the more successful the project. This leads to add on work, which generates more revenue without requiring substantial sales activity. When all things work to plan, the Sales function opens the door, sells the initial project, and benefits from paid change requests to additional scope, paid add-on work related to the initial project— and new business as a result of the existing relationship. This is often referred to as account penetration. And once again, in the pure sales model, the Sales function's activities diminish over time—freeing them to focus on other accounts.

Delivery

By now, it has been made pretty clear that it is the Delivery function's responsibility is to make certain that the project is appropriately estimated, properly staffed, and ultimately successful. This can make for a contradictory stance in the proposal process. If the customer has stated few high level requirements and Delivery feels there isn't enough information or time to provide a comprehensive estimate, they may adjust the work effort to accommodate for the unexpected. This is also known, in the industry, as “contingency” or in more popular vernacular, “padding the estimate.” Realistically, even financial models account for a degree of contingency, particularly when a project is being estimated on a fixed price basis.

Once the high level requirements are gathered, the Delivery function selects the appropriate methodology, milestones and phases, and estimates the level of effort and project duration required to bring the project to a successful conclusion. The skill mix is then selected, which also influences and drives cost. Project Managers and Technical Architects, for example, generally cost more than Programmer Analysts. Executive management, individuals who often provide delivery oversight or quality assurance, often cost more than Project Managers and Technical Architects. And if anyone questions the value and merit of a Project Manager, imagine how difficult it is to describe and defend the need for delivery oversight or quality assurance?

Delivery also estimates software, hardware, and operating costs. Many Delivery representatives use function point analysis as a means by which to arrive at their estimates. Because this is approached in a reasonably scientific manner, there is some pride of ownership—and authorship—associated with the final product. Woe be it to a Sales or Business function to question the milestones, staffing mix, and project duration. The prevailing attitude is, what do they know, anyway? Well, plenty, actually—but we'll get into that in a minute.

If the level of effort is increased and adjusted upwards, as is usually the case, the actual cost goes up—as does the corresponding price to the customer. This, then, must be addressed by both the Sales and Business functions. This is probably the most well traveled territory. The Delivery function is, by nature, cautious. The Sales function is, by nature, optimistic. And the Business function just wants to make certain the project is successful, and profitable. More battles are fought, and won, and compromised—over the cost and pricing issue.

In the final analysis, if the project is not delivered on time and within budget, all the carefully planned project financials amount to nothing. And vice versa. If the project financials are air tight, but not based on a reasonable delivery schedule—the effort will result in failure. In the perfect world, Business presents the profit ratios required, Delivery presents the time and effort required, and Sales adjusts the pricing accordingly. But in today's market, customers are looking for value and low cost services—and there is so much competition that vendors are routinely forced to negotiate on, and lower, prices. Or adjust their financial models to remain competitive.

In this regard, interaction between the Business, Sales, and Delivery functions generally result in a fair degree of formal (organizational) and functional respect. And if the process is clear and the roles properly delineated and followed, the chance for discord and strife are certainly minimized.

Closing Comments

Remember when I wrote, “Woe be it to a Sales or Business function to question the milestones, staffing mix, and project duration…what do they know, anyway?” We representatives from Delivery cannot survive without the Sales and Business functions. The Sales function makes the cold call, establishes the initial relationship, and brings in and introduces, the Business and Delivery functions. By direct implication—or just by mere comparison, the Sales and Business functions lend credibility to Delivery. Prospective customers often view the Sales function as “just wanting to make a sale,” and regard the Business function as the driver who is primarily interested in getting contracts signed. They often view the Delivery function, as the population of individuals who actually perform and deliver the work; this is what they value the most from vendor-customer relationship. Most good Sales representatives know this, as do their Business colleagues. In many respects, this is a variant on the “good cop, bad cop” routine.

And as far as limiting Delivery's ability to appropriately estimate and staff a project, many are the times when I‘ve submitted a staffing plan and cost model—full well knowing it was over prescribed limits. And many are the times when the Sales and Business functions have come back and accepted the plan, or made adjustments to their own models, to make up for the variances in my model. For example, Sales may well accept the fact that the value proposition is just too costly for the customer, and turn down the work. This is painful to watch, particularly because they are effectively losing their sales commission, so to speak. Or the Business function may adjust their profit margin or ease up on the risk assessment—in order to shore up the staffing mix and/or duration. Or they may decide to underwrite a resource to help jump-start a project and build good will. This is also somewhat painful to watch, as they have their own profitability targets to hit—and by adjusting them—may be deferring their ability to acquire a bonus based upon profitability.

So when this interaction occurs, and the gestures are proffered, Delivery often sees its way towards concessions as well. Maybe the Technical Architect really isn't needed throughout the full life cycle. Maybe a less expensive resource can be used for testing. Maybe the delivery oversight role can be leveraged over multiple projects—thus reducing the amount of time the project is hit for that particular cost. Maybe some of the functions are moderate, and not complex. Maybe it's a good idea to review the estimate with these things in mind.

Granted, these concession activities do not generally occur unless relationships based upon trust and mutual respect have been built. Once established, however, the empathy each function has for one another contributes to making adjustments with minimal trauma and a lot of grace. Each individual has their own agenda, based upon the goals, objectives and backgrounds. The design, development, construction, and presentation of a proposal should clearly be a joint effort between Sales, Business and Delivery—one that leverages each person's skills and experience. In this way, the proposal process becomes a healthy venue in which a degree of creative tension, disagreement and compromise and good synergy—produces a better and less costly solution for the customer.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA

Advertisement

Advertisement

Related Content

Advertisement