agile
The State of Enterprise Software.
23 Jan 2018So I have the good fortune to work with top companies whose leaders are passionate about transforming their applications and technologies to improve the quality and responsiveness of their business.
What is the point of technology if it does not make life simpler, the journey smoother and faster for delivering services to customers in a reliable way? Why is it so common for top companies to invest so much resource and budget to consistently fail at such a simple objective?
The sad truth is that every project I join after the fact will be facing the daunting reality of missing it’s key objectives of budget, timescale and always compromising on quality. The reasons for such issues are always due to a combination of factors including poor leadership, lack of a disciplined methodology and a supporting detailed plan. Poor teamwork and politics across silo departments and third party suppliers who are not managed to an appropriate commercial framework can also exacerbate the challenge.
In very rare cases where I have been entrusted by project sponsors to initiate a project from concept through to completion have I had a genuine sense of fulfilling a promise to deliver a project on time, under budget and exceeding customer expectations. Handing over a project and witnessing a rapid adoption by customers is without doubt the final seal of validation. It’s an amazing feeling for all concerned!
The challenge with many enterprises is that the relationships between stakeholders and senior leadership are complex and highly political in nature spanning across many departments. Also, the scale of investment required to deliver transformational change has to be justified by getting buy-in across a large number of interested parties and as a result the project leader is faced with walking a political tightrope. The need to constantly justify and seek approval is counter-productive. This interference coupled with the resulting confusion places commercial and people dependencies under immense strain. So much so, that the project team can feel paralysed from achieving the simplest milestones.
That aside, many project teams simply do not understand or follow a formal software development process. The common theme I encounter on many of my project engagements is the lack of traceability, requirements and design artifacts. Most project teams are clueless as to what has been implemented and the traceability from implemented code back to test case, design, architecture assumptions, requirements and business case. This lack of traceability and discipline often means that the developer responsible for writing the code is the most important person in the chain. Without traceability, the developer - who is likely to be the least expensive resource on the project - must make sense and deliver working software by making best guess assumptions where formal traceable documentation is not available.
A typical project will have multiple development teams with several developers assigned to build key objects and components. The compounding effect on the risk and scale of mismatches that will surface during the integration phase of major sub-components increases dramatically. The later we identify and attempt to resolve issues during the project lifecycle the greater the impact on schedule, cost and quality.
Many large organisations have shifted away from a waterfall approach to a more iterative, incremental and agile project methodology. The benefit of shorter cycle times for delivering drops of functionality has been welcomed by business users as there is a sense of progress, early collaboration and visibility of project status. Also, dispensing with the formal analysis and design documentation that usually accompanied the waterfall approach was considered a major benefit of agile. My experience of hybrid agile projects has sadly observed ever more budget and schedule over runs resulting in sub standard legacy software being delivered from the outset.
As projects approach the looming year end and budgets are being reforecast, I see frantic efforts to identify a Minimum Viable Product (MVP) to enable an overrunning project to be shut down as quickly as possible. The pressure and embarassment for senior managers to plead for more time and funding to bring the project back on track is extremely painful. Naturally, these efforts are highly disruptive and demoralising for all concerned. Very rarely can such a project recover or deliver on its original business case and promise. Usually, the major transformational project has already become a legacy system of Frankenstein proportions.
Why do most organisations get it so badly wrong? This is always a combination of factors: weak leadership that lacks the experience and capability to scope, analyse and plan a project is fundamental. Add to this the hiring of inexperienced or poorly motivated people to key roles that lack the domain or technical expertise, then we have the recipe for a perfect storm. The issues that drive a project to failure isn’t due to the software, tools or technology. It is the lack of experience, sound process model and methodology that profoundly impacts the quality of the design and build. Delivering a solution that is fit for purpose must be capable of withstanding amendment without falling apart at the first attempt at a change.
Very few projects proceed as planned. The start of a project is announced with great fanfare and enthusiasm but rapidly hits a wall. Poor productivity and the lack of traceability and prioritisation mean that the inevitable rush to get something delivered results in chaos. The desire to spin a success story out of an impending disaster means that serious compromises will have to be made. The project sponsors will be forced to accept a hobbled together deliverable with a long list of inaccuracies and defects. Not to worry, the project will learn from past mistakes and deliver better next time. Unfortunately, like suicidal lemmings we rush to the next cliff repeating the same mistakes over and over again.
Contact me if you have a requirement for an experienced technical delivery manager to help you stem the tide of challenges and issues your technology projects are facing. Project management is not simply about managing lists and raid logs. An experienced hands on technical delivery manager will engender trust, set out clear objectives and responsibilities across your technology and business teams. Adopting a traceable project methodology will help your business stakeholders deliver an exceptional user experience for your customers.