How to Outsource: 3 Things You Should Prepare Before Nearshoring Software Development

If you intend to use a fixed-price model to cooperate with your tech partner, then your work is cut out for you. Before you sign the contract and start the work, you will need to prepare extensive specification - or hire a separate company to do it for you.

Only once the specification is prepared can your outsourcing partner estimate the cost and make you a fixed price offer. There is no way to start the work before putting effort into this time-consuming step.

When you opt for a time-and-materials model, the opposite is true: you can easily start right away, without any preparations and delays.

This prompt start is tempting and would certainly look good in the eyes of many stakeholders inside of your company. But it could also turn into a trap that could ruin the whole venture.

No matter your pricing model, you should take the right steps before the first line of code is written.

If you want to be covered, these are the three things you should prepare before starting an outsourcing partnership with a software house.

Let’s assume you’ve found a good software house, providing you with a seasoned team. They can start quickly, build a robust, well-engineered system and make it operational very fast by adding features with impressive speed.

Direction is just as crucial as velocity

Unfortunately, the hard truth is that it doesn’t matter how fast you’re going if you’re on the wrong highway. Many companies focus on speed so much that they ultimately find themselves astray.

Even an all-star team with top-notch technical skills won’t guarantee success. They need to work alongside someone who will make sure that the complex mechanism being built won’t be just a mere example of proper engineering, but will also solve real-life problems.

A hired team will usually have a difficult time identifying the real pains of your company and finding adequate remedies. They lack the context and connections to the right people at your company.

The context of your business is somewhat difficult to transfer to an outsourced team, because that kind of knowledge is usually unstructured, and very rarely codified into documents.

Extracting this context takes time. It also requires specialized skills and free access to every meaningful actor inside the organization.

Access to meaningful actors is also indispensable when gathering requirements for the new system’s features, usually by running workshops or interviews with stakeholders.

This all requires good connections—something external teams lack by definition.

The best solution to this problem is to extend the team by adding someone from within who already has both the context of the business and the connections. That is the role of a Product Owner.

The value of a Product Owner

A Product Owner with a vision of what has to be built is probably the single most important factor contributing to a project’s success. That one advantage alone can’t be overestimated.

And still a Product Owner has more to give: they should be the one responsible for budget utilization and deadlines.

All projects need to be somehow anchored by selecting two vertices of the project triangle: scope, budget, and time. The Scrum way of building software is optimized for Agile scope adjustments, therefore the project should be managed by tightly controlling budget and time.

By making the scope vary, Scrum may mislead some teams into thinking that the approach to budget and time should also be as liberal, and delivering some increment in each Sprint will be enough for the project to succeed.

The role of the Product Owner is to put the team’s progress into perspective:

• Is it enough to continue what we are doing now for the project to succeed?
• Do we need to make adjustments?
• How do we decide when to change the direction in which we are developing the product?

Without a Product Owner’s watchful eye, the team may still enjoy the comforting notion of doing a great job, but the project may go astray.

What if no one in your company is up for the task?

As I’ve outlined above, I feel like a Product Owner within your organization can bring maximum value. Such POs have the context and connections to support the development team.

However, the role of a Product Owner carries a lot of responsibility and requires a variety of skills and experience: delegating tasks, resolving conflicts, even storytelling.

If you’re facing the choice of appointing an internal PO that could lack the time or expertise to manage these responsibilities, it might be more cost-effective to ask your software house to provide a proxy PO. You will find that their experience in facilitating communication will quickly get your project off the ground and proceeding in the right direction.

As Eisenhower once said, “Plans are useless, but planning is indispensable.” Being Agile may encourage you to react to changes instead of sticking to the plan, but by no means does it advocate figuring out your next move at the last minute.

When assigning a Product Owner to the team, you should reserve some time for him to produce a backlog with the requirements for 3 or 4 sprints, to serve as an initial plan.

The initial backlog should be ready before the team starts working. Its goal is not to provide the final specification, but to allow the team to spot possible obstacles and try to avoid them before they invest valuable development time.

Those pitfalls can not only be of a business nature but also of a technical nature. In most cases, developers make some lasting choices at the beginning of project: they choose the tech stack and the tools, they make architecture decisions.

A Product Owner can help understand the overall goal of the system and possible roads that the team may want to take later on, making these initial choices more accurate.

The architecture planning part is widely overlooked in the Agile world. If your team ignores this aspect, they could face gradually declining agility. After over a dozen sprints, you could find yourself facing large refactoring efforts, or even rebuilding the whole system from scratch.

Have user stories ready for the initial rush

At the beginning of a project, most teams are very eager to start the development and produce the first clickable demo, then an MVP, in record time. And it’s hard to blame them for the enthusiasm.

But during that time, satisfying the demand for user stories can be a challenge for Product Owners.

What’s more, newly formed teams require additional meetings, transfer of context, and clarification of the requirements—all taking precious time that could be used to write new user stories.

No Product Owner, especially at the beginning of cooperation with new team, wants to be a bottleneck. In these conditions, the urgency can easily provoke the Product Owner to prepare soggy and half-baked user stories.

At best, such user stories will slow down the team. At worst, they will make the team build the wrong thing, thus resulting in a total waste of time at the very beginning of project.

It’s easy to imagine how this would decrease the team’s motivation for the whole cooperation. In this case, a big bag of user stories prepared beforehand will surely be the ace up your sleeve.

The last thing that you should take care of before starting the cooperation with an external team is the team’s dependency on other people inside of your organization. By identifying each dependency, you will be able to minimize idleness later on, when software development could be blocked by your own IT department.

A checklist before starting the project would usually include preparing code repositories and other internal tools like JIRA or Jenkins. Team members should get accounts or access rights to it on the first day.

If you are starting an entirely new project with no internal infrastructure requirements, you should also consider assigning someone within the team to help you set up and administrate things like AWS Cloud, hosting, and environments for development, testing and production.

If your system is meant to integrate with other systems owned by your organization, it’s good to set up calls with the people responsible for them, even obtain APIs if possible.

If your product will also add functionalities to a solution that is already working in production environments (working with real users), you will need to prepare a staging environment. The staging environment will serve as a test instance of the system populated with real user data to make sure the tests are relevant.

Getting user data is usually a troublesome process that requires you to collect a couple of approvals. Anonymizing the user data also takes some time. It’s best to prepare it before the team will ask for it.

To help you conduct a proper kickoff for your software project, we’ve created a sample agenda and kickoff checklist. By applying it, you’ll know all your bases are covered. Use the form below to download the Project Kickoff Primer.