A few thoughts on how to organize the offshore development process to make it work well for the client
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.
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.
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.
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.
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.
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.
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.
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.
In Agile projects the quality assurance process consists of several stages covering all project stages and all system’s functionality.
Read previous: Q&A: What is custom software development?