Selling services--coordinating sales and project management
Michael Cooper, Westford Consulting
Frank Winters, The Winters Group
This paper considers pitfalls that Information Technology vendor companies often fall into when selling services. Customers buy consulting and systems integration services because they need to address major business issues. Amazingly, vendors often overlook this critically important point. This paper will focus on the interaction between the vendor's sales team, the project/program management team and the customer during the sales cycle. The paper makes suggestions for improving the effectiveness of the working relationship between sales and delivery.
In addition, the paper shows that a lack of empathy with the customer's business issues and/or goals causes a great deal of the communications breakdowns that occur during the selling of solutions. Sales people focus on getting the deal. Delivery people focus on process and technology. The customer is living in a different world, one that is focused on business issues that are usually part of the customer culture in a way that makes it seem unnecessary to communicate with outsiders about the issue because it seems so self evident—something that “everybody” knows. On the vendors side it is critical that both sales and delivery is focused on understanding the problem (listening) and then solving it together. When this is understood, the need for an effective working relationship between sales and delivery becomes obvious. Throughout this paper the importance of open communication between all parties is stressed.
There is an opportunity to improve the relationships that exists between vendors and clients as well as between delivery and sales. The ideal situation is that the three factions work together as members of the same team. Let's start by understanding some of the situations customers are in when they decide to hire an outside vendor or consultant.
The Customer's Situation
Customers hire outsiders to do work for one of the following reasons:
• The needed expertise does not exist in the company.
• The needed personnel does not exist within the company.
• The project is so important that the company wants to hire world class experts, even though they may have their own expertise and personnel.
• The project is unimportant and is a necessary nuisance and the customer wants to use its own personnel for much more important work.
• The project is behind schedule and has been put in panic mode.
The striking thing about these reasons is that they are very different from each other. It is extremely important that everyone on the vendor's team, sales, delivery and management, understands why the customer has decided to go outside for help. Alignment with and understanding of the customer's situation is critical to the success of the sales effort and project. The customer must be made to feel that alignment and empathy exist. In fact, it is virtually impossible to win business without achieving alignment with the customer's situation.
What is the Program? What is the Project?
There is an important difference between the concepts of program versus project management. The difference is more than simply semantics. Programs are interdisciplinary efforts to achieve a business objective. For example, a common objective will be “to reduce production costs” or “to increase market share” or “to consolidate operations in preparation for a merger.” Projects are created to support programs that may consist of many projects. Knowing how a particular project fits into the business objectives of the program it supports is another key to successfully selling and delivering the services that support the project. Understanding the business objectives that are behind a project effort will enable the sales and delivery staff to understand how the customer is motivated which, in turn will help them understand the context of what they say and do.
Alignment of Goals and Objectives
Vendors and consultants will often say that they are partners (small “p”—this is the spirit of partnership and should not be confused with true Partnerships such as joint ventures) with their customers and their own success depends on the success of each of their customers. This is an excellent concept. However, unless the vendor's sales and delivery staff understands the business goals of the customer, it will be difficult to make it work. This understanding will only come if the sales team goes out of its way to understand the client organization and takes the time to ask the questions concerning the business context of the project.
One might say that ideally the vendor's sales team should be selling service at the program level. When possible, this is ideal. However, in the case of large organizations with large programs, it is not always possible. Decisions are very often delegated to project managers. Strangely enough, it is sometimes the case that the project manager within a large customer organization will not know what the business goal at the program level is. So finding out and clarifying business goals and objectives is usually a service, helping the customer as well as the vendor gain a better understanding of what is being done and why.
Why is There a Split Between Sales and Delivery?
The split that very often occurs between sales and delivery is caused by a lack of teamwork and mutual respect. The folklore of business is full of sayings that support a lack of teamwork:
• “Nothing happens until a sale is made!”
• “You don't even understand what you are selling!”
• “I don't trust you to deliver!”
• “You always give away the store!”
The fact is that good sales people understand what it takes to deliver working solutions and good delivery people understand how difficult it is to sell intangible solutions that are difficult to articulate and understand. Of course some of the best sales people are actually engineers/consultants who can sell. But there are not enough Renaissance individuals to go around. The mere mortals among us must resort to teamwork (more fun than working alone anyway). Of course, the team must include the customer. The trick is to get everyone on the same team. Anything short of that results in splits and fractions, in fighting and figure pointing. This is a true recipe for disaster.
This situation is made worse by the fact that each role comes with differing pressure. Sales people have tremendous pressure on them to close business. In fact the worst thing that can be said of a sales person is—“he or she can't close.” Business people and project management at the customer have the pressure to deliver the business benefits expected by their firm. Human nature being what it is, many times the vendor will be blamed for any failure no matter what the true cause. The vendor's project manager is pressured to be a professional at all costs—to deliver at all costs using all available techniques including reading the customer's mind to discover what is really needed. If the outside project manager is not careful, he or she will be constantly under the gun getting pressure from all sides. So everyone involved is living in an environment of pressure. There is a danger of falling into the trap of creating factions and even armed camps.
Solution Selling® (AKA Consultative Selling) Excellent When Used Properly by the Team
Solution Selling ® (Bosworth, 1995) has at its foundation some excellent concepts:
• Find out what is troubling the customer
• Find out how it affects important people in the organization
• Work with the customer to create a shared solution vision
• Along the way negotiate for access to power
• Don't propose until you have agreement in principle.
The nine box model, an important part of Solution Selling®, is kind of a primer on how to talk to someone to do much of the above. It's a framework for a dialog that very often can't really take place all in one sitting or between two individuals. It's really a guideline, almost an allegory for teaming up to identify the issues/problems/opportunities, understand the organizational impact, and create the vision of a solution. Unfortunately Solution Selling® and programs like it are often used as sales (only) training, and worse they are very often not really implemented but are used as a kind of buzz word based “spray can” to comfort the uninvolved who are told “we use solution (or consultative) selling.”
Solution Selling® is an excellent tool when it is properly implemented. It encourages teamwork, particularly regarding vision creation, where it is extremely important. When solutions to complex business and technical problems are being sold, an interdisciplinary team that includes systems architects and/or designers will be needed to create a vision that can actually be implemented. Of course, this is more or less true depending on how complex and unique the customer's opportunity is as well as how well packaged the vendor's solution is.
In very complex situations at the program or business problem level with many unknowns, a broad scope of work and ambitious schedules, a rigorous process including the following steps needs to be followed:
• Requirements analysis
• Preliminary design and planning
• Work Plan development.
This is just to figure out what needs to be done. Once this is complete and a program is defined, getting involved in delivering to each of the defined projects is a much simpler task. For example, if a new venture is planned in the eCommerce space, at the very beginning consultants may be brought in to define the nature of the business, develop a branding and marketing plan and then figure out what systems are needed. Once that work is done, another consultant may be asked to provide content management for an online retail catalog—a much simpler task. For the latter a solution selling approach using a team of sales people only would work. In the first case an interdisciplinary team will be needed.
Problems With the Process Model as it Often Is
We have now established the essential need for close cooperation between sales, delivery, and the customer. All too often this is not happening—we will look at why this might be by posing a series of questions. We will consider inappropriate actions, and the consequences of those actions. In our experience almost every variation of answer to these questions can be found happening today.
Question 1: When does the project management function participate in the sales cycle? Before, during, or after commitments are made?
In many cases, the vendor's project manager, responsible for the execution of the work, is not involved early on in the sales cycle, sometimes not even until after the sale has been made. The consequences of this are typically:
• Reworked proposals late in the sales cycle in order to rush to accommodate more realistic plans identified by a project manager coming late to the situation
• Inadequately costed solutions proposed by the vendor
• An inability by the vendor to staff the project in the time required when the work is won
• A poorly planned and setup project, leading to customer concerns right from the beginning about the ability of the vendor to control the project.
Question 2: When does the project management function take responsibility for the opportunity? Before, during, or after a contract is executed?
Clearly the latest desirable answer is as soon as the contract has been executed, but even then, in some cases a project manager may not have been assigned until after some work has been done by business analysts and/or technical architects. There are a couple of important points to recognize here:
• If work starts before a project manager is assigned, it must be recognized that one person needs to undertake the project management function, even if they are not formally recognized as a project manager in the vendor organization. Project management activities do not go away simply because no one has been formally appointed project manager.
• More importantly for this paper, the real issue to address is the handoff between sales and project management. When, and how, does this occur, and is it formal or informal, is it recognized or does it “just happen somehow.”
Consequences of not understanding this issue are usually confusion about who can make what decisions as the sale moves from an opportunity to a contracted piece of work. This can result in poor, late, or conflicting decisions, and often comes across to the customer as a confused organization. Customers really want to know who is in charge—in terms of who to go to for issues and decisions.
Question 3: When does the subject matter expert(s) participate in the sales cycle, and when does the subject matter expert(s) take responsibility for the solution?
This is very similar to the previous two questions. The consequences of lack of early involvement by subject matter experts (business or technical) are often the same as those for project managers, with the added issue that a lack of communication of the sales strategy to the subject matter experts can result in late changes to the vendor's solution.
Question 4: Is there agreement between sales / account management / project management / subject matter experts before commitments are made to the customer?
This is a simple question, the answer to which is too often “no,” the consequences of which are similar to when the project manager is not involved early in the cycle, together with additional issues such as:
• A feeling by the delivery staff (project manager and subject matter experts) that they have been “setup” by sales, which does not engender them to a positive relationship with the customer.
• Work being sold that does not align with the strategic direction of the vendor company, and that may not be deliverable.
Question 5: Do the project manager and subject matter expert(s) understand the customer's business context for the existence of the project?
An answer of “no” may be a consequence of inadequate communication between sales and delivery, but the root cause may be a failure on the part of the vendor to ever understand why the customer is undertaking the project. Sometimes this can even be traced back to a failure of the customer to understand why they are undertaking the project! Of main concern here is an inadequate alignment of scope of work with customer need. Without a true understanding of why the project is occurring, the vendor will to some extent be guessing at the needed scope of work. They may try to steer the customer towards features that they are good at supplying, or they may ignore, through ignorance, critical areas of scope. At the very least they may not understand the customer's priority of scope. This can result in a significant reworking of early project deliverables as the vendor is “taught” the customer's needs during the early part of the project.
Question 6: What is the extent (if any) of the involvement that the project manager has in the ongoing management of the relationship between the customer and the vendor?
When the work has been won, and the project started, we often see project manager's heads down getting stuck into the project, focused like a laser on meeting the project deliverables. This is all well and good, but in itself not enough. The project may be part of a larger program, and another project has uncovered some situation that requires significant change, or even abandonment, of the vendor's project. What now happens is that change can occur unexpectedly to the vendor's project manager, blindsiding the delivery team. The delivery team is now operating in an entirely reactive mode, and is clearly not aligned with the customer's thinking, resulting in an inability to be an effective partner to the customer.
The Process Model as It Can Be
There are many approaches to an effective alignment of sales, delivery, and the customer. An organization may have an existing process, but some serious breakdowns in its execution. Perhaps some of the questions above help clarify a need for improvement, and provide some ideas for areas to work on.
Exhibit 1. Process Model
In Exhibit 1 we present one version of the process model. It is not absolute in terms of needing to be followed to the letter. If used, it needs to be appropriately applied to an organization's existing processes, people, and products/services. There must additionally be recognition that the process itself is not enough—it needs to be backed up by desire for the process, and effective interpersonal skills of the people executing the work.
In the model presented there are six steps (which may be iterated), three oversight activities, and four checkpoints. The checkpoints are critical for a number of reasons, although how they are implemented can vary considerably.
The first step covers the generation of an opportunity, followed by four steps that cover the sales cycle itself. Finally, there is the step to execute the project. We do not mean to imply that the sales cycle steps are not a paid for activity—this depends upon the situation and your relationship with the customer.
Checkpoint 1 is where sales and delivery initially get in synch with how an opportunity will be pursued—what is the strategy, and who will get involved. This may vary from delivery being copied on the existence of the opportunity, to the creation of a chase team comprised of a combination of sales, subject matter experts, and project management. Ideally the remainder of the sales cycle will follow the strategy, with people participating as needed, guided by the overall direction of the sales leader—which is typically the sales person but which need not necessarily be that person, especially for follow on business. After this checkpoint the initial customer business need is understood, and a capability identified that will meet the customer's business need and which has the customer captivated—a “vision” has been created.
Now the vendor needs to determine if it can actually provide the capability. This is a critical time, and if Checkpoint 1 was glossed over this is where delivery often feels they have to deliver the impossible. At Checkpoint 2 the vendor typically determines if this is business that it wants, and may use a formal opportunity matrix to help in this determination. Assuming a decision to proceed, the detailed needs analysis step is typically where the vendor's subject matter experts combine with project management to identify potential solutions that deliver the capability, identify an appropriate approach, and get the customer bought in to a particular solution—a “road map” has been created.
The chosen roadmap is now translated into a formal solution that can be proposed to the customer. Checkpoint 3 is a review meeting prior to commitments being made to the customer. This approach can be forced to happen when it is policy that no financial commitments can be made to the customer unless they are signed off by sales and project management. Preferably these are real signatures, which forces a greater sense of commitment. There has to be recognition that the project manager can actually say they will not sign—there also has to be agreement that if anyone has a significant concern, it is discussed as factually as possible so that an agreed business decision for the vendor can be made. It is quite possible that a project can be proposed with some high risks that the project manager was initially unwilling to accept, but that after reasoned discussion the vendor commits, knowing and accepting openly the business risks involved.
With alignment on the proposal, the solution can be proposed and closed—most of the actual selling has been done prior to this step, so if there has been good alignment between sales, delivery and the customer this may be easier than it at first appears. Checkpoint 4, the project kickoff, can vary from a simple handing over of the responsibility from sales to the project manager, through to a formal multiday project initiation / team building meeting (which can include the customer).
A project steering committee may be created for project oversight, with responsibilities including maintaining awareness of changing business demands and communicating these to the project manager. The PRINCE2 project management method (CCTA, 1999) provides a good example of how a project board can be incorporated into a project. Alternatively (or additionally) this can be the point at which the project manager and the vendor's person responsible for the management of the long term relationship with the customer (maybe a sales person, or a dedicated account manager) decide the process by which they will remain in synch with changing customer business demands.
Throughout the sales cycle the reality is that the opportunity, and strategy to pursue it, are potentially in a constant state of assessment, and we have identified this overarching process. Similarly the reality during the project execution is that there is also a need for constant assessment, hence the oversight process (which may be undertaken via a project board).
Account planning is typically undertaken when the vendor has a good understanding of both themselves and the customer. Typically, this happens after the first few contracts. Such a plan can become a living representation of the communications between sales and delivery when it includes the following and when it is constantly revised:
• Recognition of the business objectives of the customer
• Alignment of the vendor's solutions with the customer
• Alignment of vendor personnel with customer personnel to maintain the overall relationship
• Planned steps that the vendor team will take to progress the relationship
• Recognition of the business objectives of the vendor.
We hope to have shown some of the reasons why sales and delivery are so often misaligned and some of the adverse consequences of this. Our premise is that correction of this is essential, and is nothing more than the simple application of common-sense business processes to improve communications between the various parties, together with commonsense interpersonal relationships between people. The problem is, common sense is too often not all that common! Just keep up the search for it!
Bosworth, Michael T. (1995). Solution selling: Creating buyers in difficult selling markets. McGraw-Hill Professional Publishing.
CCTA. (1999) PRINCE2 Reference Manual. ISBN 0113308558.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA