We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

Project implementation: Setting your project up for success

With over 20 years of experience in the software development industry, I’ve seen many projects delayed for one reason or another.


Some are due to poor management, lack of skill and even over-commitment from the service provider. But just as many could have been saved through actions the client could have taken in setting up for and executing the work program in a slightly different way.

In this series, we discussed some key areas worth considering when you start planning a digital transformation or large software development project. The topics we covered aim to highlight what you can do differently to help minimise budget and time overruns. They include the planning for an accurate scope of work, and the risks of cutting corners  and not being discriminating enough with lists of requirements, the ongoing challenges of getting better estimates, and the RFP process itself.

These are all important steps that need to be considered before a project starts. But once the project is underway, there are still many other things that can cause it to go wrong. In this article, we’ll talk about three essential elements that can help deliver your program successfully.


Excel at product ownership

The most important thing that you as a client can do to help deliver your large software development successfully is is provide a competent and empowered product owner to be the critical conduit between your business stakeholders and the project team. This product owner’s job is to ensure that the final product being delivered meets your business requirements and delivers the promised value, and that on the journey all key stakeholder expectations are managed appropriately so there are no unpleasant surprises at the finishing line.

In addition to some knowledge of the software development process itself, a great product owner is skilled at understanding products and value, as well as how to compromise and how to make decisions. They know how to work constructively with a technical team and take a path towards a solution even in the face of often seemingly insurmountable challenges, and they know how to manage expectations on both sides of the equation to ensure that everyone understands what is going on and what is expected of them.

This all sounds reasonable enough, but there are two key places where this usually fails.

The first is product owners who don’t have the power to actually make decisions. Product owners need a mandate to make decisions on the fly in a way that safeguards overall product’s value success without unnecessary governance overhead or the need to take everything back to the business stakeholders for formal approval. The process of building software is fast-paced and changes regularly. Decisions and compromises are taken almost daily, so the product owner needs to have the ability to answer questions and to make a call when a roadblock comes up or something changes.

The second is product owners who lack the actual capacity to do their jobs properly because they’re double-hatting or not fully dedicated. Product owners for any significant program of development work simply must be full-time. Popping in now and then, attending only half the meetings or otherwise being unavailable, disappearing once the upfront documentation is completed in the belief that everything is agreed and it’s all written down; these approaches will almost guarantee failure. Product owners who aren’t readily available to development teams will also cause delays and increased cost through rework (because if developers need an answer and don’t get one, they have to decide without guidance, make assumptions and potentially then need to backtrack when those assumptions are eventually proven incorrect for some reason).

The product owner’s role is so pivotal that often, changing product owners mid-project can have serious consequences to the continuity of knowledge and velocity of the team, and can even significantly impact the quality of the work being done, even though the product owner is actually not writing any code themselves. While in some cases, changes to staff are unavoidable and might even be necessary in some environments, at the very least, the loss of a product owner is a risk that should be managed carefully, particularly where that person is also has “key person” risk attached to them.


Focus on the overall experience

Software is a complex and interconnected beast and there are often many ways to achieve a particular outcome. This is why it’s so important to think about features in terms of the value being delivered and what you are fundamentally trying to achieve, not necessarily the specific way that you might have planned to achieve it. You might get halfway through something and run into a roadblock; being able to pivot and deliver that same fundamental outcome in a different way (and have a product owner who is available to and has the authority to make this kind of decision rapidly) is the key to keeping large development projects on track.

In situations like this, clients can (and often do) fixate on edge cases that represent an incredibly small percentage of the overall experiences that will be delivered by the system. This isn’t to say that they aren’t important, but that in the grand scheme of things, it’s often more cost-effective to focus on what the majority of users will experience and allow “simpler” approaches to achieving the same fundamental outcome (albeit with a reduced experience) for the edge cases that will impact a relatively small minority. This type of focus on value is important because building software is expensive; it’s expensive because it takes time, and time costs money; edge cases in particular increase the time it takes to deliver a particular feature exponentially given that all possible permutations and scenarios must be first developed and then tested and supported ongoing, so it’s important to consider everything through the lens of whether or not the thing you’re spending time on is valuable enough to justify the expense.

By the same token, it’s also important to know when pivoting like this that a change request in one area of a large system can sometimes have wide-ranging implications on other parts of the system. If the concrete slab has already been poured and you want to move your toilet to a different part of the house, it’s going to be difficult.

So while changes of mind and scope are an inevitable part of a project and can occur for many reasons, and some will be par for the course and have minimal impact, some others will unavoidably cause things to slow down while the team not only pivots to and plans for the new course of action, but also while any remedial action or additional work to facilitate the change is carried out. These types of unforeseen consequences can arise from seemingly mundane, everyday decisions that indeed happen every day, and they can create a compounding effect of both immediate and longer-term impacts and risks. This happens so frequently that planning for this to occur is mandatory to developing a budget and timeline that is realistic. It’s also why a product owner who is empowered and has the capacity to make decisions rapidly without unnecessary bureaucratic overhead is so critical.

Ultimately, changes of direction are an unavoidable part of software development. As a best practice, try to minimise the unnecessary ones as much as possible, but understand that they are going to happen and that allowing the team the time to consider and implement them as properly as possible is important to a good quality result.


Streamline integration

Software development these days rarely happens in isolation. This is especially true in large digital transformations aiming to deliver enhanced and seamlessly integrated customer experiences.

Nearly every project will involve integration with a back-of-house system of record or other tools and platforms.Managing the dependencies between these systems and different parts of the program is critical to ensuring the project does not lose momentum and avoiding situations where one or more projects or parts of a project must stop and wait for another part to catch up.

To illustrate the significance of what can happen in these situations, suppose you’re working with a team that needs to halt entirely because a critical milestone of the overall project wasn’t met. Let’s say an API that you needed the team to connect to isn’t ready. In this situation, with some service providers, you might find yourself being charged extra for professionals that are just sitting around waiting to get access. This would certainly happen with some large consultancies. Other providers might be more accommodating, but for them, there will be an incentive to move those people onto something else to keep them busy. Therefore, as soon as a gap opens and people become available, they might be moved onto something else, and from that point forward you might not see them again. As discussed, team changes can have a significant impact on quality, let alone cost, since the team spins its wheels and shifts back to the “forming” or “storming” stage of its lifecycle, as opposed to “norming” or “performing”, where it might have been before the delay.

Not only this, but sometimes in an effort to keep a team busy in such a scenario, the team might try to expedite other work just to have something to do. This can be rushed forward and therefore have consequences of its own, and could result in increased cost down the track through either quality, “spinning of wheels” or other issues.

Time slips can happen for many reasons. Sometimes it’s not your internal software development that causes the delay, but the governance processes around the overall program or the lack of capacity within the team to effectively make timely decisions and keeping things moving forward. Regardless of the reason, you should ensure your house is in order and that you are doing everything possible to enable your partners to keep moving forward.

The key is ensuring you manage the program and dependencies effectively, and making effectively and timely decisions when a fork in the road presents itself. Up front you should ask your service provider what they need from you, any milestones you need to hit, any flow-on impacts from missing milestones, and any mitigation strategies they intend to employ in case this happens. You should also make sure, once you’ve committed, that you deliver what you say, when you say, the same way you expect your service provider to, and if it looks like you’re not going to be able to, let them know sooner rather than later.

Delivering a project successfully is as much your responsibility as it is your service providers. The bottom line is that in large software development projects there are many things that won’t go according to plan, so understand this plan for the unexpected.

Don’t be too ambitious with your timelines or deliverables. Make sure you provide effective, capable and empowered product ownership to work with the team: making daily decisions is a fact of life if you want to keep things moving, so give your team the capacity and capability to do it and avoid getting bogged down in approvals for every little thing. Finally, focus on the value and keep a tight rein on any dependencies. The best way to start burning your own money is keeping the development team waiting or scrambling for something to do.


Christian Brenner has spent over two decades building enterprise websites for businesses and organisations. He is currently the National Head of Technology for Merkle Australia, the country’s leading customer transformation partner, empowering brands to create distinctly better experiences.


This article is the last in a five-part series. Follow Merkle Australia on LinkedIn for more.