Blog: The route to Open Source – case study of a $1m failed development project!

There are some stories you can only tell after the event – to protect the living, so to speak.  This case study is part 1 of Sift’s route to open source.

On face value, one of the key attractions of using open source software is that you don’t need to write or maintain a proprietary code base; and there’s (in our case) a Drupal module that can be used as at least the startset for even the most esoteric client requirement.

The real benefit though is quite different.  It’s the ability to move the conversation away from what the technology can (or cannot) do, to what would be a good idea for a client’s business.  That means one is a consultant and business partner first; technology partner second.  A good place to be.

Read no further if open source is axiomatic; unless you’re up for some schadenfreude from Sift’s Norwegian .NET adventure.

What happened?  What were the ingredients?

1. At a team event in late 2002, soon after I became CEO, we decided we needed to rebuild our original Perl-based SiftGroups platform, which contained the community, commerce and content modules used by our Sift Media and SiftGroups businesses.

2. We hired a new Technical Director in March 2003 – one of his main tasks being to help bring the SiftGroups2.0 project to fruition.

3. Momentum developed slowly until in August 2003 we had a tech strategy day.  The team was very keen to rewrite things in Perl.  They knew what the deficiencies were, and were passionate and committed about their ability to improve it.  At the meeting I showed support; and I remember concluding at the end of the day that as we were delivering an ASP solution (as SaaS was called in those days), the choice of platform didn’t matter as long as it worked for clients.

4. But the signals we were picking up from the market at the time were that .NET & Java were gaining significant ground in the larger businesses we were aiming to sell our solutions to.  In particular, we’d recently lost a major pitch for Motor Cycle News for Emap.  Another major client BT was saying that they wouldn’t renew unless we had switched from Perl.  Remember this was a time when people were talking about web solutions having a much longer life than is typical now, and before it became accepted that you could use APIs between quite different applications effectively.

5. We therefore decided as a board to go against the team and in Sept 2003 announced that .NET/Java would form the basis for the new platform.

6. We then evaluated the options.  With few of the skills in-house, we compared the costs of outsourcing the development, to finding a technical alliance partner.  The figure bandied around was £300k to rebuild ourselves – not completely prohibitive at the time as we had £1m in the bank – but not attractive as partnering with someone who already had the basis of what we needed, and way less risky.

7. We started talking to Digimaker in October 2003, a Norwegian company, who were transitioning their Microsoft based CMS to .NET and planning to add the community and content modules that we needed.

8.  Although we’d made no formal commitment to Digimaker, by the end of 2003, we sold FT a Digimaker-based solution for their FT Adviser site; and also that winter sent three of our engineers to Kristiansand in Southern Norway for three months to help finalise their new product.  Sorry guys!

9.  As an aside, the new Technical Director left Sift in December 2003, following some ill-advised personal remarks he’d made on his blog!

10.  At the time, my co-founder and I were dysfunctional and our investors weren’t comfortable.  We couldn’t decide whether we were in the publishing game (our Sift Media publishing business primarily reliant on advertising revenues) or the web solutions business (SiftGroups) favoured at the time by the investors and some of the board.

11.  In March 2004 we were approached by an Oxford based company wanting to acquire Sift.  Personally, I wasn’t terribly interested, but over the next few months as they pressed their interest, most of the remaining shareholder base were keen to exit; so eventually, on the basis that it would also have resolved the intractable founder issues, a deal was struck (externally and internally) – at a price above £10m.

12.  Meanwhile the new site for the FT went live in May.  Until I started to research this post, I’d wiped the memory bank of the full horrors of the situation – a flavour:

• We committed to a delivery date for a complex solution for the FT on a new platform without any genuine confidence the product would be finished;
• Core development work being done on the live FT test site;
• Every instance of Digimaker in effect a different version of the product;
• People in Norway, India & the UK all working on things without effective code vault systems; and
• FT’s bewilderment as features that had been fine stopped working when a new version/module was released elsewhere on the site.

13.  In June the acquisition failed one week before completion.  We still hadn’t formally committed to Digimaker.

14.  On the 29^th June 2004 we finally committed to Digimaker, paying £400k for a 27% stake.

15.  My co-founder left the company in July 2004.

16.  By the September 2004 board meeting, we listed the issues with Digimaker as follows:

• Lack of pre-sales support;
• Our inability to deploy new sites without assistance from Norway;
• Problems with their development methodology; and
• No roadmap for the product.

17.  A month later we were planning to fall back on our legacy platform (which we’d been using for clients all along – FT were the only client on Digimaker).  By then Digimaker had also dropped their plans to add community and collaboration modules.

18.  Jan 2005 we hired a new CTO (and this is when part 2 of the case study will start).

19.  Our stake in Digimaker was diluted to 12% following a further funding round in March 2005, and wiped out completely a year later at the next round.

Added all up – the investment and the time spent building a product for someone else that we never used, the time spent by all the staff in Bristol dealing with it all - you easily get to $1m!

On the one hand some mad bad decisions, but like all corporate train-crashes also logical in part.  The fact is a number of skilled and experienced business people were involved.

What went wrong?  What did we learn?

1.      A strategic 27% investment in a software development partner doesn’t give you the control you need

Even though we sent over three engineers to work on getting the Digimaker product finalised, we couldn’t influence the architecture, coding practices or product direction in a meaningful way.  Even as a board member, I struggled to have any influence.  I was one of 5 on a Norwegian board grappling with accounts in Norwegian, different accounting practices and I had no idea of the particular agendas of the other investors and also felt conflicted between what was right for Digimaker versus Sift.

2.      It’s never too late to say no

By the time we finally invested in June 2004, we’d had the guys over in Norway the previous winter, we’d had the initial experience of working with Digimaker on the FT Adviser project and we could see the desperation as they tried to close their fund-raising.  Did we bring all the team into a room and sanity check the final decision to consummate our commitment?

The hell we didn’t – we felt part obligated, part paralysed by having no other options and in large part we didn’t debate it properly.  We could and should have just said no!

3.      Listen to loyal staff

The engineers had spent six months working with Digimaker.  The project managers had grappled with the FT implementation.  They knew we were making the wrong decision; and they tried to persuade us we were making a mistake.  We thought we knew better!

4.      Dysfunctional teams make bad decisions

We were dysfunctional as a board, and didn’t have an effective SMT; and my co-founder and I were both behaving as if we ran the business.  In turn, this meant we disenfranchised the senior members of staff, and didn’t properly involve them in debate.  Plenty of times through the course of the year a good SMT would have either stopped or retrieved the situation.

5.      Don’t do a bad job for a Tier 1 client

Although the FT site went live only a few weeks late, it was never stable and their dissatisfaction over time just mushroomed.  Surprise, surprise, we didn't get a sniff of further work from them for a good while. A Tier 1 disaster.

6.      Solutions matter, platforms don’t

I need to write part 2 of the story so you know what happened from Jan 2005 until Nov 2007, but from the time we first identified a need to build a new solution in December 2002, it wasn’t finally until February 2008 that we delivered a project on a new platform!

It wasn’t because we didn’t win customers.  We just kept on using our tried and tested platform (of course with some development), focusing on delivering successful and innovative web solutions for clients.  Of course, that isn’t to say that any old platform will do.  Sift’s legacy platform was certainly clunky by the time it was retired from service.

Conclusion

This story is told in a spirit of openness and catharsis.  I think I can safely say everyone involved (most of whom no longer work for Sift) learned a lot from the experience.

Ben Heald – 15^th September 2010