Regrettably, not all do succeed. Many have particular problems with the IT implementation which is sometimes the cause, but more often I think the symptom of the underlying issues. Start-ups have certain characteristics, which are both the nature of the beast and also the source of problems with the IT requirements.
Firstly, they are almost always developing the IT infrastructure before the business has determined in detail how the network will be configured and managed or how the launch products will be defined. This is because to set up significant IT infrastructure generally takes as long as building a core network, and longer than creating products and services. This means that significant architecture and design decisions are taken before all the data impacting that decision are known.
Secondly, since the company starts from a base of no staff, there is almost no-one to be involved in detailed planning of business processes, whether the products will be sold through resellers or retailers and if so how to engage and remunerate them, how the logistics around supply and sale of handsets/SIM/routers/numbers/etc (delete as appropriate) will be managed, and so on ad nauseam. Therefore once again the IT infrastructure starts out in a certain direction, and too often the business later decides on a different course, with consequent impacts (not always taken into account) on the IT build programme.
Thirdly, business plans made well before launch have a habit of being adjusted the closer to launch you get. Suddenly, volume assumptions about wholesale vs. direct, business vs. residential, self care vs. call centre, in house processing vs. external - the list is again endless - get thrown on their head, and you find you have either too much or too little IT capacity (sometimes both!). More pertinently, you may find sudden adjustments in Capex or Opex budgets which significantly compromise the IT support you can deliver to the business.
And fourthly, start-ups have a habit of changing their ownership during the run up to launch, as funding needs necessitate new investors with an incentive to investigate how their money is being spent. Often these investors have strong preconceptions about how the infrastructure should be architected - for example, corporate policies about specific suppliers, perhaps a new requirement to converge solutions with other group operating companies - and you may find at best a distraction from the build issues, at worst a major reappraisal of direction.
I have therefore come to some simple principles to help guide IT delivery for a start-up.
- Design the functionality as openly as possible, and keep it all simple, basic and targeted on the major volume transactions. Requirements will change, so be ready to go in different directions. Complexities and automation for the exceptional transactions can be added later.
- Design the architecture so that the systems are scalable, but build the initial configurations for the early volumes - resist the temptation to build for 4 years out on the basis you have the capital available!
- Define and use the change management process from the earliest days.
- Set up and use rigorously one tool omitted from the Prince2 methodology, but in my view essential for such projects: an Assumptions and Decisions Register. You will certainly have a conversation with someone very senior and new to the organisation, probably about a month before launch, along the lines of 'Why on earth did you do it this way?' You will, I guarantee, need to produce your record of all significant business and design decisions or assumptions, who endorsed them, and why.
But despite these trials and tribulations, if given the choice between mature organisation and start-up, I would prefer to work for the start-up - they are just more lively and more fun!
No comments:
Post a Comment