The Good, Bad and Ugly of Project Delivery

Software projects are commissioned to solve real-world business problems. It can be a minefield and many stories exist of late delivery, blown budgets and outright failures. But it doesn’t need to be this way. In our experience, there are a few well-defined steps to be taken on each side that will ensure your project is delivered as smoothly as possible. That’s not to say there won’t be bumps - there almost always are with anything other than the simplest pieces of work. With the proper controls, these bumps will come to light early and become smoothed out during regular communication between Client and Supplier.

So, the Good, Bad and the Ugly of Project Delivery (just not in that order)…

The Bad The Ugly The Good What the Client Needs to Do Questions the Client Might Ask Themselves What the Supplier Needs to Do

First, The Bad

If you want to build a house from scratch you don’t hire a bricklayer, a joiner and an electrician. You will need these skills and others but that’s not how you get a house built. These individuals each needs to be set specific tasks in a specific order. There are also other skills that you may not appreciate are needed (after all, you want the end result of a house, you’re not an expert in building houses). Do you want to manage all of these people, assigning them their tasks, checking on their progress and dealing with all their questions and issues that arise? The architect and project manager are the key people here who can guide you through all the options there are then execute your decisions on your behalf.

Takeaway

So, if you want a software product, don’t hire a software developer. What you’ll need is a blend of various skills: UI/UX design, front end development, back end development, solution architecture, QA testing, project management, business analysis.

Second, The Ugly

You don’t have to look very far for the worst examples of failed software projects in the media, whether its banks with platforms where users couldn’t access their accounts or public sector projects that overspent by millions and were still cancelled without ever seeing the light of day. I suspect these projects failed because the destination was not clearly defined, the steps to get there were not blocked out or the progress was not verified along the way.

Takeaway

Be clear about where you’re heading, how you’ll know if you’ve arrived and all the steps needed to get there. Verify along the way if you have truly arrived at the next step with rigid acceptance criteria.

Lastly, The Good

Outsourcing a Project to a third party requires leverage. Leverage means putting in a small amount of input to get a bigger amount of output on the other side. So, you always need to put in some input to get a correspondingly larger amount of output from the partner. Getting this right is a tricky balancing act. Its a mistake to think that no effort is required on the part of the client. These are the things that you, as the client, need to do to help ensure success.

What the Client Needs to Do

Firstly, ask yourself:
Where do I want to get to and how will I know when I’ve arrived?

Make sure that...

You have defined desired outcomes - something that your business needs to do or needs to stop doing. e.g. we want to be able to allow Customers to manage their own bookings online; we want to be able to send all Customers a digital bill on demand. This is a defined tangible outcome of the project and can be measured, unequivocally as being successful or unsuccessful. There is ideally a financial implication of completing this work, so it has a clear potential to provide a measurable return on investment and create a clear rationale for doing the work in the first place.
You have a Product Owner on your side - someone who acts as the point of contact, answers questions that are asked, provides feedback (positive and negative) and takes responsibility (on their side) for the delivery of the project.
You are involved in the development process. When you receive an incremental version of the product, you need to check if it suits your needs. UAT is the time to ask “Is what we’ve asked for what we need?”. This is your chance to refine, pivot or continue as planned and to verify whether all the success criteria have been met.

Questions the Client Might Ask Themselves

During the journey, might I change my mind about where it is I want to get to?

There are a number of reasons for this to happen such as
- the business priorities might change
- the world might change
- new knowledge might become available

Takeaway

Don't be afraid to change your plans part way through a project. Ensure that there are provisions for change from the start. If the supplier is quoting a fixed price for a known piece of work, it will be difficult to change focus part way through without tearing up initial agreements and starting again. If you engage on the basis of effort rather than a fixed deliverable, you are more free to pivot and change your focus along the way with less negative impact.

How do I minimise the risks of getting there?

The way ahead is full of unknowns. Nobody has done exactly what you're trying to do before - this is the first time this has ever happened! Similar things have happened before - the same destination maybe, but different people, and different starting point. So this is brand new, so let's remove as many of the unknowns as possible. (As they say in flying circles, change one thing at a time and your risk of having an accident is small. Change more than one thing at a time and the risk massively increases.)

Takeaway

Choosing a supplier and a team that has done similar things before minimises the risk as the way ahead becomes less of a surprise and more of a known quantity.

How do I know we’re on course?

Block out the steps needed to get from here to there in as much detail as you can. The BA can do this with your guidance. This might be a list of deliverables, and once complete, the work is finished (in truth we find products are never 'finished', there's always the desire to add more features or make UI/UX changes to improve the existing experience).

Once these steps are known, you will be able to gauge whether you're on track or way off course.

Takeaway

Check progress as you travel towards your destination. Verify whether your product meets the acceptance criteria you have set before you mark it as complete and move on to other things.

How do I know that what we’re asking for is what we want?

If you want a Mercedes, it's much simpler to build something that looks like a Mercedes without all the engineering under the bonnet - i.e. a model. If you can look at the car, walk around it, sit in it even, you'll get a great feel for what the actual product would be like to own. Same with software - if you can walk through a mock-up that looks and behaves exactly like the finished product, you'll be much more able to evaluate whether the current design is fit for purpose. Developers (myself included) are also notoriously poor at making good UI/UX decisions so let's not leave it to them!

Takeaway

Build a model of the software, before building the actual software.

How do I know that Users will understand how to use what we’re building?

Get feedback from whoever is expected to use the product. Its all too easy to make huge assumptions about how Users will behave, especially if you know a system inside out. Users who are fresh to a new platform look for visual cues about how to use the software and also based on their experience with other systems. If you put your target users in front of your new system and they don't know what to do, you're in trouble.

Takeaway

Get feedback as early as possible, listen to it and make changes where necessary.

What the Supplier Needs to Do

Be transparent.
Ask questions as they arise and arrange regular sessions with the client to cover these off
Make assumptions explicit wherever possible, allowing the client to confirm or challenge the assumptions.
Raise issues and questions as early as possible in the process, e.g. immediately following the Sprint Planning session where questions have been raised or complexity uncovered.
Tackle the difficult tasks first (giving more time for complexity to be understood and resolved)
Arrange regular feedback to the client and regular drops of work into a UAT environment for their approval
Internally, arrange a morning and afternoon session where more junior developers can spend time with more senior ones to ask questions, check their approach and seek feedback . This helps the junior people develop autonomy whilst still getting the support they need, but also gives the senior people time to concentrate on their own tasks rather than being asked ad-hoc questions that could disrupt their own delivery timelines.
Walk the client through a UAT release or provide a video walkthrough. At CSL we have recently started creating video walkthroughs of new platform releases showing the client how a feature can be used. It's something that can be referred to in future and sent to any interested party so it is a nice efficient way of helping the client understand what is contained in the delivery.

The latest and greatest