Hi All,
I'm doing some research at the moment on how to sell development, and wondered if you would add your experiences.

Looking in particular at comparing the "traditional" model (Sales people propose solutions to customers, quotations are produced, Orders received, the project is managed and the product delivered then paid for), with the iterative techniques where the development is supplied more as a serviced, prioritised by the customer throughout development (such as Agile software methods).

I have a theory that the sales process and the constraints that are imposed on the project by it can have a huge influence on the success, delay, or failure of a project, but most development methods I have worked with avoid discussing this part of the project.
So I'm interested to hear your views?

Many Thanks
Nick

The biggest problem in selling development work is usually that the specification serves to translate between the world that the buyer understands and the world that the developers understand.
In software this is particularly difficult as there is nothing tangible that most non-expert buyers can actually understand. Likewise, helping developers understand what a buyer actually wants to see on a screen or a report is equally difficult.
Add to this the pressure that most sales people are under to achieve targets and the fact that in many cases sales people cannot begin to understand the complexity of what is being sold, and you end up with projects that fail (not necessarily just technically, but financially, timewise or quality)
Agile tries to address this by undertaking smaller faster deliverable cycles, but for most buyers this must appear to be the same as writing an open cheque.
The critical issue that then underpins the process is who accepts the risk. Buyers want fixed price contracts or at least capped ones, suppliers respond with specifications and acceptance procedures that (if managed properly) protect the supplier, but do little to help the buyer get what they want.
In short, I don't believe that the constraints are in the sales process, but in the way that development projects are defined and specified in terms that few single individuals can actually understand. The result is mismatch in expectations between everyone involved.

Thanks Martin,
I agree totally with you, but do you think that maybe extending the development method formally helps buyers and sales people to get a better solution. I know some businesses for example, who create a structured pricing system which enables the customer to choose the extent of risk they take in the time domain, by charging more for short time-scales.


Many thanks to Alan as well.
I have also seen this on a number of projects, as specifications (of many pages) often miss out the things the customer considers normal, but the supplier has not considered.
Would this be a good sales argument for an agile style of development, which allows for modification to the specification?

Edited: 04 October 2010 at 06:51 PM by virnik

Clearly the whole point of doing an Agile style development is to get deliverables to the customer as soon as possible to avoid misunderstandings. For an educated buyer I can see that this is a selling point. For a less educated buyer the sales pitch that points out all the risks in development that leads you to using Agile might be off putting.

You're right; there is a balance to be drawn when presenting risk and that judgment is typically made by the sales person.

I suspect many projects are presented as linear projects in the sales phase, with both the buyer and seller knowing that the project will change significantly in cost, time or direction. The risks are then offset one way or the other by implementing sufficient phases, project change mechanisms and document sign-offs at the project stage.

I see Agile as a more honest and efficient approach, but, as you say, honesty may not be easy to sell.

Sytems Engineering suggests customers only express a fraction of the true set of requirements - usually non functional performance or systems type requirements, and hardly ever pur functional requirements. Other requirements may just be assumed (ie the customer thinks they are so obvious they do not include them, they just assume the developer knows them).

Agile is fine, and introduces a learning system where customer and developer work much closer together, but getting customer experts time is always difficult, nobody has slack in their organisations anymore. Also agile can suffer from a lot of scope creep, especially as the customer learns what they could have when you deliver incremental functionality. You have to mange your time-boxes very carefully.

Also, injecting new technology into an organisation will involve change (it can either be emergent and unpoleasent, or it can be anticipated and planned for). Injection of technology without change delivers no value. The change aspects are often not even recognised which has lead to many many projects failing.

Charlie

There is one way only to get real understanding of requirements and that is through true trust and partnering with open communication. This is seen by most as the nirvana that will never arise.

We have operated for many years with the outlook of having that competitive edge and minimum cast over those of competitors. Think back to the story of Hoover; are they in business to make good vacuum cleaners - or make money?

Through many initiative such as TQM, lean etc we have not seen much progress. As an example of this thinking, take the statement above, mentioning "assumptions" by both parties - customer and supplier. It is only through good communications and trust that all stated and implied requirements, along with risks can be fully explored and understood to arrive at common outcomes.

Thanks all for your replies.
I think scope creep is not a problem, with a full Agile development as it is the customers choice to change the project, and frequent deliverables may enable the customer to start using the product prior to all the backlog being complete. If the customer wants to continue development for twenty years, I'm not going to stop them provided they are paying for it.

The amount of resource the customer is willing to put into the development in terms of meetings, or testing the iterations would be a significant barrier to full agile development.

It's a good point that any successful project relies on trust and good clear communications, without these projects are doomed to fail what ever method is employed.

Nick

Hi Virnik

I think I would separate out 'sales' and 'the processes' used to gain and secure contracts - the two aren't the same thing. Selling can be internal or external to the organisation and could range from getting buy in from a stakeholder over a cup of through to signing a contract for a multi-million deal.

So I think the issue is whether contractual processes get in the way of delivering. The short answer is probably yes but they are there for good reason and the question is what level of process is appropriate because the process is not just trading off TCP of a project it's also mitigating financial risk - through complying with legislation, levels of sign off, project risk, resource management, financial margins, business strategy add addendum).

Stuart

www.virtuallyperfect.org