Some organizations seem to exist in a permanent state of high drama. You have probably come across a business with this kind of operating style. Everyone seems to lurch from crisis to crisis, and even a routine task such as closing the month-end can be a frenetic process involving late nights and last-minute phone calls.
Businesses that operate like this may lose valuable staff members. While some crises are unavoidable, companies that try to minimize them are more resilient. It’s exhausting to firefight all the time, and it can lead to staff burnout and, eventually, turnover.
If you want to take on project after project and keep delivering customer success long-term, it’s best to try to manage the business in a more sustainable way. Working at a continuous, productive pace enables people to manage their work-life balance more effectively and produce their best work.
This notion of working at a steady pace and avoiding crisis is central to the Agile Manifesto, which I wrote about in a previous article. Arguably, technology projects are particularly amenable to Agile management techniques, as they don’t face the same challenges as big infrastructure projects.
Much of what we can do today has never been done before. But that doesn’t mean technology leaders can’t learn from other industries. Here are some historical examples of managing projects:
1. Bring the tough stuff to the front.
In the world of Agile software development, the mantra is to deliver value as early as possible. It speeds up delivery time, making the client happy while encouraging employees to feel positive about the new software.
However, when it comes to technology projects, the easy tasks tend to get done first. This can appear to be great progress, but in reality, it can be problematic. The people doing these tasks are usually more junior employees. If the more complex tasks are delayed, it could be a long time before more experienced people get involved. By that point, much of the effort and allocated costs might be spent. When a red flag is finally raised, the train is a long way down the line.
Early in my career, I worked as a consultant with engineering firm Rolls-Royce, which produces aero engines. I was struck by the way they deliberately tackled the most complex projects first, early in the life cycle. If an issue arose, they had the opportunity to adjust cost and/or delivery time expectations. They could potentially move forward with a bigger budget or longer time frame, amend the design or scope to fit the budget and time constraints or just can the project. All of these provide a better outcome than tackling the hard stuff later and finding out something significant when time and money are already substantially spent.
2. Test as you go, innovate safely and re-plan.
As an example of this technique in action, I’m going to go back in time to Joseph Bazalgette, the 19th-century English civil engineer who masterminded the creation of London’s sewer network, which relieved the city from constant cholera epidemics. In its day, this project was extremely innovative, both in the materials used and the process. It’s also notable among examples of Victorian construction for safety and a low death rate among construction workers.
Bazalgette was a proponent of the use of Portland cement, a material stronger than standard cement but with a weakness when overheated. In one of the earliest examples of quality assurance techniques, people rigorously tested the batches and the way things were being done across the network on a daily basis. The results were fed back to the manufacturers, who altered their production processes to further improve the product.
This partnership between the master builder and the cement company is a great example of what any software-as-a-service company aims to be to its customers. The company supplied the material in small batches, they were tried and tested and the results of the tests were sent to the makers, who reworked the formula in response. The sewers have stood the test of time and are still largely in place today.
3. Have an open culture.
If asked to name a project that ended in crisis, many people will likely think of the Challenger spacecraft disaster. In 1986, the space shuttle broke apart shortly after launch, claiming seven lives. The world was in shock. How could this have happened?
The commission of inquiry, led by theoretical physicist Richard Feynman, found a tiny component had not been tested at the cold temperatures that were present at the launch and failed, causing the spacecraft to break up. Several engineers had raised concerns about this but, unfortunately, their concerns were not listened to. The decision to press on was later blamed on “customer intimidation.”
Businesses that have an overly hierarchical structure where people hesitate to raise red flags out of fear of being blamed are going to find it difficult to surface risks. Suppressing and hiding risks causes trouble for everyone. Of course, it can be difficult to raise issues with demanding customers. But it is generally better to have the conversations early, point out the risks before customers notice and work together to deal with them. Challenger is an extreme example, but it illustrates the importance of encouraging people to recognize what is not working and to admit it openly.
In conclusion, businesses with an open, forward-looking culture in which everyone works together to solve problems are better able to avoid an atmosphere of constant crisis. And when the unexpected does happen, they are more likely to rise to the occasion as a team.