Recent experience of working on a start-up MVNO contrasts sharply with some previous experiences in larger companies. The noteworthy difference is the ability to get things done in the former, whilst the aim of the latter often seems to be to prevent innovation and progress.
This is a generalisation, of course, but large companies are usually big bureaucratic machines and this usually gets in the way of actually getting things done.
As an example, in a recent start-up MVNO, during one of the project meetings we identified that we needed a secure FTP server. I added it to my to-do list and, later that week, it took me about an hour to build, configure and test the server, and another hour to document what I had done.
Compare this to a previous MVNO project I worked on for a large company: when the need for secure FTP was identified there, roughly 10 people were then involved in various discussions over the following months about how to achieve this. I estimate it burned more than 30 man-hours just with people discussing what we should do about it at a project management level.
Of course, I offered to build one for them but “that’s not how we do things here” was the, not entirely unexpected, answer.
Instead we spent dozens of man-hours debating what we needed, and which of our “partners” we would ask to do it. Subsequently, I then was tasked with writing a requirements document (about an hour of my time), and getting it reviewed and approved by people who would struggle to understand it yet alone be technically competent to review it (probably another 4-5 man-hours including my time chasing people for sign-off).
After receiving the proposal from the chosen partner, it needed reviewing and debating (approx 10 man-hours) and several man-hours of bureaucracy to get the out-of-budget spend approval, and the purchase order raised. Then this was discussed again at subsequent project meetings because the delivery had to be fit into the project plan and tracked (probably another 20 man-hours).
Finally, I had to spend several more hours reviewing the proposed solution, testing and, ultimately, the test results.
All in all I estimate that this project to install a simple FTP server consumed more than 80 man-hours of the company’s resources, the vast majority of which were people who did’t really know what an “FTP server” was or why we needed one.
Including the direct cost to the project of outsourcing the server design and build to the partner, I reckon this piece of the project cost the company in the region of £100,000.
Of course, one of the reasons start-ups are so nimble is because they tend to employ people who are good at doing things. This isn’t the culture at large companies. In my view this is because, in large companies, technical competence is rare and what does exist is eventually beaten out of the staff by the big stick of bureaucracy. This stick is usually wielded by people who lack any technical skills themselves.
The big problem here is the belief that everything can be fixed by adding more bureaucracy.
In other projects I heave heard senior managers demand that more project managers are assigned to big projects which were already bogged down by having too many project managers. A sure sign that a project is in trouble is when managers start saying it “needs more governance”. I have worked in projects where there were four project managers to one Engineer; more than 50% of the Engineer’s time was taken up engaging with project managers!
Of course, project management and governance are important and are the hands on the tiller that steer a project, but the big mistake many organisations make is to think they are the engine.
The real engine of any IT project is the Engineers that design and build the systems, who actually write code, set up networks, install, configure, and integrate systems. Everyone else should play a supporting role to those functions. If your IT project has more project administration people than Engineers, then you are doing it wrong.
Until large organisations start to realise that and start building and supporting “engine” resources of their own, they will continue to haemorrhage money and have a high failure rate on projects.
Leave a Reply