The Logical Developments logo which is a diamond with the letters L and D inside of it. The letters are offset from each other vertically while also overlapping horizontally. The each sit inside of their own rectangle. The logo is in the "Classic" variation with a yellow to white gradient bar above it and red to white gradient bar to it's left. It all sits inside a white right angled triangle in the top left of the thumbnail. The thumbnail has the title: "Quote through to deployment: The Logical Developments design process" written along the bottom. "Quote through to development" is in white, while "The Logical Developments design process" is italicised and in yellow. This is all on a blue background. In the middle of the image is a 'sketch' of a design document - it has a placeholder for an image and header, with non descript lines of text. It also has a place holder ER diagram, the bottom of the document of the document is missing to suggest that it is still in process of being written.

Quote through to deployment: The Logical Developments design process

Aaron Muilne - Sep 15, 2022

What does it look like to develop tailored software, and what is involved?

When comparing 'normal' software options, a process that you might go through involves research: canvassing all the available options - weighing up the end cost (which might vary on how many users will be using the software), features - what it can do and does that suite your needs, support, customisation - can it be tweaked should adjustments need to be made. The next step will be purchasing and licensing before having the software installed in your business after which any required training takes place and everyone begins using the new software.

In a way, developing a new piece of software or adding new features is quite similar. We sit down with our clients - and potential clients - and spend some time canvassing their needs. During the research phase we explore how many users will be using the system - exploring the desired outcomes for each kind of user (e.g. the administration team will need different tools than the finance or sales team). After spending some time to understand the needs, these can be turned into features that will meet those needs. Should the quote prove satisfactory, we move into the purchasing phases - the specification, development and deployment are often tied to milestone payments.

Sometimes, when dealing with existing clients, a requested change to their software is small enough that the change can be achieved with only a little time spent coding and testing. In this instance the cost is usually taken out our clients’ support hours. The relevant documents that outline the change will be notes from a phone call or an email that follows up the initial request - this puts it into words that can be referred back to.

If a client approaches us and after assessing the apparent difficulty, size and scope we decide that it will require substantial amounts of work, we'll organise a (series of) site visit(s) to complete the research phase. In these meetings we take detailed notes that are then compiled together with relevant source documents, email correspondences, and links to other systems. We then sit down and compile a quote for the work that needs to be done.

The quote document outlines the problem that the client would like addressed - it will accurately describe the rationale behind the changes (to the existing software) and what the users will be able to do and the outcomes that can be achieved once the work is done. When working on pre-existing software the quote will also summarise any infrastructural changes that will need to be made to accommodate the new feature(s). This is to demonstrate that we understand the needs and they are addressed with the proposed solution.

The final detail that shapes the quote is whether or not the work that will be undertaken is breaking new ground for the team. The quote also considers our clients ideal deadline. These two factors shape the hours involved and outlines what the overall priority is for both parties.

After the quotes have been presented and a decision made, we get to work creating a specification document. This document will use most, if not all, of the materials that were utilised to create the quote - a lot of the information needed to accurately quote the prospective hours undertaken is needed to write the specification document. The specification document, once finished, will be a blended document of high level and abstract details mixed with low-level and detailed information that will guide the development team. It is intended to be easily read by all parties and will be used as the standard by which the work will be evaluated. Both the developers and our client should be able to read through this document and say that the software should do X, Y, and Z while looking like A, B, and C.

Where the quote outlined the problem, and the costs involved to develop a solution, the specification provides the solution. If the problem is 1, 2, and 3 then the solution to 1 will be A, B, and C; the solution to 2 will be D, E, and F; the solution to 3 will be G, H, and I. These details are outline in a descriptive summary, accompanied by any relevant screen shots, mockups and diagrams to explain the changes. For the developers, there will also be a list of new methods that will need to be written, or existing methods that will be updated. Lastly Entity Relationship Diagrams will be included to show the relationship between the data that is stored; likewise there will be lists of new database field entries. The end result will be an explanation of the new functionality that is being added broken down by feature.

In short, the process looks like this:

  • 1. Meet with client.
  • 2. Discuss the requirements.
  • 3. Provide a quote with a summary of the requirements and mockups (if needed).

Repeat steps 1 - 3 as needed until both parties are satisfied.

  • 4. We draft a specification document.
    • Take the requirements from the quote, outline how they will be addressed
    • Add further illustrations or mockups of the product/feature
    • Repeat steps 1 and 2, iterating and refining the specification document. At this stage, this document needs to be clear as possible with firm details that outline the expectations for both parties.

While theoretically the conversations from the quote stage should be able to drop right into the specification document, requirements might have shifted or proven to be more complex than anticipated and now need to be re-evaluated either to be shelved until next time or update the prospective timeline.

  • 5. Agree on the final form of the specification document.

This summary has been adapted from our Development Life Cycle document.

As technical as programming is, it is also a rather creative endeavour. Looking for ways to solve the problem takes time; while the brunt of the problem solving happens in the code, having an idea on where to start makes a big difference - it sets the direction of the project and allows for better time line projections.

Looking back over How long did it take, we also want recognise as frustrating as it might feel spending a lot of time up front in discussion, it will pay dividends in the long run by producing a robust document that will guide the development phase. Once the document is finished and agreed up, development can begin and the sooner our client will be able to start utilising the new software.

The sooner a conversation is started, the sooner we can get into building the tools you need!