How to get your software project done faster

What can YOU do to get your software project done faster? Here, our Technical Project Manager David Linfield discusses what you can do to help develop the best product within a realistic time frame.


What can YOU do to get your software project done faster?

When considering a new software project, clients usually have a timeframe or a deadline at the forefront of their minds. Most will instinctively understand that rushing things can lead to a lacklustre product that is not fit for purpose. But good software development doesn’t come cheap, so inevitably time pressure always ranks high on their list of priorities. Guess what? We feel the same way. In this post we wanted to turn the tables and ask not what we can do for you, but what you can do to help develop the best product within a realistic time frame.

Own the project

So, you’ve decided you need a piece of software that will make your business even more successful. Everyone in your firm is excited by the possibilities and wants to see it come to fruition as soon as possible. This wave of enthusiasm elicits promises from staff members to do everything they can to make it happen. What sometimes happens next, unfortunately, is that the initial burst of energy can get diverted by the inevitable clamouring of other no doubt legitimate competing priorities. The software project must then battle for air on everyone’s separate to do lists.

It’s a situation that can often leave the developer feeling thwarted, spending time chasing key players for design decisions, critical pieces of information and waiting for testing feedback. This can create delays of days, weeks, even months and frustrate all parties if the project stalls or heads in the wrong direction. The most effective solution is for you to assign, from day one, an individual to be the ‘product owner’ from your organisation, someone who understands what is needed, has deadlines in mind and will take internal responsibility for chasing the necessary people and keeping the project on track.

Plan, but don’t over plan

Planning and forethought is an essential part of the software development process. But how long should you spend planning? At some stage planning and scoping needs to stop and work needs to be done. It’s not unknown for clients to spend years in these early stages, refining and adding to the specification in minute details before they finally decide to get a product developed.

At Ghyston, we prefer to start the development process as soon as a broad plan with high level deliverables has been defined. Based on this information, a core system will emerge and can be tested and played with in real life by its users. It then becomes incrementally easier and quicker for those users to identify which additional features really matter. Having a practical approach to evolving the specification based on early stage testing means that developers can react quickly to any changing priorities or budget constraints, ensuring resources are focussed on what really matters.

Monkeys and typewriters

The influential software engineer Fred Brooks once pointed out that although it takes one woman nine months to make one baby, "nine women can't make a baby in one month.'' The same is true of software development. Clients working to a tight timescale will sometimes suggest we throw more and more developers at a project to hit the deadline, but Brooks’ law states that one too many staff members can tip the balance and actually slow things down. This means developers end up treading on one another’s toes and creating coding conflicts. Staff are left waiting for other elements to fall into place or even end up duplicating work. Trust that we know how many people it takes to deliver your project on time.

Ready to launch?

If your business is car production, then it is of the utmost importance that your product is perfect when it goes to market. No consumer is going to be happy if the windows don’t open or the lights aren’t sufficiently bright. In software development, this isn’t necessarily the case – and it’s one of the elements of what we do that we struggle to get people to understand. You don’t need the software equivalent of fancy trim or heated seats on day one, these are fiddly details that can be added on later. The most important thing is to get a version of your software up and running as soon as possible: we call this the ‘Minimum Viable Product’. Catchy, right?! But seriously, your users won’t miss what they don’t know about and will be your most important test audience, telling you what you really need to add or alter to create a product that works for everybody.

Be realistic about what’s achievable with the resources you have at your disposal. By doing things at the right speed and in the right order, by giving the project to a single owner and assigning a suitable number of developers you’ll be able to launch a well-tested product that comes in on time and budget.


We think you'll also enjoy

Learning to Build Real-World Technical Solutions: My Experience as a Ghyston Intern by Reece Coombes

Over the last 8 weeks, we have had a group of interns working closely with the team here at Ghyston. Before they left us, we asked a couple of them how they had found the experience. Reece Coombes reflects on his time with us – read on to find out more.
Learn more

Do we need to be accountable for the longer-term impact of technology?

We are excited to be shining a light on one of our recent projects that won Innovate UK funding for its three worthy goals; aiding the local economic recovery from COVID, reducing discrimination in AI, and combatting climate change.
Learn more

Do you need an extra pair of hands to deliver your 2021 technology plans?

If you are considering your options for delivering your ambitious 2021 plans then this blog post will help you identify when working with a partner could help and how to get the best out the relationship.  
Learn more

Subscribe to our newsletter

The latest news and industry insights, straight to your inbox