Proposals (2 of 3) – Terms and Conditions

November 30, 2010

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)

November 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.

Project Estimation (3 of 3) – Risk

November 9, 2010

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

November 2, 2010

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).