100th and Final Post

It seems only fitting that my 100th post on this blog will be my last. As you may have seen in the NI Alliance Partner News on December 17th, I will be transitioning to a new role focusing on companies that supply NI with services (e.g. calibration, maintenance, and so on).

Changes to the NI Alliance Partner Team

Over the past 6 months, NI has been building our partner team to meet our increasing partner needs. Our mission is to ensure customer success by engaging system integrators, solution providers, product and technology partners while fostering mutual growth and financial success and driving new product adoption. Our partnering resources now include:

• Armando Valim, Partner Programs Group Manager
• Jeff Meisel, Software Product Partners (e.g. LabVIEW add-on toolkits)
• Robert Jackson, Hardware Product Partners (e.g. CompactRIO modules)
• Julie Schreier, Partner Programs Marcom Manager
• Rob Reichmeider, VAR Manager for Americas
• Kelly Hunka, Partner Programs Associate
• Andrew Ellison, Alliance Program Administrator
• Additional resources (to be determined)

In the interim, Amando Valim will assume responsibilities of Alliance Program Manager. For inquires that you previously directed to me please, you can now contact partners@ni.com.

Importance of our Alliance Partners

It has been my pleasure and passion to work with our Alliance Program Partners building our mutual business for these many years. While I am looking forward to new opportunities in my career, I firmly believe that building stronger partners is crucial to our continued success. Good business practices is an important aspect of that growth – thus, the reason for this blog. I hope that you have found some insights on how to improve your business. For the time being, I’ll leave this blog up and remind you of the Table of Content is a good way to access the content.

Best regards,

Jack

Sales Negotiations

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

Proposals (3 of 3) – Warranties, ….

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.

Proposals (2 of 3) – Terms and Conditions

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.

Proposals (1 of 3)

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.

Project Estimation (3 of 3) – Risk

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.

Project Estimation (2 of 3) – Pricing

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 tasksthat meets the requirements and 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).