Fashion in ‘94 was to manage software projects in weekly project meetings, where systems and coding people as well as testers and others participated. No software requirements were the centre of discussions, as most of them floated in space and everyone had their own view of what needed to be done. Much time was spent on getting a shared picture. Specifications existed, mostly with short but incomplete descriptions produced by systems people. It was still incomplete work that needed to be properly done by coders, as they couldn’t pass the bucket to someone else. It was of great help if the work was based on technical standards, which partly replaced unspecified requirements, and could therefore save a project. Lots of problems still needed attention.

Today, software projects have daily meetings, still no software requirements, and notes written on laundry lists. The way to manage a project haven’t improved, only with a cooler name. Project management is as pointless as it was then. More effort is spent on planning and coordination activities. In ’94, one hour was spent each week to talk about project matters; that has increased two to three times today. The activities are nevertheless the same, named differently, but with the same watered down results. In newly posted surveys, developers spend 10 hours on coding activities each week. In private surveys made in 2001, software projects spent 30% on project management, 25% on coding, 35% on testing and only 10% on specifying requirements. Creating a structure for project management activities will set aside time and resources for precisely those activities, either they are needed or not. Even if the goal in 2001 was to spend 15% of allocated person-hours on requirements work, a fairly large project managed to only spend 10%. Project management has a tendency to become a slush account, where anyone can write their spare time without doing any productive work. That has been institutionalised with today’s way of working.

Nearsightedness has become a fashionable idea. Postponing decision making, or ignoring it completely, is a strategy that at best builds mediocre products. In ’94, products were built at least twice before being released. The same is done today, although differently, creating new positions outside the delivery machinery to fix serious problems never addressed inside. The much celebrated ‘value creation’ by fans can’t be seen by real product users, who expect a release to work. The nearsightedness ignore business problems, the big picture, favouring current technical problems very few are interested in. All verbal meetings benefit those who know how to talk, how to dominate and how to blame. The good ideas are never heard. Valuable ideas are usually born in a relaxed and spontaneous surrounding, away from the office, seldom in front of a screen that only generates tension and anxiety.

Innovation is not iterative, it consists of three phases that are quite separate. The first phase is to come up with a substantial idea, the second to build the idea, the third to make it work on a market. It includes marketing, educating clients in all the advantages the product brings. Innovation rarely sell itself, unless the brand is very strong. Launching non-original ideas that doesn’t stick on a market is not terribly innovative.