I often say that many companies are software or technology companies, but they just don’t know it. This crisis of identity causes them a lot of trouble. Simply stated, those who got their management stripes in a none-complex environment will struggle in, and of course hinder, a software development project.
Why? Software is a complex endeavour, meaning that cause and effect are not clearly related. Complex is different to complicated. In a complicated system, cause and effect are clearly related. My dad, a builder, worked in a complicated domain. It required skill but there was a logical ordering to his work; the foundations preceded the supporting walls; the supporting walls preceded the ceilings; etc. There was, more or a less, a straight line between beginning a new house and finishing it. (Which is why he could give accurate estimates that he, to my knowledge, never got wrong.)
There is no such straight line in software. An actual software project is more like a science project, its nature is one of discovery, which is why software projects are so hard to estimate and many fail completely. In an IEEE article, entitled ‘Why Software Fails’, the following reasons are given for failing projects:
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project's status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project's complexity
- Sloppy development practices
- Poor project management
- Stakeholder politics
- Commercial pressures
This may as well be a list of ‘classic mistakes a none-software company makes’. Let me pick a few, more or less at random.
Software projects are creative, and their problem and solution co-evolve together. Cross and Dorst say this:
It is widely accepted that creative design is not a matter of first fixing the problem and then searching for a satisfactory solution concept; instead it seems more to be a matter of developing and refining together both the formulation of the problem and ideas for its solution, with constant iterations of analysis, synthesis and evaluation processes between the two ‘spaces’ - problem and solution.
Those foolish enough to try and fully articulate the goal of a software project only demonstrate one thing, they don’t know what they are doing.
You can’t estimate in a complex domain. You can only test and learn and refine the expected deadline as you go along. Could an explorer have estimated how long it would take to get to the new world? No, because he didn’t know where it was. It was a journey of discovery.
Poor Project Management
What is ‘best practice’ in none-complex project management? Gant charts and interdependency planning. Is that best practice on a software project? No, it’s worst practice because it will stifle discovery and momentum.Those who think that linear, factory based planning on a software project will work are missing the point. Applying it is an example of ‘poor project management’.
How can ‘commercial pressure’ be dealt with in a factory? For example, with temporary workers to deal with extra demand. Would this work in software? Well, no, since it’s a fact that when you add extra people to a late software project, you make it later. In the software industry, we call this the mythical man-month; the logic is simple, if one women can make a baby in nine months, then surely nine women can make a baby in one month… this is wrong thinking, right? And that’s what happens when you apply traditional, linear, factory thinking to the complex, non-linear process of developing software and technology products.
What is intuitive in the linear domain is counter-intuitive in the complex domain. Software and technical teams respond differently to commercial pressures.
Many companies hamstring themselves by not knowing how technological and software development works. And this is because they ignore tech, are scared of it, and it’s because they refuse to let go of their old identity. They say, we are a bank/telco/law firm, when they are in fact a software company that happens to sell mortgages/streaming tv/legal services. If you trace this identity crisis to its roots you will almost always find a collection of managers, who may or may not have MBAs, and who will be trying their best. Effort is not the issue. I could try (really hard) to play basketball but I am a rugby player. And that’s the problem, at the heart of many companies you have a load of people trying to play the none-linear, complex game using linear, non-complex methods. This is why they are losing. My touch team can’t beat the Harlem Globetrotters and it’d be foolish to think we could.
That some companies think they can easily manage tech projects is arrogance, but it’s an innocent form of arrogance. This sort of arrogance is born of ignorance, not necessarily from a sense of superiority (or inferiority).
The solution is to get wise, and learn how tech works, or to get out the way, and let people who know what they are doing run the show. At Ugly Ducking we’ve seen a lot of banks get tech right, and they are flourishing. We’ve seen others, in denial of their new nature, hire extra accountants when they really needed a developer. They muddle on.
Baby and Bathwater?
Not many people know this, but in the old days the father would get a bath, then the mother would use the water. Later the children and finally the poor baby. The water would be so dirty you couldn’t see the baby and hence you had to be careful to not throw the baby out with the bathwater.
I am not suggesting that all traditional project management is bad. Nor am I suggesting that an MBA is a bad way to educate yourself. I’ve had the privilege to visit the Rotterdam School of Management and learnt a lot there. The course I followed was from their MBA. What I am saying is that you have to know when a project is in its linear stages and when its in its non-linear stages. (Some projects actually never have a linear stage.) You also have to understand when to carry out experiments, because analysis cannot be used when a situation is unknown, and when not to. This hybridisation of the old and new is what many organisations need now and will be the key to their future success.