How to outsource software development if you are not an IT geek

So, you have got the approval to outsource the next innovative, business-changing software and you were tasked with finding the right company and coordinating the project from start to finish. You open G…, I mean your favourite search engine, type in software development services and start browsing through the endless list of SEO-optimised pages on how to find the perfect company to work with. Now you are even more confused. 3 hours later you are nowhere closer to knowing what to do next…

The task is generally a lot easier if you know what you are looking for and how to screen all these websites. But what if this is your first such project and your expertise in writing software is limited to writing sum formulas in Excel?

I won't dwell into actually selecting the right company to work with because this article wouldn't differ from the other thousands out there. Instead, I will introduce you to what such a development project should look like, just so your lack of knowledge and experience isn't abused. You might then be able to connect the dots and ask relevant questions in the screening call before you make the decision.

User-facing or backend only, that is the question.

One of the first questions that you need to answer, which will also have impact on the project plan is whether or not the planned software is to face the end users. A user-facing solution is one where there is actual interaction through an interface of some sort, it could include:

• Mobile application
• Web application
• Smart Watch application
• Voice assistant command
• Desktop Software
• Enhancement of current software with new buttons, fields or functionality

On the contrary, a non-user-facing software would work in the background. It could, for example be an automation tool which brings e-commerce orders into your ERP software. You don’t really gain anything to interact with, they simply “magically” get imported.

Phases of a software development project

Discovery, aka requirement gathering & sign-off

The first phase of the project focuses on defining the scope of what is to be done. Often case customers come to software development companies with a big document that consists of everything they had thought of. However, before such a document is translated into a solution design, it still needs a significant amount of analysis and further clarification sessions before it can be deemed clear. Reason - non-technical people who normally prepare such documents have a different mindset and might not include all the relevant details.

This phase is normally concluded with a sign-off by a major stakeholder. In big projects, this phase can last several months.

A question that often arises is, should I be paying for the discovery phase? The answer is simple, would you like to be providing services for free for a few weeks or months? No, you wouldn’t. Considering the time and effort needed to complete this, the discovery service is fully paid.

Remember to include a clear definition of what you expect the end result of this to be. It is not unreasonable to change the provider after this stage and a new provider should be able to pick up from where it was left off and not have to repeat the entire phase.

Some of the aspects of the project to be documented at this stage are:

• All the underlying business processes defined and described
• Specification of the to-be solution
• Prototypes & wireframes - not the final designs but drawings that help to convey the idea
• Project plan with information on the required engagement, expertise and working model
• Plus anything that you will use to deem the target solution ready. Be it drawings, tests, etc.

Remember, it is extremely important to have your team fully engaged in this phase. The outcome of this will define what will be built as part of the project and what will need to be handled separately (and for additional fee) with change requests (CRs)

Solution design and design testing

Next comes the solution design phase. It is mostly active on the provider’s side and reactive on your (customer’s) side. Designers responsible for the user experience, user interface, solution and architecture work together to deliver a plan for the final solution. They should use you, and your team as the business experts and the target users of the solution. It is therefore important that you have dedicated key users who will be available to answer any usability questions and test the initial designs, before they start the next phase.

If you are building a user-facing solution, there are multiple methodologies to test designs. One of my favourites here is Usability Testing in which carefully planned interviews are conducted with your target users and conclusions are drawn with regards to the usability and intuitiveness of the designs.

After this stage you could still change the provider. However, please note that you are already getting into the technical nitty-gritty in this phase so already defined designs could mean a restricted number of alternative providers or having to repeat parts of this project stage.

The result of this phase should include:

• User Experience journeys, personas, maps - depending on the used methodology
• High-fidelity user Interface designs - drawings of what the final solution will look like
• Architecture diagrams and interface definitions
• Business process descriptions
• Information on the technical stack

Software development & configuration

This stage is rather fully on the provider’s side. It is, however, useful to have regular checkpoint meetings with the project managers to see if everything is on track. If they are keen to keep you in the loop for some of the major topics then it’s also worth your while. The more you, as the end users are involved in the process, the more likely the final solution will meet your needs.

At this point, please remember - be curious and responsive but don’t be a nuisance.

Software testing

This is where things finally get exciting. It’s where you get to play around with the built solution, provide feedback, request changes and start learning the new tool. It is extremely important that you work off well-prepared test scenarios that reflect the target usage of the solution and are aligned with what was communicated as a project requirement at the beginning of the project.

The software company should provide you with a tool where you can log defects. I would suggest that raising problems isn’t done by e-mail as it’s simply too easy to overlook something and it does not give you traceability and reporting options.

If, during testing you discover functionalities that were built in adherence to the documented requirements but do not meet your needs, you should talk to the software provider. The sooner you do it, the better. Simple changes can often be made free of charge but major redesigns and rebuilding will incur additional fee. The process of requesting changes after a design sign-off is called raising a Change Request (CR).

The result of this phase is a sign-off from your side that the software meets your needs.

Cutover

If your solution replaces an existing software, carefully planned transition phase is key to success. In critical processes, we often cannot simply switch one solution off and another one on and expect everything to work. It has to be done in a structured manner to ensure consistency of data. A cutover plan is a step-by-step set of instructions on transitioning from the legacy to the target solution.

Why? Imagine that you are replacing an old legacy ERP system which receives orders from your 5 e-commerce shops with a new custom-built solution. Everything is ready to launch and you now shut down your old solution, change the configuration of the connectors to point to the new one and expect everything to work. Seems pretty straight-forward, right? What if, during the transition time, an order was placed in one of your shops? The customer made the payment but the order never reached your ERP system. You are in trouble.

This is why you need a cutover plan.

Go-live or deployment

The end of the cutover phase is called a go-live. Every project member dreams of this date almost every night. It’s the date when the new solution is switched on and brought to life. If you hear the term deployment to production, don’t think that you suddenly became a manufacturing company. To use something in production refers to actually bringing it into your business once the test phase is over. Once your solution is in production, you need to be careful. You are now dealing with live data.

At this point, you should make a request to the software company to carefully describe the?deployment process. Sooner or later, you will need to make changes to the solution, be it small or more extensive, you need to know how they can be shipped to production. In case you don’t decide to stick around with the same software provider.

Summary & tips to remember

If you have scrolled through the above few paragraphs daydreaming about what you’ll do tonight, that’s fine. Here is a short summary of the most important things and some additional tips to make your outsourced project a success:

• Discovery phase is normally paid
• Your team should be made available to act as business experts
• Request design testing before anything is signed off
• Ask for architecture diagrams and make sure they are updated in case of changes
• Define clear acceptance criteria for each phase of the project
• Cutover plan is needed if you are replacing a legacy solution
• Deployment is the process of making your solution live
• Ask for documented deployment process
• Make sure you receive the complete list of credentials needed for external solution providers
• Make sure you get a copy of all the security assets (if applicable). Often they are embedded in the infrastructure and cannot be retrieved.

Good luck with your next project!

Need help in managing your outsourced software development project or planning to outsource but don't feel confident doing it alone? Drop me a message on LinkedIn so we can talk about your needs!

P.S. I would love to hear about the challenges that you have experienced or your best tips not to forget when planning software projects.