One of the greatest challenges when running a software inclined technology company is that many times client requests are preceded by the words “We are looking to build a simple system that…” quickly followed by a sketch or bullet points on an A4 of the perceived system, complete in its glorious simplicity. This is often a primer to the bombshell on the budgetary constraint present and a pressurized request to drop a number; how much will it cost…I want to know now!
The journey to educating a client on what is takes to deploy a system, is wrought with humor and in equal measure misunderstanding. Misunderstanding because the exchange of value begins at the moment of engagement and not at the point of deployment which is where most client minds are docked. It is imperative that any software development company have a well thought out engagement pipeline that will deliver value to them – usually monetary and their clients – by way of a deployed system or knowledge transfer.
We subscribe to a three (sometimes four) phased process that borrows heavily from the agile methodology practice. Working with high level descriptions, our first phase is a needs mapping exercise. While a client may have sent an RFP or brief, experience has shown many times those documents are a copy, paste, modify affair . This phase allows for a structured needs discovery workflow that will prevent or minimize scope creep and ensure we keep on time and on budget. Design thinking plays a central role in this phase.
The second phase covers system architecture where research on the best tools and stacks that will deployed in the building of the platform is done. Justification for all choices should be given. The output from this is a comprehensive breakdown of the technology used and deployed, with a matrix that will show the value proposition of each. Remember, it’s a solution we are after and not a technology showcase.
We don’t look at the build out period as a phase in itself but bundle it as a final phase alongside deployment, documentation and training as they happen concurrently.
A key component of this lifecycle is that of support and maintenance, and its value is calculated as a percentage of the whole project applied annually inline with a service level agreement that must form part of the project documentation. Many clients would wish to skimp on this bit, and many solution providers would oblige, much to the detriment of the business relationship as needs and technology changes, without a framework to manage the change.
The simplicity that a client requires on the front, is supported by complexity in the back and it pays to both apply and understand the process that prevents chaos and loss of value in the longrun.