Vishal BhatiaPART 2
In Part 1 we covered a number of tools that can be used to keep control of your project. If you haven’t read it, click here to read.
How to successfully manage your outsourced projects
If you’re entirely new to outsourcing or software development in general, then this section will be very useful; otherwise you can probably skip ahead.
We’re going to look at four simple techniques you can use to manage your outsourced projects. Which ones are most appropriate will depend on your situation.
Milestone tracking
The simplest mistake you can make with outsourcing is to micromanage everything down to each individual task. It is far more efficient to work toward clearly defined milestones. Your vendor will then be able to commit to a delivery date for each milestone.
For example, a milestone could be the successful integration of a new feature by next Wednesday.
However, for this approach to have a shot at working, your vendor needs to have a management infrastructure. If they’re just a “body shop” providing individual programmers and they expect you to manage them, it’s going to be a lot more difficult. You’d effectively need to be prepared to take them on as virtual employees, handling all the management with your own resources. To be fair, if all you need is a few programmers, it’s often a perfectly acceptable approach.
The important thing is to understand the difference between hiring an outsourced team and hiring individual programmers. While it might be cheaper to go with individuals, it can be so cheap you need to be wary. This is generally the case when the vendor expects you to do all the costly oversight.
In general, if you have limited management resources to begin with, then hiring cheap programmers will be a recipe for disaster. If you can’t give them the necessary oversight you’ll just end up paying out more by wasting time and fixing problems.
For example, let’s say you go to a cheap vendor and hire what you think is a full development team. What you actually get is a ragtag bunch of junior programmers who simply don’t have the skills to deliver.
This is a critical project for you, and you don’t have the time to cut your losses so you have no choice but to knuckle down and work with the ‘team’ you’ve got.
Your in-house project managers have to go through everything individually with your new team members, writing half the code for them as they go, and staying up all night to make sure it is done. You can probably already see…
This is NOT what outsourcing is supposed to be like; far from creating cost and time savings, it’s making everything more complicated and expensive while wasting precious internal resources.
As you can see, if you need anything more than a couple programmers to take on extra tasks, you really need to find a vendor with a proper management structure so you can actually delegate.
You should also make sure to manage by milestones so you avoid getting involved in day-to-day programming tasks.
Any worthwhile and professional outsourcing vendor will be more than capable of working to these principles.
Collaborate using audio and video
You should not underestimate how useful it can be to talk to your programmers via audio or video. In more complicated situations or where an objective has been misunderstood, for example, actually talking to each other can lead to a much quicker resolution.
Thanks to the widespread availability of broadband these days, you should almost universally be able to communicate with your vendor through Voice Over Internet Protocol, or VOIP services such as Skype.
For example, let’s say you’re trying to explain over email the difference between a purchase order and a backorder, as well as how the software should handle each. A purchase order is when a customer places an order. Whereas a backorder is merely a notification telling the customer the item they just ordered is out of stock. Unfortunately, this is proving difficult for your programmers to understand due to their slightly limited (although largely impressive) understanding of written English.
You call them on Skype for a quick chat and after five minutes explaining the difference using a simple example, they fully understand what you’re trying to achieve and quickly implement it in your software.
Of course, it’s also possible to use screen-sharing applications to allow programmers to work well together, to see what your vendor is seeing during a meeting or vice versa.
Face-to-face
If you’re one of those people who would much prefer doing business face-to-face, I don’t blame you. This can make outsourcing seem a bit more daunting, so here are some samples of when and how you might want to meet with your vendor face-to-face.
Let’s say you’ve been communicating with your vendor by email and instant message since the beginning of your project a few months ago. Everything is going smoothly; it’s not as if there aren’t challenges, but both sides are really happy with the arrangement. Still, you decide to meet up and you fly to India to visit their facility.
The meeting is awesome and you really start to establish a personal connection with these people who have previously just been names in your inbox or voices on the phone. What’s more, you blast through a whole bunch of great ideas and everyone is really excited to take progress to the next level.
Put simply, in this instance, a face-to-face visit has given you accelerated and improved results.
You haven’t gotten rid of every communication issue or nagging concern, but you do now have a ‘real’ relationship with everyone involved and a much better chance of taking your project from good to great.
The question on your lips is probably something like, “So do I have to have face-to-face meetings for outsourcing to work?” and the answer is:
Absolutely not. If you have to visit your vendor or vice versa in order for the arrangement to work, then something has gone hideously wrong. The whole point is to work remotely.
Meeting in person is simply a very good way to accelerate results in an already productive working relationship.
Test-driven development and continuous builds
Integrating software created by multiple developers can be a difficult or even arduous process. It never works the first time, does it?
Even when you try to plan ahead and leave time to fit everything together, the different parts never communicate properly. You planned to actually test the functionality of the software to see if it does what it’s supposed to, but the stupid thing won’t even run.
Unfortunately, many developers fail to plan for these kinds of integration issues. Different programmers do things differently; so differently, in fact, that the code is incompatible.
The only real way to combat these challenges is to have frequent builds of your software, so integration problems are caught and dealt with as they arise.
Then you can make everything even smoother by automating the testing process to avoid the tedious nature of human error that comes with manually testing each software release. This is called ‘regression testing,’ and it works by conforming that existing functionality is not broken by each new release. The more you test, the bigger your suite of automatic tests grows and the more efficient the process is.
Frankly, these are basic and standard parts of modern software development so any reputable outsourcing vendor should already be familiar with them and their use.
Of course, regression testing becomes more useful the more you do it and, thus, only becomes really worthwhile for larger projects. Smaller endeavors will not start with such a rigid framework and there will never likely be a need to use it.
On the other hand, complicated or long-term projects likely to survive multiple releases will benefit greatly from having an automated testing process. It won’t completely remove the need to test your software but it will help ensure new releases don’t break anything critical, and you will catch bugs quickly and easily.
Furthermore, automated testing allows you to do something very cool called test-drive development, otherwise known as TDD. With this approach, testing is put at the forefront of development with programmers testing each new feature before it’s even implemented. Of course, the test will always fail, but the point is to define the parameters for success so you know for certain when the new feature is completed and actually works.
TDD is essentially hardcore unit testing where each module or unit of code is tested independently so you can ensure there are no bugs within them before trying to integrate everything.
You really want to try to enforce unit testing; and using TDD effectively makes it mandatory.
Programmers define their own unit tests and these are then checked into your source code control system along with the actual module code. These tests then become part of the automated regression tests and are implemented every time programmers check the code in the future.
A really big benefit of TDD is almost seamless integration since generally, you will be able to add new modules or update old ones, whenever and without error. This allows you to integrate frequently or, in fact, every time someone writes some new code.
What’s more, you can see real time progress on your software development whenever you like. If you’re project is a web application, you can even have your web browser point directly to the work in progress so you can check-in as and when.
Of course, the biggest benefit by far is the almost entire elimination of infuriating and costly release delays caused by integration errors.
How agile are you?
If you would prefer to use a less structured, more collaborative approach, you could consider using agile development.
When using this approach you focus on explaining your requirements to programmers through ‘user stories’ or, in other words, the experience your users should have while using your finished software to solve their problem.
You can then simply work with your programmers to decide what features are most important and prioritize their activities.
The only downside to agile development is the need for frequent meetings to discuss progress and requirements. However, this irritation is counterbalanced by the fact that this process is proven to be the most effective way to overcome communication difficulties and convey critical information to a team.
So the question remains: should you use agile development? We generally try not to dictate what you should or shouldn’t do and it is very dissimilar to traditional software development yet…
You’ll find it’s hard to deny the impressive results. What’s more, the methodology is rooted in sound principles and experience. We’d encourage you to try it out.
Which management style should you use?
Frankly, this is a conclusion you need to come to on your own; we can’t answer it for you. The right answer will depend on what exactly your project is, how complex it’s likely to be, and what your timeframe is for development. You would be wise to discuss all this with any possible vendors and try to find a solution you are both happy with.
If your project is likely to go on for a long time, have multiple releases, or need a good deal of ongoing support, then many of these techniques like regressive testing or TDD will become mandatory for success anyway.
Whatever you decide to do, always make a concerted effort to track the effectiveness of your efforts so you can avoid disasters before they happen and improve on greatness when you find it. The next blog post will teach you how to track and measure the success of your project.
