Q&A: How to organize the outsourcing software development process?

outsourcing software development

A few thoughts on how to organize the offshore development process to make it work well for the client

How should we start co-operation with an outsourcing software developer?

Typically, the client approaches the outsourcing company with a problem that needs to be addressed. So, it is essential to have a clear idea on what you want to achieve as the result of the project. At the beginning of the relationship with a new client, we usually offer a pilot project – it could be a small fixed-price project. The pilot project is fulfilled in much the same way as a large project, and during its implementation, both parties will have time to assess whether their cooperation is comfortable and to make sure that the client does not face any additional risks. The pilot project helps the contractor to understand how the client’s internal processes work, who is responsible for what, etc.

How does a modern software development process look like?

At Aplana, we use Agile approach where a project consists of a series of sequential “iterations”. An iteration could be considered as a very small project with a project plan (list of tasks) at the beginning and some deliverables at the end. An iteration usually takes not more than 3-4 weeks, at the end of each iteration the client sees the result of the project stage and shares their opinion - whether they are satisfied with the progress and what they would like to change.

What minimum interaction level with outsourcing team is required?

The client appoints an authorized representative as “product owner", who actually becomes a member of the team and interacts with the team every day, making prompt decisions, and ensuring agreement with the client. This is the best option where “product "owner" always stays "in the loop" of the team's work.

If there is no such person on the client side who can play the “product owner” role then (while, of course, this is not an ideal situation), the client must still review current results and give some feedback to the team at the end of each iteration at least.

Do we need a software requirements specification document (SRS)?

In the classic approach to software development the whole project is based on a single software requirements specification documentation, which is prepared at the beginning of the project.

In theory, the clients should produce their own SRS – a very large document that describes the future system in fine detail. But usually very few clients can come up with a workable SRS. So, it generally falls to the outsourcing partner to study the customer’s business, to understand their requirements, to describe them in a structured way in the form of an SRS document and to send the SRS document to the client for discussion and confirmation.

Because the most active, evolving tasks and processes are usually selected for custom software development, by the time the SRS is ready, the customer’s needs have often changed. That costs a lot of time and effort. In reality, it’s almost impossible to create and approve a large-scale SRS, because the market is changing so fast. The customer must develop new products and services to keep up – and it’s the same story even for banks, insurance companies and large industrial enterprises. We find that typically business requirements change once a month at least, so while you will try to develop/review/approve a large SRS document, there is a big chance that requirements change and you will need to change the SRS document again, again and again.

That’s why for the recent years Agile iterative approach have been gaining popularity. In this model, the client may change the requirements from iteration to iteration, but not during a single iteration. Each iteration gives the team an opportunity to focus on the task at hand before completion of the next stage. So, such model is flexible enough to adapt significant business requirement changes during the project without software development process failure.

If we have no SRS then how the requirements will be documented and managed in Agile project?

In every project, there is a hierarchy of requirements – top-level business objectives, business requirements, system requirements, developer task descriptions. Sometimes a group of business or system requirements is called “product feature”.

Typically, we are discussing top-level project goals and main business requirements at the beginning of the project during a 1-2-day customer Workshop. Workshop is a “brainstorming” session where we have an open discussion on all project goals / requirements and exchange ideas. Of course, high-level requirements are documented and prioritized after the Workshop.

Then you must create a project implementation route, i.e. a subsystem or module development sequence. Sometimes a customer, having developed the first part of the system, can give us very valuable feedback on implementation, which we use to adjust the next stage of development. This is a big advantage of iterative development. So how do we manage requirements during the project? Every system module could be quite large so it should be decomposed into smaller pieces of work called “tasks”. A task should be small enough so that one developer can implement it in not more than several days. Every development task should have a clear description (system requirements) so the preparation of such descriptions should be done before the task is assigned to a developer for implementation. That is why requirements management process runs in parallel with the development but one iteration ahead. For example, during iteration 2, system analysts are preparing descriptions for iteration 3 and developers are working on the tasks prepared for them during iteration 1 – so it’s a quite clear and reliable process.

How accurately can you calculate the project budget and when?

Naturally, if requirements are modified, the budget can change as well. After the first meeting, we usually give customers a tentative cost for the entire system, and its accuracy. Also, we discuss budget reserve (usually around 20-30%) to allow some requirements flexibility. Until the final budget goes beyond the reserve, everything is fine. And then we alert the customer when they start introducing requirements that go beyond the preliminary approved budget. All the tasks that go in for development, as well as implementation time, are thoroughly documented so it is possible to track all budget spending as well as do some forecasting.

What happens when the total project budget exceeds the risk reserve?

The customer makes all the decisions – based on the business needs. The customer is fully aware of what part of the budget has already been used, how much is left, as well as whether their requirements are included in the core functionality of the system or whether they are considered optional.

Cost management options might include, for example, taking development team members off the project – this will delay launch, but reduce monthly budget.

Can the customer dictate who is on the team, say: "I need three Java programmers, and I am going to manage them myself"?

We work in a completely transparent model so the customer can participate in discussions with potential candidates on all project roles. But they cannot say for example “I need three Java programmers, and I’m going to manage them myself.” The customer doesn’t personally decide who would be on the development team. The outsourcing partner is responsible for the deliverables quality and for the deadlines, and it’s the partner who takes final decisions on project team members.

How is the quality of development deliverables ensured?

In Agile projects the quality assurance process consists of several stages covering all project stages and all system’s functionality.

  1. Initial testing of each function is performed by the developer. This stage of testing is conducted in the working environment of a developer.
  2. Quality assurance testing – this task or set of tasks go to a tester or quality assurance manager who check it for compliance with the customer’s requirements. This stage of testing is performed in the environment of the quality assurance manager, and this is important that this environment is different from the one used by developer because in QA environment, the developer has no right to delete or change anything. If problems are identified at this stage, the task goes back to the developer for follow-up revision.
  3. Integration testing – the associated sets of tasks (a substantial part of the system, possibly a subsystem) are tested to see how they all work together. If we are talking about the whole system module that the customer can already adopt, its additional testing is done using automated tools.
  4. Acceptance testing – usually takes place on special “staging” environment on the customer’s infrastructure. Staging environment replicates the customer's real working (“production”) environment. The customer uses it to learn to install, implement and configure the system. The outsourcing partner has the right to have “read-only” access to this environment, but they cannot take any actions here.
  5. Trial implementation – finally, when the software system is approved for trial implementation, it is installed in the “production” environment of the customer and becomes available to end-users. The outsourcing partner has no access to this environment, because real business data is stored and processed there.

Any advice about data security?

There are two important points related to data security when working with an outsourcing partner:
  1. Never use real data in any of development environments – real data should be used in “production” environment only. Of course, some data is required for the team during development and this could be achieved in two ways – anonymization of real data (done by customer) or fake data generation (prepared by the outsourcing partner).
  2. Do not give any access to your “production” environment to the outsourcing partner. If any problems occur in the “production” environment, the customer’s specialists reproduce them for the outsourcing team in the "staging" environment.

Read previous: Q&A: What is custom software development?