Project delivery for large enterprises can be tricky. Over the last 19 years, assisting companies to deliver on their objectives, I've noticed that delivery tends to be blocked by the same things every time.
The need to iterate and deliver at speed has never been more necessary, both for servicing existing customers and attempting to attract new ones.
Having had the opportunity to work on a diverse range of initiatives throughout my career I have first-hand experience seeing what hinders companies in delivering at pace in a production environment. In this post I will discuss a few of the consistent themes I have observed.
Fear of Failure
Failure, in my view, is not taking action and not learning from the outcome of those actions. However, this view is not shared by many, and on projects, the ramifications of perceived failure are real and have a detrimental effect on the risk appetite of people to make brave decisions. In most projects I have engaged in, there is such a high level of uncertainty, that the risk element and level of assumptions are high.
"So essentially what starts out as a quick way to put together a top-level project scope quickly turns into a risk management exercise, detailing each and every possible item that could lead to non-delivery or non-compliance."
To ensure the assumptions are validated, project teams need to iterate as quickly as possible, without sacrificing quality, to ensure that they prove or disprove these assumptions. Ideally this is to be done with the intended end-users of the solution.
Unfortunately in a large number of cases, this does not happen. Resulting in the following scenario playing out:
- The assumptions and risk levels are clearly articulated in documents, and a lot of time and money is spent on analysis, asking internal SME’s (that's subject matter experts, not small medium enterprises 😉) across various departments their opinions regarding the assumption, and the risk items identified.
- This creates unnecessary circular debates, wastes valuable time, which increases the risk of ‘failure’ anyway, and does not get one any closer to a way to validate the assumption.
- The fear of failure often entraps people from making the clear, concise, brave and often right decisions to move the initiatives forward.
The Methodology Tension
“We are implementing this Agile”.
I unfortunately hear this at the beginning of almost every project that I am involved in. The various rituals are set up, “we” decide on a two-week sprint-cycle as a core project team and off we go. We are now agile. If only it was as simple as this.
Although we have the best intentions and have lived through projects where a waterfall type approach has not delivered the intended results, “going agile” does not work if there is no upfront understanding, education and buy-in from all stakeholders on these projects. This includes from the person paying for the project, right through to the end-user that will be drip-fed iterative features at a consistent pace. Each one of these groups needs to be on the same page when it comes to the process and intended process that is being followed.
In my experience, there is a lot of agreement up-front in a project initiation, as well as kick-off events. As time passes, the lack of understanding of “running” agile grows and, people fall back to past patterns of behaviour, reverting back to:
“where is the signed-off Business Requirement Specification (BRS)”.
Very quickly the day-to-day processes slip into a “fast waterfall” initiative, reducing the agility and speed at which a project can deliver value to the intended end-user group. And I go back to my earlier topic of fear. Due to the inherent fear of failure, people will want to document each and every requirement and potential outcome ad nauseam, without fully understanding what the end-user wants or needs.
How Projects are Funded
From my experience, the process of getting funding for larger, often digital transformation type projects, is traditional in nature, and governed by people who do not have the responsibility to ensure a project is implemented, makes its way into a production environment and can be used by actual users and add value at the same time. From my perspective, there seems to be a belief that the company is investing in something tangible that has a known outcome, and that once built, the tangible asset exists for a period of time untouched, and depreciated over time. This is not the case.
A business case typically has some benefits, such as risk mitigation items, capital costs and documenting operational costs. These usually form the basis for a decision that is made by a committee who uses the information in the business case to inform the steer whether to back and prioritise an initiative. Typically, the benefits presented need to have a wow factor and are largely educated guesses which need to be validated. The quicker validation happens, the stronger the business case becomes. However, in projects I have engaged with, this is mostly not the case. The business case is approved, often with very lofty benefits, and a steering committee is then established as a governance structure to manage the outcome of these benefits. The whole process is skewed to slow, lethargic and outdated outcomes. We are not building a house. We are trying to solve a business problem, are making some assumptions, and need to roll with the punches within a structured governance framework that allows gates where progress is assessed and brave go-no-go decisions must be made and learnings taken from the experiences. For me, the ultimate success is a solved business problem, with users actually engaging with the solution.
The Governance Myth
Lastly, governance has to get a mention. If I was to write this post a few years ago, it would have stated categorically that intense corporate governance processes are a key contributor to organisations not being able to iterate at speed. However, experience and hindsight has enlightened me. When embarking on an initiative, ensure at all times that the necessary people are taken on the journey with you. Involve them, ask them for their opinions, their guidance and their insights. I have found that this small change in my approach has helped a great deal in ensuring a fruitful relationship with the required governance steps, and interactive initiatives.
Conclusion
Although there are many themes that cause a lack of rapid delivery within companies, I have to end this by saying that I have had the privilege to work on a handful of projects, within a corporate setting, where quick, iterative progression was achieved and governance followed. The business stakeholders took some time to buy-in, but once they saw the speed of iterations and saw results often, they liked what they saw. Not surprisingly, these are the projects I most enjoyed working on and, I'd venture to guess, were also some of the most enjoyable for other team members.
In my next post, we turn things around and I'll share my insights on how to unlock speed of delivery in your company.
