6 Tips to Help CTOs in Outsourcing Product Development

If the software product you have in mind is meant to draw in a big target audience, robustly serve a massive number of concurrent users, or scale without constraint for years on end, you are about to start building an enterprise-scale software product.

And this does change the game in many ways, adding more to the list of the pitfalls custom software projects of any size pose. The negative consequences of these pitfalls can easily increase your total project spend. They can hamper your product’s growth, result in poor product quality, and overextend your time-to-market.

Can you as a client (the business owner, CTO, CIO, or some other high-ranking executive) help make sure your outsourced high-scale custom software development project stays well on track?

Certainly, a very major role belongs to your software outsourcing provider. However, you hold a lot of leverage too even in those instances, when you don’t have almost any in-house development team, or when it’s just a fraction of your external team.

Let’s take a close look at  some of the pitfalls you should zoom in on, and find out how you can circumvent them.

Introduce uniform coding standards

Developing larger-scale software solutions typically involves a significant number of software developers. Their main job is to write the code that makes the software work.

While on a higher level (for instance, the task assignment and execution one) the actions of these numerous developers are supervised and controlled by their Team Leads or senior peers, on the code level they are frequently free to do as they please. The resulting hodgepodge of coding styles, personal habits, and personal preferences winds up in the solution’s code database. It makes it hard for others to deal with this code when fixing, refactoring, or expanding it.

Furthermore, this situation puts newcomers through the wringer of an even more difficult onboarding. As a developer leaves the project or company, the code they’ve contributed to the code database may become even harder to read by others – there’s simply no longer anyone to ask.

To aggravate, for their sheer size or for some legacy reasons, many high-scale projects often take more than one development team to handle. In many cases, these teams hail from difficult geographies. This seldom makes the interactions between individual developers from two different development teams more productive.

How to avoid this kind of a scenario and the ensuing slowdowns, delays, tensions, and blame-shifting?

You must do two things prior to getting  your software product development underway:

• Introduce uniform coding conventions (that must be upheld by all your developers in all your development teams. It is best to compose detailed written Code Structure guidelines, and make sure all the software developers involved are well-aware of these guidelines. It makes sense to create a single, Web-based source of information (for example, in the form of a Wiki) all the members of your different development teams can easily access.

Your code-related guidelines should contain the naming conventions for all the variables, functions, and classes used. See to it that your naming conventions and the resulting names clearly reflect the essence of the action or object they are used to signify. It is also necessary to describe the code-formatting rules, the way code-related comments are to be created, and the rules for the processing of errors.

• Include in your Code Structure guidelines a uniform list of statuses your software developers can use to describe the current state of a piece of code being added by them to your solution’s code database.

Use an optimal number of statuses. They shouldn’t be either too many or too few. Usually, 5-6 is the optimal number for any custom software development project. Each status must have a description that precisely indicates the state of the code it signifies.

For example, your statuses can include Fully Guidelines-Compliant, Noncompliant with the Guidelines, To be Fixed, Duly Debugged, Tested/<Testing Type>, Committed/<Name of the Code Branch>, and more. It should be possible for one piece of code to have more than one status at the same time.

It may be a good idea to request your development teams to make a transparent agreement to the effect that all their team members undertake to adhere to your Code Structure Guidelines. This agreement should also state that a development team is entitled to refuse to deal with another team’s code, if this code is not compliant with these guidelines.

Lastly, if there is more than one development team handling your high-scale software development project, you should pay a great deal more attention to code versioning. See to it your teams treat this matter responsibly enough.

Avoid poorly defined requirements due to a lack of project stakeholder buy-in

The development of any high-scale custom software application (for example, an enterprise mobile app) is preceded by a discovery phase. This phase focuses on collecting and formalizing the requirements and lays a solid foundation for the application to be built. The discovery phase of your project can on no account be dispensed with, skimped on, or sped up – it must take as long as required. Seemingly, these days most of the high-ranking business stakeholders fully realize this.

Simultaneously, quite often the whole thing boils down to just formally allocating a time period, during which the software provider’s BAs can talk to the client’s knowledge holders at some length and jot down notes. In a vast number of instances, this is downright not enough. What you must do is ensure a serious and sufficient executive involvement and buy-in.

If you are the CTO or CIO of a big company (say, 1000-2000+ employees) that wants to outsource a sizeable project, it is best not to have more than 5 points of contact for the different areas of project implementation – one per each of the areas (typically, they include Product Design, Core Engineering, Business Analysis, Testing, and Management).

Also, it is imperative that the requirements’ gathering effort be handled centrally and holistically by a single designated project actor with enough time and authority. In major companies, this role belongs to the Head of Product. The Head of Project interacts with the company’s product managers and business analysts, involved in implementing the project (whether the company’s own ones, or those of their IT outsourcing company).

Prevent misinterpretation of the requirements by your different software development teams

If you have a major software development project that is handled by more than one project team, keeping your development teams on the same page in terms of the project requirements is always essential.

At first, explaining your requirements to your external team’s Project Manager, or sending them a not so well-written 200-pager their developers can delve in when something is unclear seems like a solution. However, usually this approach proves seriously ineffective before long.

No matter how experienced your external Project Manager, it may be way too hard for them to capture all the details and convey them to their developers. This is especially the case in Agile projects, where no detailed technical specification exists. Moreover, the more development teams and PMs you have, the more likely you are to wind up with something off the mark.

To prevent your requirements from getting garbled along the way, you can:

• Explain the requirements for a part of the functionality not only to your external team’s PM, but to the rest of their team too.
• Create demos with explanations for the more complex functions. Make these demos available to the whole of your external team on a permanent basis.
• Send your external team’s PM (s) a list of all the features to be developed. Ask them to return this list, indicating who of their developers is going to be responsible for each specific feature (this is also something you can do to improve your change management).
• Try to put your external PMs in contact with your BAs, responsible for the functions these PMs are dealing with.

Your remote developers must be able to easily clarify any of the requirements they are engaged in implementing.

Preempt botched-up integration of code contributions from different software development teams

As mentioned before, high-scale custom software development projects frequently take more than one development team to implement. While this usually reduces time-to-markets, eliminates part of the hiring hassle, and helps source the talent you’ve been unable to find locally, the downside is certainly there too.

One of the major unpleasantries that may crop up (and recurrently so) is that the parts of your code, written by your different development teams will turn out to be difficult to integrate. This is quite a frequent occurrence in those cases, when this kind of integration is not taken care of beforehand.

As the client’s CTO or CIO, you can hardly rely on anyone else to take care of the possible integration issues in advance. To prevent such issues arising (or at least significantly mitigate them), initiate two moves from the outset:

• Go for continuous integration. Preferably, also make it a requirement for your custom software development company to have sufficient expertise in this area.
• Make it binding upon all your development teams, to use the same integration tools. It’s best to find out their command of these integration tools before the project’s kick-off.

Taking timely care of the possible collective integration-related issues can spare you lots of hectic hassle. It will help you avoid missed deadlines and unwanted tensions between the different parts of your development force.

Make the right choice of the testing approaches

The CIOs and CTOs of non-IT businesses, who act as project actors tend to be less knowledgeable of software testing as a process.

Usually, they also have very little, if any, knowledge of the various types of software testing and related nuances. No wonder – in many instances, even seasoned custom software providers opt for not so optimal testing approaches when dealing with high-scale software development projects. In any event, the testing of major software applications does have some peculiarities worth knowing about.

First off, the size of these projects makes it necessary to use a great deal of Automated Testing. Automated tests allow covering a sizable software solution more thoroughly. They also speed up the software testing process. Consequently, you should encourage your external custom software provider to create as many automated tests as possible.

Secondly, it is important that one keeps the tests relatively small and function-specific. Larger-scale testing and things like end-to-end tests frequently get thwarted halfway and then have to be re-launched. This inflates significantly the amount of time spent on testing the product.

Thirdly, it makes sense for you to find out who exactly is engaged in creating your tests. In large projects, your software provider may sometimes entrust this task to software developers, responsible for the corresponding functions. At first glance, it seems like this approach does have some logic to it. In practice, it often results in a motley variety of poorly written, barely usable tests that then have to be re-written.

Make it clear to your software provider you want all your tests designed by QA engineers and BAs, and not anyone else.

Don’t overlook the important HR tools you wield in software outsourcing 

Although the technical and Project Management approaches are key, the HRM practices you use carry quite a bit of weight too.

We all know that most software outsourcing companies declare that you can manage the employees they put at your disposal as your own ones. Simultaneously, your software outsourcing company creates the conditions and incentives that encourage your dedicated development team to show high performance.

Indeed, in most cases, you can largely manage your outsourced dedicated team as your in-house one. It is also true that custom software development companies in the popular software outsourcing regions like Eastern Europe lean over backwards to indulge their employees and encourage them to achieve high results.

And still, it is you as the client’s CTO or CIO, who holds some of the more important HR tools. These HR tools can help seriously boost the commitment and productivity of your dedicated development team.

Firstly, as far as you can influence this, try to give your outsourced developers a chance to master those skills and tools that they will be able to use elsewhere.

Secondly, even if your project is likely to run for a long period of time, your outsourced developers tend to regard it as a long-term, but still temporary engagement. Those who seek career growth do so within the framework of the company that employs them on a permanent basis, and not the one that has simply hired them for a time. You can use this to your advantage too: whenever such employees show really good performance, you should inform their job supervisors on your IT provider’s side accordingly. Your  external employees must be aware of your  willingness to support their career growth this way.

Similarly, you can propose promotions within your outsourced development team. This will both support their career aspirations and boost their interest in your project.