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.

Ghyston
Ghyston

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.

Ghyston
Ghyston

We think you'll also enjoy

Understanding the Power of Digital Twins

We have been having lots of discussions about digital twins, a concept that's gaining significant traction. But what exactly are digital twins, and why are they causing such a stir?
Learn more

How to make 2024 the year you tackle the big talent shortage

As part of our series on practical business leadership advice for 2024, we’ve put together four steps you can take this year, to make your organisation more effective in its recruitment and retention, and to tackle another common issue: lack of diversity in the team
Learn more

Our investigation into the LastPass Security Incident

Here is our response to the recent news of a security incident at LastPass and our recommendations of pre-emptive actions to keep your data safe.
Learn more

Subscribe to our newsletter

The latest news and industry insights, straight to your inbox