Running Better Software Development Life Cycles: Perfecting Project Processes

The difference between a project succeeding or failing is so often attributable to a series of key moments in the project’s life cycle. From QA to testing, setting defined goals, and outlining clear processes, it’s these elements that will truly make or break your project.

At their heart, all projects are essentially just a series of processes that come together to form the final outcome. Each of these processes has a distinct ‘micro-outcome’ that adds to the overall project’s final result.

In software development, nailing down these processes can help improve your final outcome. Without great processes in place at each stage of a project’s journey, things begin to go amiss whether through user error or in the code itself.

With that in mind, we’ve put together a guide to project processes that should be in place during a development cycle. We’ll take you through this step-by-step, giving you a complete picture of what you or your team should be doing when undertaking a new project.

Defining scope

The first process to put in place is that of accurately defining scope. Your team should have a process that establishes:

• What the project is

• What features and functionalities will to include in the project

• How much time/”manpower” it takes to achieve these aims

• What parts of your systems the project affects

This process could be as simple as a development team meeting with the project owner and then a document that draws up the scope. The important part is that this process establishes exactly what IS and IS NOT part of the scope - which means anything that falls outside of the scope can be excluded from the project or billed as an extra.

Understanding UI/UX behaviours

Your team must have, or create, a process that understands the project’s functional requirements from a user’s perspective.

Why?

What one person knows to be inherent to your audience is not obvious to a development team. You might just assume that a developer knows to do X because your audience likes Y - but without a process to explain these behaviours and have developers understand them, the project can quickly go awry.

The process must establish the functional requirements (i.e. what should the product DO?) and the non-functional requirement (HOW it should do it?).

The behaviour stage must involve both the design and development teams. A typical process to handle is the ‘discovery’ phase - a session where the product owner meets the developers and designers and builds out a customer journey based on their requirements - giving design and development a chance to share their thoughts, concerns, and insight.

During or following the discovery session, designers should mock up interactions such as buttons etc. This helps developers see what is required and gives them the time they need to suggest technical changes. Meanwhile, as a product owner, you can ensure all of these suggestions make sense for your users.

Inherent knowledge for in-house projects

Another key part of this process is that there must be a system by which the product owner can explain inherent behaviours or knowledge that they understand, which a developer doesn’t. For example, if you’re a CTO at a property company, you may lose some property-related terms in translation.

For this, we would suggest documentation that lists terms key to the project and a specific terminology channel of communication set up between you and the development team - allowing them to ask questions if required.

Knowledge base

Your project must have a clear delivery process that is documented through a knowledge base. Do this before any code is written so that developers have the resource to hand - and so that any future work is consistent with the strategy. Your knowledge base will include:

• What tooling will it used

• How that tooling will be used

• Code styles/languages used

• Technical strategy

• Frameworks utilised

• How to find resources used in the project

The knowledge base should be updated as part of the development cycle with additional elements such as detailing any unusual behaviours in the system.

Essentially, a key process in your development journey should be the creation of a clear strategy document that lists the tools, languages, and technical elements needed as if a fresh developer has just hopped on the project.

Delivery strategy

If using a well-established system such as Agile, your actual development process doesn’t need to be documented. However, a clear map of the project’s overall processes can help keep a project on track.

For example, you could create a process map in a collaborative platform such as Maven to map out:

1. What is the step-by-step delivery process - how long are dev cycles, when are the key meetings, how does the dev team update the client?

2. How are development requirements or suggestions being logged? Which ticket tracker (such as Jira) are you using?

3. How will ongoing delivery monitoring occur? What is the process for when concerns occur around delivery timeframes?

Remember, even the best developers cannot say for certain when a project will be completed as there are always unforeseen issues. Building a process to accommodate for this is vital.

Testing & regression strategy

A clear testing process must be established and adhered to in order to prevent issues. This process must include:

• Automated tests

• Manual tests

• Pull requests

• Peer review

The importance of pull requests

A pull request allows a developer to document every line of code they’ve changed; this then goes to peers to review, who can look at it on a line-by-line basis. Not only does this process allow better testing of changes before they are pushed ‘live’, and implemented into the main code, but it also allows a team to impr ove on code rather than just fix it.

Sent by one team member to another, a pull request is the perfect example of a process that takes place on every single project.  It requires a clear and defined process to guarantee success.

As with many processes we’ve discussed, pull requests involve several team members, and each individual must deliver a certain element to complete the final goal. While SOP documents are a fundamental way of documenting each stage of a process, in instances like this, it’s helpful to have a visual representation of the process so your team can truly understand how it impacts the wider strategy.

Demonstration & feedback processes

Delivery is rarely the end of a project - especially at first when it’s very likely that there’ll be feedback and changes to make. As a result, your development cycle should also include a process to gather client feedback and work out how it will be implemented as smoothly as possible.

This process should include:

• How will you demonstrate the product/project?

• How often will it be demonstrated? This can be fluid - you wouldn’t be demonstrating a back-end coding project until there’s a front-end element to display.

• What mechanism do you have for collecting feedback and then actioning it?

Once these processes have been established, your team can run more efficient dev cycles that interface with a client in a productive way - rather than having to rush to demonstrate a project because it’s run over schedule and the client is demanding to see it.

Review and lesson learning

When the project is ‘complete’ (more on that in the final paragraph), how can your team learn from it? This may not seem like a ‘process’, but it’s valuable to decide on a way your team can review the project together and identify lessons learned. We would suggest doing this as a group session. Questions to ask in a session like this include:

• What went well in the project?

• What went wrong?

• What did we become aware of that could save time or mitigate issues in future projects?

• How can we improve processes or actions to make things better in the future?

However, development never really ‘finishes’ - whether the product is handed off to an external team or is maintained by the developers who built it, iterations are a constant part of digital products and their life cycles. With that in mind, the processes above should also be extended to iterations. To put that simply, run through all of the above processes again each time you approach an iteration phase.

By devising and sticking to these processes, your development project will stay on a clear track, reduce the potential for issues and ensure a client stays on board throughout the cycle. Our own development team uses these processes to deliver excellent software mobile applications that meet (and exceed) client expectations.