Stand-Up Sales

Will your Software Project Proposal be rostered on your customer's list of approved projects this year?

Part of the back-and-forth between different customer stakeholders is contention over budget.  But you can't budget without numbers.  So, if your project is going to be in play, you'll probably have to deliver the dreaded Estimate!

Example Of Estimate And Project

But, have no fear!  An Estimate is your friend!  Done properly, an Estimate can be a key step in advancing a sales cycle which provides important benefits to both customer and vendor. 

On one hand customers are concerned to minimize project risk.  And on the other hand, vendors are concerned to minimize cost-of-sales (which is a kind of risk in itself).  The Estimate is one step in addressing both concerns together.

The reason for this bi-directional benefit is the acknowledgement that both parties are involved in a process of "peeling the onion".  At the beginning of a project all one may have is a "vision".  And it is a process to gradually enhance that vision until it becomes a successful part of the customer's business -- or not.

The "or not" part is also an important part of the estimating process!  It may be that through the estimating process that the customer discovers that the Project should not be pursued.  This process of incremental development of a project plan is an important way to manage risk.  It is a truism of  software projects that an unconscionably high percentage of approved projects actually fail.  The steps outlined here provide one way to help ensure your project has the best chance of success.

The WBS Is The Secret

Alternative engagement models may involve competition, a POC and/or an RFP.  Regardless of the sales process, an Estimate will be especially enhanced by the level of detail that you can economically include in your analysis. 

The example software project Estimate attached here was based on a Work Breakdown Structure (WBS) of about 350 lines (including 250 "leaf tasks").  The WBS was developed in discussion with the customer, but the confidence in, the completeness, and correctness of the set of Tasks was derived from vendor experience.  The Tasks were sufficiently granular that relevant vendor experience for specific patterns, could be applied.  The elapsed time to develop the WBS was a week; actual effort was only one day FTE in total for the customer and two days FTE for the vendor, involving on the vendor side, sales, business analysis and software architect.

Here are the steps that were taken to build the Model Estimate:

1. DRAFT PROJECT PLAN -- Working with the Customer, develop a short Draft Project Plan, maybe three to 10 pages at most.  The most important elements in the Draft concern project sponsorship, governance, relevance to business model, project interfaces and boundaries, and high-level project functionality objectives.  For the first cut, this is not a paid activity.
2. WORK BREAKDOWN STRUCTURE -- Working with the Customer, develop a Draft WBS.  This exercise is significantly helped by developing the WBS "live" using project management software.  PM software enables the easy capture of information, and presentation and summarization of information that prevents information overload.  The development of the WBS is also a dialogue between customer business sponsors and vendor technical staff because the Estimate WBS will cover both business and infrastructure functions.   Note that the WBS dialogue may identify "unknowns" around design -- which is a good thing.  It is important to be able to highlight areas that must be investigated further; for which then there is likely the requirement of customer funding for these clarifications.  The estimating method used in the example was to tally up Use Cases, which had been defined at a comparable level of effort granularity.  Use Case-based estimating is a good method, you may prefer another method.  At this first-cut estimating effort for the size of project described here (mid six figures development costs), estimating is not a paid activity. 
3. VENDOR ESTIMATING EXERCISE -- The last step in developing the Estimate is for the Vendor team to assess the work or effort required and to develop costings.  In the example here, the proxy for work is the Use Case.  It is important to remember during this exercise that the Estimate is just that -- an Estimate.  In the Model Estimate shown here, the confidence interval around the Estimate is +50% to -30%, 19 times out of 20.  If there are risks that have not been properly assessed, then the Project Plan and/or WBS may need to be re-visited; otherwise a costing can be attached to each item in the WBS.
4. ESTIMATE PACKAGING -- Now that the Estimate is developed, it can also be packaged in Phases, according to the needs of the customers and the sales team.  The delivery of the Estimate is an important sales step and should be handled accordingly.   Given the transparency of the estimating process, the delivery of the Estimate will be a moment in which both customer and vendor have a stake, and thus a very positive step forward sales-wise!

As discussed in the attached Model Estimate, the value of the Estimate is very clear:  It is to answer the executive sponsor's reasonable question "how much is this going to cost me?"  Another way of phrasing the same concept is to say that the Estimate defines the "scale" of the project.  The executive has a right to know that the Project in question is "mid seven figures" or "low seven figures" or "high six figures" etc.  On that basis, the executive can decide if a project is worth exploring -- and including on a list of budgeted projects. 

The methodology outlined here will get you to that understanding of project scale, professionally, and in a way that limits all parties' risks.  For well-defined and repeatable projects, you may not need not to go through the full exercise outlined here.  However, if there are uncertainties and unknowns, development of an Estimate will be very helpful.

Don't Worry -- It's Just A Ballpark

An objection that "high six figures is not precise enough", misses the point.  This exercise concerns an Estimate, not a full Project Plan.  Furthermore, as detailed in the attached example, from a legal perspective an Estimate is not an offer to do business.  We want to do business, but first we need to feel confident that we are "in the ballpark" -- then we can go forward with Discovery, Project Planning and delivery of a proper Proposal.  Of course, the Project can still be cancelled.  The methodology discussed here is one of incremental project development:  one iteration after another, either based on insights from experience, or on one or more POCs.

Here's a caveat: what do you do when your Estimate is higher than the cut-off for project approvals?  Or if you think your Estimate is worryingly higher than any competition? Should you low-ball the project?  Another way of phrasing this question is in the proverbial "sell the Chevy and deliver the Cadillac" style of sales.  There's a simple answer to this question:  "NO".  Unless you want to base your career on one-shot opportunism, in other words on a treadmill of broken promises, you will stick to your professional and ethical principles and provide the best information you have.  And your reputation as a straight-shooter will serve you well.

Another Secret -- Don't Overspec!

There is more than one way to deal with the problem of a project that your customer cannot afford now.  This can be the subject of another blog entry here, but in short, the sales team should not be tempted to overspec a project.  Most of the time, a project is too expensive for the customer NOT because the customer couldn't afford the project, but because the sales team did not "ride herd" on the specs.  Shopping the specs around either the customer organization or your own developers will invariably produce a bloated and unaffordable laundry list of functions that are often not required.  Focus on the real business value at the core of your project and spec only that.  And more often than not, your customer will be able to build an affordable business case for a real business breakthrough!  You can add the bells and whistles later . . . and oddly enough the bells and whistles will be done better when you have the core correct!

Click here to see attached model Estimate.   The example is based on a real-life case.