We were delighted to have a short piece on CIO best practice published in the March issue of CIO Magazine. Here's what we said:
Just like starting over
Running the information needs of a hot new online company may be attractive, but there are plenty of pitfalls to watch out for on the road to success
Online startups are on the rise, springing up around the country despite the credit crunch. With “Silicon Roundabout” firmly established in London's Shoreditch, there's more support than ever: the new online Dragon's Den, networks like Smarta and “Entrepreneur Country”, post-boom microfunds and virtual incubators such as Betaworks and Reincubate.
The startup CIO must operate differently from a typical CIO, and one of their first decisions will be around “build vs. buy”. “Buy” – or rather, outsourcing parts of the platform to an agency or partner – can be very appealing to a startup.
“Fail to prepare, prepare to fail” is often applied to outsourcing, but startup CIOs should heed another mantra: “fail fast”. Uncertainty abounds in their operating environment and CIOs should aim to make failures apparent rapidly, and before too much money has been spent. CIOs should be wary of Stockholm syndrome, where they find themselves starting to defend inadequate partners from their own businesses.
Outsourcing well requires experience, and all the more so for low budget time critical projects. Typical outsourcing best practices are not well-suited to startups, and most of the agencies within reach of a startup are more used to working with established businesses. With untested business models, few staff, and little time, how can startups create a strong, trusting long-term relationships with outsourced partners reliant on their revenue?
Success with the initial business plan is rare, and with many pre-revenue companies changing their strategies or products three or more times before they get to market, it is sensible not to commission projects fixed scope in entirety from the word go. VCs typically expect a successful exit from ten per cent of investments, and success on the part of the startup will radically – and often unpredictably – change requirements. Without a terms in the contract to change tack, the agency project manager might step back and allow the CIO to work directly with agency staff. This can break down methodology and muddle specification ownership. Close communication is vital, but CIOs should be aware of the risks of their CEO distracting the partners with talk about phase two when phase one is still the objective.
Alongside limiting the scope of projects, prescriptive technical specification is important. Agencies may be able to deliver products are that are beautifully search optimised, for instance, but may only do so where explicitly specified. Stakeholders should specify platform metrics to avoid costly or inaccurate data-mining processes. Web and user metrics are common, but there are also likely to be operational metrics that will be reported to investors, or which are key to monitor business performance.
Most UK PLC CIO's aren't at risk of bankrupting their companies if a project overruns by fifty per cent, and it's not uncommon for CIOs to renegotiate with suppliers or their board, weeks or months into a project. It is a lenient seed investor who will keep confidence in the startup CIO who admits they have underestimated core costs so significantly. Milestones will change rapidly, and investors need CIOs that are cognisant of the chance for unplanned technical cost.
Outsourced partners may want to work with their metrics rather than the CIO's, and are often keen to avoid specifying an effective man-month cost. This complicates tendering, and getting partners to report against the startup's own metrics is an important principle. Day rates of £600 or more are standard for many businesses but will rapidly cripple a startup.
Micro-proofing – or building inexpensive prototypes as often as possible – is a sound principle. Prototyping is cheap, helps the business to learn more about what it really needs, and can be a good benchmark for quality and cost-creep from the supplier. Startup CIOs would be well advised to double any supplier quotes involving more than customisation of an existing platform.
Delivery quality management is hard, and there is no substitute for robust due diligence. Vetting potential partners to find which are agile and follow best practice can save some unpleasant surprises later on. CIOs should cast a wary eye over partner methodology at the outset.
Outsourcing a project doesn't mean the CIO can just let partners “get on with it”, and an experienced technical person following the build and chasing agencies will be more likely to get results. A remote third party can often be found to support the CIO, should the partners be overseas.
To hasten delivery, the partner may customise an off-the-shelf product to address the project, adapting Open Source or customising a proprietary product. The CIO should determine whether the agency's choice is objectively the best fit, or if they chose because it either fits their other project work, or is a new technology that they would like to learn. Smaller startups should be wary of CMS platforms being shoehorned into ill-fitting “one-size-fits-all” solutions. Secure, robust solutions will not be delivered without the right components.
Less experienced CIOs might struggle not to get caught up with low level technical specifications, losing sight of the business need and investor's requirements. CIOs may find their CEOs or board have made assumptions about the technology strategy which are not made explicit, and even the need for developing or retaining technical IP can be unclear.
It is important to recognise whether the agency will be developing a product that the customer will own. If not, there may be a perpetual license or ongoing licensing cost. With a poorly worded contract, we have known some agencies to bill for a full “build” project, only to deliver a “perpetual non-transferable license”. The investors have subsequently fled.
CIOs need ask a number of further questions of their partners: if the project is being built for their ownership, is it being built on a proprietary framework? Is the partner offering escrow on the source code of that framework in the event of the agency's liquidation, and could it realistically be managed if that happened? Is the software being built using servers or software which could introduce additional licensing cost if hosting providers were changed?
One of our clients had outsourced work to Pakistan, and whilst looking at the publicly accessible development servers of their partner during our due diligence, we found we had full access to a variety of highly confidential documentation from their other clients, not to mention a full, unencrypted database backup of a UK retail business' customers.
Serious security failures like this are uncommon, but failure to comply with relevant legislation is surprisingly prevalent. Even if the partner had secured their servers, the fact that they were storing complete sets of user data outside the EU sets them in breach of the Data Protection Act, and their storage of customer billing details breached PCI-DSS (payment card industry) regulation. The customer's site did not comply with the updated Companies Act.
Where CIOs offshore and manage to secure tantalising sub-£1,000 man-months, most partners will not follow their business' legal and regulatory constraints.
Finally, partner contracts should model what would happen when only some of the functionality is delivered, and consideration of what defines a successful implementation is important. An agency may feel that they have delivered ninety per cent of the functionality, whereas the CIO may feel he has only fifty per cent of the tools he needs.
Web startups can fail catastrophically with immense technical complexity when poorly managed, and with best practice, methodology and specification being discarded. They can be left with a mess that is far from the expected delivery, with the cost of making good unclear or beyond budget. Partners may offer to write off invoices in exchange for equity, or a commitment to further work being put their way, but it is a desperate company that signs up to this after a project failure.
Being well equipped to engage at an early stage can make a startup CIO. The role is not for the faint hearted, but with careful planning it can be immensely rewarding and can propel the CIO into new career heights – or early retirement!