De-risking your software projects while making them more profitable

20 January 2020
Paul McGillivray

Digital transformation, or business process automation is known to be expensive, and can also be full of risk. Projects can overrun their budget, or not deliver what they promised. Worse, large projects might not be adopted by the team who are using the software, or the assumptions that the project's based on could be wrong. This is a major challenge for software development and can prevent business leaders from taking on the projects in the first place.

We know that to keep up with the rest of our industry, we need to continue to automate our processes. If we're not doing it, we risk falling behind our competition, or being overtaken by new tech-startups, who can scale quickly and reach a wider range of customers for less money.

But at the same time, an entire digital transformation project can cost tens, sometimes hundreds of thousands of pounds. It can - understandably - feel like a huge risk to commit to such a large spend on a project, when you can't be 100% sure of the ROI, or that your colleagues will adopt the new system.

But there is a way to de-risk your projects and reduce the up-front spend, while getting very early buy-in from stakeholders, and an equally-early Return On Investment.

At Remote, we practice Lean principles when we're developing software. Lean was developed by the Japanese manufacturing industry - largely Toyota -  but works fantastically well in software development. The seven principles of Lean development are: Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, and Optimize the Whole.

When we follow these principles, software projects can become much more valuable to stakeholders, and more more profitable early-on. Lean software developments are easier to maintain in the long run, and much more likely to be a success.

The Lean Principles

1. Eliminate Waste
In software, this principle guides you to make sure that you and your team don't build in features before they're definitely required. In each iteration - or sprint of work - you only develop features that have been identified as being needed in the project to deliver the primary outcome. You don't try to second-guess the people who'll be using the software, and you don't add bells and whistles 'just in case we need it in the future'. Working like this reduces complexity in the software, and makes sure that what's built is going to be used.

Also, thanks to shorter delivery times, it means that when a requirement comes up, it's delivered before people begin to scope creep, or add 'nice to have' features that won't, in the end, support your main objectives. This keeps project costs down, and functionality high.

2. Build Quality In
Deliver each feature fully formed, and of high quality, with built in unit tests, and code that follows the pattern dictated by the architects. This means that code is easy to maintain in the future, and less prone to bugs or interfaces with bad UX. The team can then incrementally improve features when need arises, and those improvements aren't so costly or time-consuming to do.

3. Create Knowledge
It's important that the whole team knows the project, so that anyone can pick it up and work on it to the same high quality as the rest of the team. Pair programming, ongoing wiki documentation, and 'Brown Paper Bag' sessions mean that the time spent working on features is taken up by actual coding, rather than learning how the project's been built, or how a piece of work should be implemented to keep it in line with the rest of the codebase.

4. Defer Commitment 
A huge risk of large digital transformation projects is designing the whole project up-front before getting any feedback from the end user, or proving the assumptions that have been made that the project is based on.

When you defer commitment, you move from Waterfall development (designing the whole thing up-front, and then developing it) - which can mean that you spend months designing and developing a system, only to find that it's completely unfit for purpose - to iterative, or Agile development.

With Agile, you have a good view of the final outcome of the project, but you defer your commitment to designing and developing the output until you're absolutely ready to build it, and know that it's needed. This helps with the 'Eliminate Waste' principle, and when this principle's omitted in software projects, those projects are much more likely to fail.

5. Deliver Fast
This principle's an essential component, but can sometimes be misunderstood. Deliver fast doesn't mean to rush, or to skip stages, or to push your team hard to work long hours or work harder and faster. Those tactics are the quickest way to ensure a bug-ridden, poorly-thought-out project, and no one wants to spend their work days like that!

Deliver fast actually refers to how the project is delivered. We make sure that we stay on track with actual requirements, rather than assumed requirements by:

- Not over-engineering
- Eliminating waste by focussing on the priority features required in each iteration
- Breaking the project into small slices of functionality that can be rolled out quickly to stakeholders to get feedback
- Proving the assumptions that the feature is based on as we go along in small iterations

This way, we begin to immediately reap the benefits of the software, in effect delivering multiple, valuable, small projects in usable, manageable, affordable stages, rather than one giant expensive piece of guesswork.

This is the essence of the MVP - the Minimum Viable Product. What's the smallest version of this project that we can deliver - perfectly formed and beautifully usable - that'll immediately prove to us that the automation of this process is going to work?

How do we provide value from the start, and begin to earn back the cost of developing it while we're still developing?

To design and develop and deliver in these small-but-perfectly-formed iterations is a fantastic way of reducing the risk of the project, and of managing the ongoing cost of development. Identify the feature to automate, design, develop and deliver it, measure the results, and begin to receive your ROI while developing the next feature, or incremental improvement of the original feature, now that you've had quality feedback from the people who are using it.

6. Respect People
This principle's at the heart of everything we do at Remote. Putting people first; respecting the opinions of everyone involved, regardless of rank or status; looking after them to make sure that they are supported and part of the community; making sure that they're working with purpose, so that their days have meaning; and doing all we can to avoid pressure, burn-out, stress and upset.

Transparency, honesty, and full, regular communication is key to an efficient, happy team doing meaningful work. These principles are also essential to a successful software project.

7. Optimise the Whole
In their book, Implementing Lean Software Development, Mary and Tom Poppendieck talk about how the software industry is well known for its tendency to suboptimise. Creating vicious cycle; the product owner pushes the development team to deliver faster and under pressure. and so the code's rushed, the codebase becomes more complex, and the development time for each set of features gets longer.

This intersects with a second vicious cycle - longer development times mean that when it comes to testing, the tester has large amounts to test, and the feedback look gets longer and longer, and while the tester's testing, the developers are working on the next increment when there are already bugs in the earlier pieces of code, causing problems further downstream.

The solution is to reorganise the development team into value streams - multi-disciplined, smaller teams that can work together on smaller features - or pieces of value - and deliver them to the tester more quickly - and for the project manager to understand the capacity of these streams so that they don't overload them with work.

Coding well, within capacity, in small slices, in small streams, with shorter feedback loops, and shorter development cycles leads to optimised code; efficient, high quality delivery; and features that are actually wanted and needed throughout the project.

You can greatly de-risk your project by following these principles. They reduce the rollout time, and help you see your return on investment before the project as a whole is even completed.

With your business processes automated, and your digital transformation project conceived and delivered according to Lean principles, you can be much more certain of a successful, cost-effective and profitable business.

You can find out more about how we work at Remote, and how we can help you transform your business with useable, elegant, powerful custom software, by emailing me at [email protected] - I'd love to hear about your business, and share with you how we can help.

Paul McGillivray

Get in touch

If you'd like to talk to me about a project or an idea, get in touch, I'd love to hear from you.

Lets make a difference