These days, software is everywhere and just about every business relies on software developed specifically for that organisation. You might find yourself in a position where it’s necessary to commission and control the production of some code – a task which can appear Sisyphean because you don’t know much about the process.
That doesn’t mean you can't do it successfully, though. Here’s some insights on how to do it.
1. Have a process
The most important thing to know is that while technical knowledge of software development certainly won’t hurt, it isn’t a prerequisite. More important by far is robust process.
Specifically, we recommend leveraging the working backwards process which we use in all our software development projects.
An important element of developing a customised software application is to have a clear vision of the apps purpose, functionalities and benefits. Knowing what you don't want it to do can be equally as important as knowing what it will do - it gives the project scope. It prevents both over and under engineering - you feeling underwhelmed, or being left with a bill bigger than expected.
The most effective way to do this is to pull out a pen and paper, and leverage the working backwards theory to produce a roadmap for your application. This is when you create content (such as press releases, FAQ's etc.) as though have already developed your application.
The bottom line is: If you think you know what you're about to build, but can't document it, then you shouldn't develop it.
2. Know your options
Do you need to build software from scratch to solve your problem?
There’s two components to this question. One is that you shouldn’t custom-dev if there is something available off-the-shelf (this goes to reinventing the wheel). And secondly, there are a lot of freely available components which can be rapidly incorporated into an application, which means reinventing even parts of the wheel is unnecessary.
The roadmap should include schematics such as a user-interface mock-up, application architecture diagram, a business process model, detail on components and their functions. These schematics are crucial. They will drive discussions around product advancement towards completion, rather than progress reports being nothing more than a thumb suck from the developers.
3. Document, document, document.
Documentation is typically despised by developers; don’t let them get away with not doing it (because they will try). Documentation starts before development, but it doesn’t stop there: it should record what has been done, by whom, and why. Stay on top of it!
4. Collaboration
With a clear plan and purpose, your team can set about producing the code. Collaboration with your team is essential; here the “soft skills” of leadership dramatically outweigh any technical skill, particularly when it comes to dividing the tasks among members. You should also introduce and oversee a rigorous testing regimen, including automated and manual test scripts. Engage with the team on the concept of ‘test coverage’ which is the code which is tested). A good technique is to ask the team what their assumptions are, then where and how these are evaluated.
5. Put emphasis on testing
Again, developers tend to like producing code a lot. Testing it, not as much – you need to drive respect for testing and make sure it happens. In agile environments, where iterations of the software are rapidly produced, keep track of progress by referring to the roadmap; make sure each iteration passes into acceptance testing (with internal team members) before moving on to the next one.
Code review is next. This is technical, but it should be part of the process you are overseeing. Peer code review is a good idea, but you can also work through your schematics to confirm how the code meets the specified goals. And use the code review process to review documentation and security.
6. Properly introduce your new software to your business
Once your team has produced a viable application, it’s time to introduce it to the business. This is a crucial phase, because this is the point at which bugs, problems and other unexpected issues will crop up. Inevitably.
That’s why your team isn’t done yet. ‘Spray and walk away’ doesn’t apply here: be ready to deal with all sorts of problems. And you’ll need to be sure of operations readiness, as database and server administrators must plan for installing and supporting the new application.
Your application also needs to be ‘deployment ready’, while you should have a plan for rolling back if something goes seriously wrong (with software, this is always a possibility).
With any luck, and with the inevitable niggles which are likely to cause some wailing and gnashing of teeth, it will all go OK.
7. Close the loop
Which brings me to post-release.
After the software is up and running, it's a great idea to go back and review the process. After all, this ‘closing of the loop’ will stand you in great stead the next time round. With our dependence on software these days, it won’t be long before that happens.
Though managing a software development project for the first (or third or fourth!) time can be daunting for anyone, it's especially the case for those with a 'non-development' background. But it's not impossible! Your success doesn't rely on your knowledge of software development, rather knowing how to manage a development team.
If you have an application idea you would like to have scoped, start the working backward process with our experts in our complementary 1-1 planning session. Learn more about our offer, or book your session here.
