Skip navigation

Community

Building Stronger Partners

11 Posts tagged with the sales tag
0

Sales Negotiations

Posted by JackBarber Dec 14, 2010

Alright, proposal is done. Now, the real fun begins with the negotiation phase. There are entire books and seminars devoted to negotiation. For instance, NI has used Karrass in our sales training. In talking with Alliance Partners, here are some common techniques.

Tips and Techniques

You should typically start with a win-win approach. Stay positive and first look for the areas of agreement. But, be prepared and willing to negotiate where there are differences. Hopefully, you left some room to negotiate.

  1. Put yourself in your customer’s shoes – The most common mistake is to fixate on your own situation rather than your customer’s concerns. For instance, if you are too worried about winning the business, you may not see how desperate the customer is for a solution. You may need to challenge your own assumptions.
  2. Capture and Create Value – If you have productized your own software for re-use, you may be able to charge a license to use it. If you have created higher labor rates for more experience staff, you can offer to discount it (e.g. using one of your CLAs at your CLD rate).
  3. Silence is Bliss – Don’t talk to too much. Most people are uncomfortable with silence. Let them fill the void – and avoid making mistakes of your own. Use it as an opportunity to test limits and get agreement before making a concession. Also, don’t over-close. If you have a deal, don’t introduce more facts or information.
  4. Slow and steady – As you are negotiating, be careful not to give away too much, too soon. Make concessions slowly as needed. Try offering minor concessions first. And, don’t simply trade ‘tit for tat’.

Always Be Closing

And, until you have a deal, the old adage applies: always be closing. That’s not just about asking for the sale. But, it is a mindset that you should always be driving for closure. What is required to reach a deal? What is preventing the deal from getting done? If you can’t close the deal, figure out what are the next reasonable steps. And, always solidify the next engagement




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/12/14/sales-negotiations/
0

Concluding our short dive into developing proposals, we have discussed the merits of having a standard template and review process to not only improve consistency and professionalism, but also reduce and manage risk. We also addressed some common issues like protecting IP and software licensing. Let’s continue the fun.

Warranties and Indemnification

The other major aspects of T&Cs deals with the liabilities associated with the project:

  1. Warranty – basically, if it doesn’t work or stops working. How long are you responsible to fix it? Note that there is difference between providing  a warranty, which should only address the system not performing as specified and service which can include standard maintenance, updates, adaptations, ….
  2. Indemnification – what if there are damages associated with the system’s operation or failure?

Typically, these liabilities are limited in some fashion. For instance, they liabilities will not exceed the total cost of the system (or project). Note, for those who are CSIA members, there are a good list of suggested T&Cs available on their website.

Customer’s T&Cs

Now, I know this has probably never happened to you, but I’ve heard on occasion from Alliance Partners that the customer will ask to use their T&Cs. Or, send their own T&Cs with their acceptance. So what do you do? Well, first of all, you should have a defined process to review for unfair terms.

Note that if you simply accept their T&Cs, you may invalidate your own insurance policy (which was created according to the liabilities of your own T&Cs). So, a good strategy against an unruly customer may be to ask your insurer for a rider to accept the additional liability and then rebid with that additional charge.




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/12/07/proposals-3-of-3-%e2%80 %93-warranties/
0

Last week, we discussed submitting the proposal for your project including your sales teams. Of course, there is much you should include in your terms and conditions.

Intellectual Property

Your T&Cs should also address the intellectual property involved in the project. To begin with, there should be agreement on the ownership of the work. Is this work for hire? Or, is the purchase of solution including the licensing of the software? Ultimately, there can only be one owner. So, if you sell it, you can’t re-use it.

Many developers struggle with, or even overlook, the value of their software. But since there can only be one owner, it is important for your customer to understand that you will need to start from scratch, which will cost additional time and expense. In addition, you will not be able to re-use code from previous projects which will be more reliable and robust.

Eventually, Alliance Partners often develop standard modules for re-use. By branding these modules, it may be easier to charge your customer for its use. But don’t make the mistake of simply giving the value away. For instance, ‘Oh, I’ve don’t that type of project before, so I can reuse the code and do it in half the time, so I’ll charge half the price.’ No, the project value is still the same. Your efficiency should be your reward to keep.

Software Licensing

But, I’m not naïve. I understand that customers often want to ‘own’ the software. There is the brute force logic of we bought it, so we should own it. And, the common rationale that you might go out of business, so they just want to protect themselves. In which case, you need to explain the principal of ownership and licensing.

Don’t get me wrong. It is OK to appease the customer by giving them the source code, you just need to provide it with a license so you retain ownership. But, you should consider (and address) the following issues:

  • What if they copy/modify?
  • Can they transfer/resell?
  • Can they reverse engineer

But what if there is an issue with the proprietary nature of the application? No problem, simply define which aspects of the application are proprietary. Then, section out that work which will be done and the ownership will be transferred to them without possibility for re-use and therefore no licensing is required. However, all other development should be provided under license and re-use retained.




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/11/30/proposals-2-of-3-terms- and-conditions/
0

Proposals

Posted by JackBarber Nov 16, 2010

Now that we’ve gathered requirements, broken down tasks, estimated the project costs, derived a price, and mitigated risks, we are finally ready to prepare and submit a project proposal.

Standard Template

First of all, you should have a standard template for creating your proposal. At a minimum, it should include sections for:

  1. Overall description and scope
  2. Specific objectives and benefits
  3. Requirements
  4. Constraints, assumptions, and dependencies
  5. Differentiation – don’t forget to make it clear why you are the best choice!

Review Process

Depending on the size of your organization, you should have a formal process for your proposals. Even if you are the one creating your proposals, you should still have a process for reviewing it for accuracy. And, as you begin to delegate proposal creation, you should further define the required approval process. For instance, any proposal over $XXX must have sign off from the sales manager, president, owners, and so on.

Sales Terms

Your proposal should include your standard sales terms. That is the financial aspects of your proposal:

  1. Payment plan – You should outline payments for the purchase of materials as well as milestones which are the basis for the authorization for the work to begin.
  2. Commercial issues – You should specify your payment terms as well as your process for invoicing and remittance (how money is transferred).

In my experience, Alliance Partners are far too timid with respect to these financial considerations. You aren’t a banking institution, so you shouldn’t be expected to finance the project for the customer. If necessary, explain to the customer that you bid the job based on your standard financial terms. Of course, you can be open to accommodating their terms, but you may need to adjust your bid accordingly.




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/11/16/proposals/
0

Proposals (1 of 3)

Posted by JackBarber Nov 16, 2010

Now that we’ve gathered requirements, broken down tasks, estimated the project costs, derived a price, and mitigated risks, we are finally ready to prepare and submit a project proposal.

Standard Template

First of all, you should have a standard template for creating your proposal. At a minimum, it should include sections for:

  1. Overall description and scope
  2. Specific objectives and benefits
  3. Requirements
  4. Constraints, assumptions, and dependencies
  5. Differentiation – don’t forget to make it clear why you are the best choice!

Review Process

Depending on the size of your organization, you should have a formal process for your proposals. Even if you are the one creating your proposals, you should still have a process for reviewing it for accuracy. And, as you begin to delegate proposal creation, you should further define the required approval process. For instance, any proposal over $XXX must have sign off from the sales manager, president, owners, and so on.

Sales Terms

Your proposal should include your standard sales terms. That is the financial aspects of your proposal:

  1. Payment plan – You should outline payments for the purchase of materials as well as milestones which are the basis for the authorization for the work to begin.
  2. Commercial issues – You should specify your payment terms as well as your process for invoicing and remittance (how money is transferred).

In my experience, Alliance Partners are far too timid with respect to these financial considerations. You aren’t a banking institution, so you shouldn’t be expected to finance the project for the customer. If necessary, explain to the customer that you bid the job based on your standard financial terms. Of course, you can be open to accommodating their terms, but you may need to adjust your bid accordingly.




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/11/16/proposals/
0

An important and sometimes overlooked aspect of project esimation is determing the risk associated with the project.  There is a natural tendency to simply estimate the time and cost associated with the project – assuming everything goes well. OK, perhaps, we pad our estimate a bit for uncertainty. But how much? Or ultimately, how can we be more precise in our risk assessment?

The Game of Risk

Project risk comes in a variety of forms. There can be risk associated with ‘newness’ of the project or technology. Risk can come from the lack of specifications or reliance on the customer (e.g. provide necessary parts, time on manufacturing line, ….)

So, for a sizeable project, you want to identify the risks and define their potential impact. Then, determine the possible costs of those risks in much the same way as estimating the costs of the project itself.  Finally, you can analyze the probability of the risks – individually and collectively.

Mitgating Your Risks

After your analysis, you will want to mitigate the substantial risks. For instance, you can:

  1. Minimize the risk – Do a feasibility or pilot study to reduce uncertainty.
  2. Transfer or share risk – Don’t be afraid to consult with the client and inform them of potential risks. Just like a doctors shares the potential risks of a surgery.
  3. Share risk – You may be able to find a way to share the risk. For instance, provided a fixed bid for the project + variable cost for the identified risk as pricing model.
  4. Accept or avoid risk – Ultimately, you may have to accept the risk in order to get the project.

Acceptable Risk

I know of some Alliance Partners who have established acceptable risk factors. For instance, what is the ratio of risk to total project cost. Or, the owners may even have cumulative project risk vs. annual revenue. At some point, you need to know, when to say ‘no’, this project is just too risky.




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/11/09/project-estimation-risk -management/
0

Last week, we started a discussion on project estimation. It starts with good requirements gathering. Then, you can break down the project into a set of tasks to develop a system that meets the requirements to make estimates the effort, duration, and cost of those tasks. Now, we move on to translating that into the actual project price.

Pricing Method

Once you have estimated the cost of the project, you can determine the total price for the bid. Yet this is another area, where mistakes can be costly. So, you should develop a common, efficient and standard method for pricing projects. This becomes particularly important as your organization grows and you look to delegate the responsibility.

Cost of Goods

The cost of hardware should be straight-forward, right? You may have common products stored in a spreadsheet or rely on the vendor’s web site to look up prices. But, do you have a method in place to validate your cost of goods? If that is too much overhead, you should require validation on higher-priced items.

Labor Rates

How about labor rates? If you have done so already, you should consider establishing different labor rates depending on seniority, certification, and so on. If nothing else, it creates value that can be negotiated. For instance, in a competitive situation, you can ask the customer other bids included labor from certified developers. Or, if your customer is pushing for a lower price, you may want to say ‘OK, we’ll give you a discount, but because you are a good customer, we’ll be providing a certified architect at certified developer prices.”

The Price Is Right

Other possible variables that you may want to include in your price are pre-sales effort, marketing, and other overhead. You may not want to provide them as line-items in your quote, but ultimately they need to be accounted for. And, finally, you should assess the capacity and ability of your organization to take on the project. Not to mention the overall risk of the project (more on that next time).




Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/11/02/project-estimation-pric ing/
0

Project Estimation (1of 3)

Posted by JackBarber Oct 26, 2010

One of the areas that has always amazed me with respect to Alliance Partners and their system integration efforts is their ability to estimate and ultimately bid the project cost. It seems almost an art (perhaps a black art) as it is a science, but it is critical to the success of the business.

Project Requirements

It starts with gathering good requirements which is an art in and of itself. In a previous post, we discussed a ‘needs-based’ approach and the type of requirements that you want to gather. We also talked about probing techniques and how to deal with conerns.

Task Breakdown

Once you have a good set of project requirements, you still face the challenge of estimating the cost of the project. Hopefully, you have a good idea of the hardware requirements, but labor usually makes up the bulk of the total cost. Ideally, you can break down the project into a set of tasks to develop a system that meets the requirements. Then for each task you can estimate the effort, duration, and cost.

There are several methods for estimating the labor cost of each task:

  1. SWAG (Not recommended) – Scientific Wild Ass Guess
  2. Expert – ask an expert based on their experience
  3. Delphi – Ask a group to brainstorm and build consensus
  4. Comparative – Based on history or similar task
  5. Weighted average – a combination of estimates (e.g. Optimistic + 4*Likely + Pessimistic) / 6)

Obviously, depending on the size of the project, you’ll need to decide how much time you want to invest in this process. But, estimating project costs is critical to your profitability.

Labor Cost Variables

Other factors to consider in estimating projects.

  • Work interruption factor – no one can work uninterrupted. For instance, meetings. Such breaks in the thought process and work effort will inevitably impact effectiveness. Idea: consider limiting meetings and e-mails to certain parts of the day.
  • Part-time effect – Working on multiple projects can impact effectiveness. The developer must ramp up or down from one project to the next.
  • Skill factor – Obviously, a novice may take longer to complete a task than an expert.
By completing the task breakdown and considering the variables, you can reasonable estimate of the labor cost which often constitute the majority of the cost of the project. Next week, we’ll formulate that into a price and ultimately the proposal.



Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2010/10/26/project-estimation/
0

Probing for requirements

Requirements gathering is largely dependent on your probing techniques. So, it is worth your while to educate yourself (and your sales team). For instance:

  • Open probes – used to understand concepts. What do you need? What about this is important to you? How will this make a difference?  Tell me more.
  • Closed probes – closed to elicit and clarify specific information. So, the requirement is …. If I understand you correctly, you’re saying … Right?

Keep in mind that during the requirements phase, the customer should do most of the talking (70%). Using  these type of questions, you should be able to follow the basic 3 step requirements technique:

  1. Elicit and define the need
  2. Analyze and support a suitable solution
  3. Verify and close that the need will be met

Note that it is not essential to come up with the exact solution to the need. You merely need to establish what the requirement is and how you will judge if the requirement is met.

Dealing with Concerns

concerns Another aspect of successful requirements gathering is recognizing concerns and knowing how to deal with them effectively. In each case, you should first acknowledge the concern and probe further for clarification before responding. Then, check again for acceptance before closing.

Skepticism – occurs when a customer expresses doubt about a proposed solution to a requirement. Respond by offering further proof.

Misunderstanding – occurs when a customer is misinformed about your proposed solution. Respond by clarify the proposed solution and seek acceptance.

Indifference – occurs when the customer understands the solution but does not see that it is necessary. Respond by validating the need before repositioning the solution.

Drawback – occurs when the customer not only understands the solution but is not satisfied. Respond by acknowledge their dissatisfaction and their unsolved need. Then depending on the situation, you may need to refocus the customer on a great need that is being resolved, thereby minimizing the issue.



Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2009/05/20/sales-tactics-requireme nts-gathering-cont/
0

At National Instruments, we teach a ‘needs satisfaction’ approach to selling where:

  • Selling – A process of uncovering, understanding, and satisfying customer needs.
  • Need – A customer want or desire that can be satisfied by your product or service

 So, selling is the process of revealing AND understanding customer wants, desires, and needs; then satisfying those needs with the features and benefits of your organization, products, or services.  Often, system integrators refer to this as requirements gathering. And, it’s arguably the single most important aspect to successful, profitable projects.

Establishing scope

Gathering requirements begins with understanding the scope or the ‘big picture’ for the project. Not only what really needs to be accomplished, but how will the project be viewed as successful? Just as important, you must ascertain the stakeholders who will ultimately be judging the success of the project. And, distinguish between the elements that are critical versus nice-to-have, or non-essential.

100_3106Until you understand the big picture, there is not much sense diving into the details. For instance, my wife and I like to take vacations, but would often end up frustrated until we understood our different ‘scope’ for our project. For me, a vacation is about doing stuff. For my wife, it is about not doing stuff. Once that became clear, we were able to establish requirements that fill both our needs.

Types of Requirements

During your sales engagement, you should have a checklist to ensure that you have gathered requirements for all aspects of the project. In addition to the basic capabilities and performance of the system, how will the customer interact with the system? What interfaces and data/results be required? Other requirements might include safety, reliability, security, and so on.

Ideally, for each requirement, you should assign specific attributes. Most importantly, how will you measure/assess the requirement and the acceptance criterion? Some folks also assess uniqueness, criticality, and relative priority of each requirement. And, some even establish the feasibility and risk of each requirement as well as record the source of the requirement in case there is trouble meeting it.



Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2009/05/18/sales-tactics-requireme nts-gathering/
0

If you’ve been in the NI Alliance Partner business for long, you realize that technical know-how is great, but selling is key to your success. From beginning a sales engagement and gathering requirements through proposing, negotiating, and closing the sale, there are many things that can prevent you from ever applying that great technical knowledge.

First Contact

Selling begins with that first customer contact after the lead is generated. Actually, some argue that selling is part of the marketing process itself. But, marketing, well that’s topic in and of itself. So, let’s assume that the lead has already been generated.

  • Preparation – what is required for the proper opening? Gather all known and available information about the prospects. Based on the source of the lead, what do we know about the potential customer (e.g. needs, care-abouts)? What was the value proposition that he has already encountered? Also, has there been any prior contact, maybe they are already a customer. Of course, the amount of preparation should be proportional to the anticipated size of the opportunity.
  • Opening – Always have down pat how you are going to introduce yourself and your company. Often, this is akin to your positioning statement. That should be followed quickly by the purpose of the meeting or call.
  • Expectations – Then, set the expectations for what you want to accomplish. Agree to the agenda and how much time that both parties have. In addition to ensuring that you understand the purpose and agenda, this will allow you to take control and set the tone for the meeting.

The old adage applies; there is only one chance to make a first impression. Don’t miss your opportunity to make it a good one.



Originally posted by Jack Barber at http://buildingstrongerpartners.wordpress.com/2009/05/13/selling-is-key-to-your- success/