Early in the Badger’s career, when he was part of a team sorting out a large software and systems project with serious problems, the CEO of the time angrily asked the line manager responsible for the project ‘Why has this happened? Why haven’t we learned the lessons from other problematic projects?’. The line manager’s answers were ill-considered waffle and only served to ratchet up the pressure from, and antagonise, their boss.
At that time, projects involving anything IT related were notorious for serious timescale and cost overruns. IT was a young, rapidly growing industry, and software development was seen as black magic performed by very clever people. Disciplined software engineering processes were rudimentary, and most programmers were graduates from enormously diverse STEM-subject, rather than computing, backgrounds. The Badger’s first software team leader, for example, had a Civil Engineering degree and a master’s degree in Water (sewage) Treatment!
In the decades since, IT companies have improved and evolved their management and engineering policies and processes – their ‘company manuals’ – because it was necessary to stay in business. Today, a continuous improvement ethos that feeds lessons learned into policies, processes, and practices is a norm, and software and systems engineering is more standardised and rigorous. Companies still have troublesome projects, but there are fewer of them, and they are detected earlier and addressed faster.
And so, the Badger’s interest was piqued recently when he heard a CEO calmly ask a line manager the same questions as above. The line manager answered with three points that struck a chord with the Badger’s own experience. The first was that in recent years annual staff turnover of between 12 to 15% had diluted the continuity of knowledge because nearly half the workforce had changed. The second was that clients want the capabilities of evolving innovative technology much faster and cheaper, which means that projects can encounter more skill and experience issues than envisaged at contract signature. The third was that feeding lessons learned into management and engineering policies, processes, and practices and embedding awareness in the workforce needed a greater company willingness for those who had lived the project experience to spend more time as ‘overheads’ rather than revenue earners.
The CEO calmly agreed, and then said something which also aligned with the Badger’s experience, namely ‘Our company’s policies, processes, and practices will never be perfect. If we want fewer project difficulties, then we must get project people to just talk more to each other and willingly share their experience’. And there you have it. The fastest way to learn lessons is for people to just talk to each other. Projects depend on people, and people have different personalities, motivations, strengths, and weaknesses, and never do quite what you expect! That’s why troublesome projects will never be eradicated completely and continuous improvement is always a challenge.