How to destroy your corporation in 1024 easy steps
My take on projects in ye average bigge organisation has been: the price of a project depends only on the position on the corporate ladder of the manager who starts the project. The lower the level of the manager, the cheaper the project.
Please note that delivered functionality or business value is not part of the ‘project cost’ equasion…
I have often wondered about, and looked in amazement at these large projects that seem to go on forever. I believe that most projects can be done with less people in less time, and many projects are not worth doing at all.
Maybe someone at <insert large ‘consultancy’ company here> did actually invent a working perpetuum mobile…
Read what a (former) big shot in a large company writes on how this mechanism works in practice, and what it feels like to be on the receiving end. How to destroy your company by packages, outsourcing and ‘consulting’ companies (and not paying attention to your users and customers)….
“Outsourcing is a brilliant trick of the managers. The responsibility for the failing project is moved to an outside vendor. They are now the object of aggression.
The real customers don’t talk with the programmers. They talk with the managers that are talking to managers that are talking to managers. Somewhere in the chain of communication all the meaning is lost. The result is something they don’t want, the users don’t want and the customers don’t want. Last but not least the process took so long that the market has changed. They have to start all over again.
Do you now understand why we there is such a shortage in IT specialists? About 30% of IT-projects is succesful. This means that 70% of the IT-specialists are working for nothing.
My advice
Adapt what is working as long as possible.
A team of 15 people is capable of doing more than a team of 1000.
Do it yourself.“
Hans describes a full circle process of what happens before a project is outsourced. I call it the “Shit” cycle I couldn’t resist making a drawing of it:
I missed one phase in the process: the pre-project phase, which consists of a sales rep of <insert large ‘consultancy’ company here> taking the high-level manager to the golf course…
What I don’t know is, each time the project goes through the cycle again whether golfing is required (Hans writes about one project that cycled for ten years…).
September 14th, 2007 at 5:52 pm
“The price of a project depends only on the position on the corporate ladder of the manager who starts the project. The lower the level of the manager, the cheaper the project”
There can be several reasons why this tends to happen. For example:
a) Managers are often evaluated by the size (generally measured by budget rather than output) of the projects they’ve worked on. This creates an incentive to make projects with big budgets: it’s the route to promotion. (If you’re clever, you get promoted and move on before the project fails…) Architects and developers collude with this, because working on big projects also looks good on their CVs.
b) Only managers who are relatively high up the ladder have the authority to authorize large projects.
c) Price scales very non-linearly in some dimensions. 99.9999% availability is a lot more expensive than 99.99% availability. People with a broad scope of control (i.e. people higher up the ladder) often care more about these systemic attributes, because they can see the wider effects.
(a) is pathological. (b) can be OK: it’s reasonable that decisions that commit more resources should be made by more senior managers. (c) just makes life interesting.
I hear the message to keep the team small, and mostly agree with it. However, I also have a gut feel that some worthwhile projects actually are quite large. (How about the NASA moon landings?) They’re more risky, at least partly because of their size, but they’re still worth having a shot at.
I like the maxim that we should make things as simple as possible, but no simpler. Sometimes starting with too small a team also leads to problems — I’ve seen small teams that made a mess of things because they lacked specialist domain expertise that might have been present in a larger team, or because they tried to cut too many corners.
As well as looking at team size, we also need to look at
a) how to we ensure we measure project size by outputs rather than inputs?
b) how do we ensure that there is appropriate scrutiny to ensure that organisational (or taxpayers’) funds aren’t being spent simply to massage managers’ egos?
I suspect getting these things right would probably eliminate at least as many failures as simply setting a simply rule about the optimum team size.
Graham
September 15th, 2007 at 11:16 am
[...] Yesterday, Hans Konstapel shared a story ( How to Destroy your Company by Implementing Packages or Outsourcing) Marc Evers responded to it, I responded to it, and got a gift in return… Graham Oakes posted a thoughtful comment that would merit a proper post – I call it “three reasons why project price depends on corporate ladder position”. [...]
September 15th, 2007 at 11:29 am
Hi Graham,
thanks for your reply… Great stuff! I see a) quite a bit. Part of the reason a) looks good for developers, is that (apparently) it is cool to work on complicated stuff (instead of creating simple solutions, but no simpler, as you say). a) Managers often like the status that goes with ‘having many people report to them’ – it makes them feel important.
b) does make sense. I wonder how many managers who are at b) and understand it create projects orders of magnitude smaller than what they could create…
Some projects (e.g. the moon landings) are difficult to make small(er). However, large projects do not necessarily have to mean tons of hierarchy and locking the customer/user out (as Hans Konstapel says ‘they talk to managers who talk to managers who talk to managers
).
In some banks, for instance, projects tend to be larger than they need be, with much too much hierarchy – for instance, as a developer, you are not allowed to talk to the users, because you have to go four layers up to find a development manager who can talk to a business manager…
Like you, I also have seen small teams that were, well, too small in some way. Sometimes as a result of (business and software) people lumping ‘customers’ together to use a ‘common platform’, when the customers did not have much needs in common… You can do that if the ‘customers’ are a captive audience…
As far as the NASA goes, their projects seem to have benefited enormously from budget cuts… They finally got around to make smaller landing devices, use open source software etc. NASA projects are now ‘smaller’, and still quite entertaining.
And you are right, looking at outputs is probably more effective than setting rules on team size (or maximum budgets). Getting an organisation to look at results is… an interesting challenge
September 15th, 2007 at 11:34 am
Oh eh, just to clarify. I mean that larger projects can be done with less hierarchy (e.g. setting communication up so that people from project teams talk directly to their peers, rather than up-and-down through management layers, with all the distortion that goes with it).
Willem