Joe is bang on the money that enterprise IT has become so complex that startups are disincentivised.  With my CEO of Blue Prism hat on (we are not one of Joe’s big five), I thought I would add my thoughts to the debate.

Large enterprises like buying IT from large vendors.  Minimise the number of suppliers, and negotiate hard.  Reduce management and procurement costs.  Nobody really wants tangential relationships with small suppliers that might go out of business (or get bought by Computer Associates).

So enterprise activity, driven by corporate IT, has created rules and procedures.  A frustrated startup might think of them as guard dogs, fences, sentries and barbed wire, with the sole objective of keeping new vendors at bay.  IT calls this a supplier consolidation strategy and you can see why it makes sense on the face of it.

Even when a small vendor gets some limelight in a corporate account, they have to fund increasingly long and expensive sales cycles.  Free Proofs of Concept, deferred licence fees, an intricate (and near infinite) maze of decision makers to negotiate, and pressure from enterprise procurement to “recognise the reputational gain of working for us” – in other words drop price.

This is all bad for innovation because large vendors are not innovators.  They are not incentivised to innovate, nor agile enough to do so.  Quite the reverse.  So the enterprise actually loses out.  The lost opportunity of delivering real benefits by simply acting and delivering change quickly. Acting in this way may produce a small number of failures, but I believe that the overall benefit to the enterprise from increased agility and speed to deployment for the successful projects will more than compensate.

Nonetheless, startups need to acknowledge and accept that selling to the enterprise is much harder, much slower, and much more expensive than it used to be.  Investors have already realised this and diverted their funds towards companies in the Cloud, SaaS and virtualisation spaces because there is an apparent shortening of the sales cycle, partly by bypassing IT and selling straight to the business.  This leaves “traditional” enterprise IT startups struggling for funds, struggling for sales and struggling for recognition.

The good news for enterprise IT startups is, that it is now an underinvested space.  This, I believe, will create fewer but more exciting, and less competition bound, innovation opportunities.  In the end the economic case wins out.  If startups can find the most compelling of propositions, then corporate IT will ultimately adopt the innovation or have to find an alternative.  If I was investing right now, I would be looking for enterprise IT innovation.

Joe argues that most enterprises don’t have “anywhere near” the agility promised by SOA, cloud and Enterprise 2.0.  I agree that there is plenty of room for innovation and smart startups are the sparks that will create new fires in this space.

It’s amazing how much hard work goes into designing and building a website and, not least, writing the copy.  We have also taken some important design decisions such as dropping the prism widget from the logo:

Personally I quite liked the old prism and sorry to see it go, but I was the only one who held that view.  Democracy eh?

On more serious matters, working out who you are, who your customers are, and what the message that connects those two things is weighty stuff and takes time in the world of enterprise software.

We are not 100% there yet, but we are moving in the right direction and we are hopefully taking steps to look like a larger, more serious company as we are emerging from early stage into growth mode.

What used to worry me is that I expected to crack all these problems overnight.  Learning with our early customers, listening to them, getting independent people to listen to them, and taking a bit of time to think both introvertly and extrovertly has been most helpful.

Talking to customers teaches us not only about who we are and how to connect, but also enables us to examine how we deliver.

This is not just benefiting our sales team, but also our new customers coming on board, who can take advantage of previous experience, methodologies and working practices, and new ways in which Blue Prism software can be used.

The website is in final testing and should go live next week at www.blueprism.com.

Talking of website upgrades, I have moved this blog to a new ISP and upgraded to Wordpress 2.5.1 – big improvement!

Jacob wonders whether IBM can seriously launch into this space next year, as they state.

Imitation is the sincerest form of flattery and I welcome IBM’s efforts.  The very fact that they are even trying to enter the space, validates a market that it is very difficult for the smaller vendors like Blue Prism to build alone.

It’s just that things have been so busy, which has prevented me from posting for a while.  Lots of change going on at Blue Prism.  A new mood is emerging in the industries we work in.  In line, chronologically at least, with the start of the credit crunch, there seems to be a great deal more short-termism.  Capital budgets are being slashed, especially in IT.  There is increased demand for results PDQ.   Urgency is increasing.

As an enterprise software vendor you might think the IT budget cuts are a threat, but the opposite has occurred.  We fit in quite well to the new mood and our sales pipeline has never been busier.

Apart from sales (which is always the first priority) my time has been demanded on investment and recruitment matters, which anyone involved in running any sort of company will know is time draining, albeit highly interesting and often entertaining.  I hope to reveal more in due course, subject of course, to the usual array of confidentiality clauses

In fact Miami were no pushover.  Their opening drive, based almost exclusively on an aggressive running game, put them in a promising position only to run out of steam with a 48 yard field too much to ask in wet and windy conditions.

In my view both quarterbacks had stinkers.  Miami in particular, whose QB was appropriately named “Lemon”, managed to oversee 4 consecutive penalties at one point in the game when the Dolphins were otherwise in control.  Illegal receiver downfield; illegal substitution and (unbelievably) an illegal formation being amongst the crimes.

The Giants played none too well themselves with Eli Manning (QB) seemingly unable to hit the proverbial barn door with any form of stringed instrument.

It teemed with rain most of the match and even up in the second tier, we were getting wet.  So using the conditions as an excuse is plausible, and I am certain this contributed to the score being as close as it was.

When you are leading a team in a competitive situation, you frequently encounter turbulence.  Often it is the same for all sides.  Being successful is not about being brilliant at all times.  Sometimes it’s just about being better than your competitors, making small improvements and focussing on the apparently little things.  All of which reminds me of the old joke about the grizzly bear chasing two hunters.  One stops to put on his running shoes.  The other hunter laughed “you are not going to outrun a bear in those”, to which the first hunter replied “I don’t need to outrun the bear, I just need to outrun you!”

The Giants were not great but they were better than the Dolphins by a small margin in most areas and this saw them through.

By the way, on a sporting note, as a former linebacker for the Stockport Falcons, I did like the look of No. 52 for Miami, Clam Chowder (or was it Channing Crowder).  Sharp, energetic, aggressive, hard hitting and made a large portion of Miami’s tackles.  Man of the match for me even though I was supporting the Giants.

Looking back through our fault reports there was barely an issue raised in the last few months.  The IT people in charge of day to day running were reporting that everything was fine and “to specification”.  Yet the business users were reporting too many exceptions, not enough capacity, and functional issues.

Since our product is designed to be flexible and offer the agility to adapt quickly to new business requirements, this was highly embarrassing.

Turns out that the problem is that the business requirements have moved on, some of the people have changed who did not understand why some of the original design decisions were made, and when the business users asked the IT dept why the system didn’t do exactly as they wanted, they were told it met specification ,and that exceptions and responses were within SLAs.

The lesson I learned from this is to understand who your real customers are.  In enterprise sized companies this is often extremely difficult, but talking to the business users of the solution is always a good starting point.

One of the advantages a vendor solution has over an internally built one, is that the vendor is normally a specialist in a specific area and brings the benefit of working with many other organisations, hopefully with the expertise gained having been internalised into the software product.  Here we fell into a hole on this occasion.

I am so embarrassed, that I have scheduled a free review by one of our consultants, to reassess what the current problems are and what options there are for improvement, a redrafting of the business requirements as it were, not just in relation to our product, but the whole solution.  Then maybe we can get the IT spec changed to match?  And maybe that spec can include some flexibility to meet changing business requirements of the future – D’Oh!

In this post he comes across as an exhausted inventor who has finally seen his new gadget rolling off the production line.  It is hard work launching an enterprise software company.  I know because I have tried it.  Many of Ismael’s comments could apply to Blue Prism equally.  The issue of market timing resonated in particular.

Does this mean that there is a degree of serendipity about the chance of success?

I wouldn’t pretend for one moment that Blue Prism has yet reached “success” whatever that is (and it means different things to different people).  Like Ismael, I am very encouraged by progress, especially in the last 6 months, albeit the first version of Automate was released in 2004, some 3.5 years ago and, let’s just say that meeting our revenue forecasts was much harder than anyone expected.

It can be lonely at times as a Managing Director (try not to weep).  When I used to work in a bank as a middle manager I had any number of peers I could relate to, and discuss ideas and issues with.  Since that is no longer a route open to me, I try to find peers outside the company.  As a result I know quite a few people who either run (or used to run) enterprise software companies.

This got me thinking.  What are the key characteristics that determine a successful MD or CEO?  Obvious requirements that might spring to mind might include:

• A keen aptitude for marketing
• Technical vision
• Ability to inspire people
• Financial astuteness
• Ability to sell
• A propensity for making customers happy
• The gift of the gab

Looking across the successful people I know, the most important characteristics are none of the above.  They are energy and determination.  Fortunately, both characteristics that Ismael has in Spades.

I think blogs should represent the views of the author and that there should be a single author.  However, you may recall me saying that Dave is the “techie” I respect the most of all I have met.  So having read his first effort (below), three comments sprung to mind:

1. I totally agree with his views in this instance and, therefore, since they exactly match my own, I am happy to put them on this blog in my name.
2. Dave is one of those rare CTOs who has acute commercial focus and places the highest emphasis on customer need, when evaluating product development objectives.
3. The writing is in Dave’s hand and his analogies stink!  So I refute responsibility for the way the message is communicated.

Here is Dave’s post:

Alastair has been gently pushing for a guest blog from me for while, and I’ve resisted up until now.  But a discussion during a recent scoping workshop with our development team has prompted me to put keyboard to blog as it were.

We were talking about the various stages of product development and the challenges that designers face during each stage.  The stages of product evolution are closely tied to the evolution of the company that is developing the product, but different challenges are presented to the ‘engineers’ than to the board.

Let me dive in and share some examples – at this point I want to row across to analogy island (private joke) and imagine my product is a fruit.

New products, like growing fruit, are full of potential not yet ready for consumption.  Innovators have a vision for what their product might become, and a few forward thinking consumers jump on-board, accepting the faults and gaps in functionality, because the new product is ground-breaking.

Over time (and the length of time depends on the number and quality of the team and the commitment of your innovative “early adopters”) the product becomes market ready, the gaps are filled and so are the promises – the product delivers and the customers are happy.  My fruit is ripe.  Still rowing?  Good.

The challenge that we face now (and after a number of years of development, refinement, delivery and further development our product is definitely ripe) is how to prevent the product (or fruit – I think) over-ripening.

The temptation as designers is to continually push out releases, adding the bells and whistles that everybody asks for without major steps forward.  This inevitably leads to over-complication – more configuration than execution – and a product that still does what it did in the beginning – is static – but is so feature rich that nobody can find anything anymore.

Within our development database, fault reports that start with the phrase “Wouldn’t it be nice if….” are invariably early warning signs of bloatware approaching.

But in software, what you can’t do is freeze the fruit, or can it, or dry it or whatever you do to fruit to preserve it.  Apologies – my boat has a leak somewhere.

Each release has to push the boundaries and implement the next innovation - the next idea, the next step forward, without over-developing the software.  The objective is to keep the product ground breaking despite the passing of time and also to keep your competitors – who have seen what you have done – at bay, giving customers more reasons to buy your product.

That’s my challenge at the moment; we can all see software products – some of which you might be using now – which are full of so many requests for functionality from different audiences that they are over-ripe, past maturity and no longer what they once were.

That’s one of the later stages of product maturity, however, and we’ve still got several ideas that will keep our fruit ripening in the sun for a while yet.

We’ve reached the island……for now.

Dave Moss

Why is it so hard for small companies to sell to enterprise customers?  Ed French has an interesting insight in relation to vendor financial stability, and the high failure rate of enterprise implementations generally, pointing out that:

“A vendor that’s still around for a project that failed is perhaps no more useful than having a successful implementation where the vendor has gone out of business!”

However, financial risk is only one of many buying criteria and, whilst this is largely outside the control of the vendor, other criteria are more addressable.

Decision making in the enterprise is so much more complex than for individuals or SMBs.  Small ISVs need to understand that and make the buying decision easier for the customer.  This can relate to pricing to match budget mandates, breaking down projects into smaller pieces, running a cheap pilot (hey guys its really tough for small companies to do free pilots!), providing case studies and reference site(s) and working hard to understand the enterprise’s mode of action and priorities (growth/maturity/defence/cost cutting etc).  Finally small ISVs have to pay even more attention to building personal relationships that lead to trust.

If you are interested in tech investing, run a small tech company with growth ambitions, deal with VC backed companies, or just interested in tech trends, check out Ed’s blog at http://techgain.net/.  Ed is one of very few UK VCs who blog and for the purposes of disclosure, one of his funds is an investor in Blue Prism.  That’s not the only reason I subscribe to his blog though!