The lack of predictability is often cited as a reason for relationships falling apart. When it comes to IT projects, predictable delivery is a crucial part of success. In fact, ignoring the hidden costs of unpredictability is one of the key issues tripping up many product owners, project sponsors and even board members.
The software development industry has some legendary unexpected failures, often referred to as ‘black swan’ events. For example, the planned $50 million Levi Strauss SAP migration project that led to a $200 million loss, or how the Airbus A380 was massively delayed, in part because some of the design team used an outdated version of the product development software.
While these failures quickly achieve cult status, budget overruns and late delivery are more common than many in the industry acknowledge.
Research has shown that 31% of projects are cancelled before they are completed, with only 16.2% finishing on time and within budget. This has largely been blamed on poor requirement management, bad communication and scope creep.
While the blame for failure is often levelled at the development team, the reality is almost always much more nuanced.
Predictability works for everyone
IT predictability is the ideal state, where teams can write code at a consistent and sustainable pace, while meeting all quality standards. Unfortunately, this is always reliant on both up- and down-stream dependencies.
Great development teams must be empowered to say “no”.
There will always be third-parties that the developers will have to integrate with, many of whom don’t have the same standard practices and who don’t employ the agile two-week iteration practice.
Even a relatively small delay on contract sign-offs from the client, or development milestones by third-parties, could have a big knock-on effect and it invariably takes much longer than two weeks to get back to the agreed delivery roadmap.
Understanding each party’s priorities
A key part of building a predictable IT project is communication. When all parties are open and explicit about their big-ticket items, these can be built into the roadmap upfront.
Getting blindsided by uncommunicated security or compliance audits, or a change in cloud service provider, will impact predictability.
The conveyor belt is always running, and this is why great development partners will work closely with their clients to ensure everyone is aware and prepared for all eventualities.
It’s also important for everyone to be aware there are many partners in an IT ecosystem. There are any number of service providers that need to be engaged with, and their requirements and potential delays also need to be incorporated into the roadmap and managed to build and sustain predictable delivery.
Protecting developers’ time with proper planning
Project management is a vital part of a predictable delivery model. Meetings need to happen, but having a meeting and then 30 minutes later having another meeting is not ideal and this context switching takes a very real toll.
A recent Qatalog and Cornell University report shows that on average people take about nine-and-a-half minutes to get back into a productive workflow after switching apps, with 45% saying context switching makes them less productive and 43% saying it causes fatigue.
By using heatmaps to create the scrum event schedule and other meetings, you can minimise interruptions and frustrations from creeping into the development team’s day. This will ensure maximum efficiency and productivity to enable the development team to focus on delivery and first-time quality.
A ship can only have one captain
To achieve this level of predictability, it’s also necessary to work ahead. By using dual-track agile processes of discovery into delivery, development teams can start refining scope and building requirements sprints in advance, giving teams a high level of predictability.
However, this requires excellent and frequent communication between the development team, product owner and other key stakeholders to ensure all parties are aligned and provide minimal chance of misunderstandings. For this reason, it is important to have a single product owner and frequent open communication channels with clients.
While the product owner will normally attend daily stand-ups, it’s important to have other stakeholders and subject matter experts routinely join the fortnightly review and planning session for a voice of the client so there is no chance of miscommunication.
Things can get lost in translation or priorities can get diluted, so having a subject matter expert on hand adds a layer of certainty and helps maintain predictability.
Finally, great development teams must be empowered to say “no”. Managers and stakeholders are not at the coalface and don’t understand what needs to be done and how long it will take.
By empowering dev teams to push back, you allow them to finish the work at hand to the expected quality levels for that increment. When leveraging dual-track agile, the teams can identify and solve problems well in advance of sprint delivery, thus putting them in the best place to successfully deliver.
Share