Add to Technorati Favorites

Categories

How to Outsource Software Development - Part III (The Blueprint)

Enough of analysis. Let’s attack this task-wise. What we will finally have, is a blueprint for successful outsourcing. For the sake of clarity, I am considering a single outsourced resource working on a client’s project. This is scalable.

The Players

Players on the Client side

The Handler - who is basically a proxy for the remote developer. The Handler is also the single point of contact for the Developer.

Players on the Vendor side

The Developer - the person doing the real work.

The Project Manager - managing the outsourced project from the vendor’s side.

Vendor’s local presence at the Client location - suggested, but seldom possible.

The Opening

A game well begun is a game half won.

Who are involved in the first requirements gathering phase?

All the players - the Handler, the Project Manager, the Developer.

Who will write the requirements document?

If the Client has an existing requirements document, it serves the purpose. Else, the Project Manager plus the Developer from the Vendor’s side have to do it.

Either way, the Vendor has to produce their own interpretation of the requirements and have it signed off by the Client. This is a separate document, if the Client already had a requirements spec. If the Client has to prepare the requirements doc, this can be it.

Who will prepare the project delivery schedule?

The Project Manager on the Vendor side, in consultation with the Developer. The delivery schedule has to be signed off / approved by the Client.

The Middle Game

Consolidating on the momentum.

Who will manage the Developer?

The Developer is managed by the Vendor, as a normal employee. No attempt is made by the Client to micro manage.

Who can access the Developer?

The Handler - directly, without any level of indirection in between.

How about the accountability of the Developer?

Weekly updates from the Developer to the Handler on the client side.

Weekly updates from the Developers to the Project Manager on the Vendor side.

How to measure the progress of the project?

The Project Manager should provide interim builds. The Handler should do a sanity check on the build and keep an eye on the progress.

How to escalate issues that are not solvable by the Developer?

The Handler should escalate issues to the Project Manager.

Defense - How to protect against potential Checkmates

Ah, the joys of fending off a ruthless enemy attack.

How to handle requirements changes?

First, change the original requirements doc.

Second, if required, the Vendor prepares the Vendor’s perception document to reflect this change.

Third, get the Vendor’s perception approved by the client.

Fourth, change the project delivery time line accordingly and get it approved by the Client.

What happens if the Developer leaves the Vendor for greener pastures?

The Client fills in from the redundant developer pool. This certainly has an impact on the project schedule. Who pays for the time impact depends on the understanding / agreement between the Vendor and the Client.

What happens if the Handler leaves the Client?

Bad luck. Some one has to fill in the shoes. But this will not have as big as an impact as a Developer leaving the project.

What happens if the Project Manager leaves?

The Vendor has to put in a substitute. Again, the impact is that serious. The key is the Developer.

The End Game

The final touch.

Who will manage the final delivery?

All - the Handler, the Project Manager and the Developer.

How to do post delivery support?

Think of it as a part of the whole project. The Client should engage the Developers in the same way as a normal project. This includes post delivery bug fixes.

Who does the testing?

The Client should do the testing.

There should be a test plan. If the Client already has a test plan, it should share this information with the Vendor. If it does not, then it should either prepare one, or have the Vendor do it.

With a test plan, the Vendor can ensure that the deliverable is meeting the expectations.

Nasty Question

What to do if the Client is not happy with the work?

Such a case should not arise if there are periodic deliveries. In the worst case, the Vendor has to bite the bullet.

This concludes my rambling. Comments are welcome.

4 comments to How to Outsource Software Development - Part III (The Blueprint)

  • [...] Blog Take on Everything « How to Outsource Software Development - Part I (The Issues) How to Outsource Software Development - Part III (The Blueprint) [...]

  • Aditya

    hmmm…nice process mainly simple and effective. simple in terms of roles are clearly defining…not to many if else…and effective in terms of client handler in touch with developers….less changes or bugs after release the initial phase and covering the real life things…

    It better to have some more than one handler from client side..one for domain another senior software guy (who can be a developer, architect)

    In this process client need to depend more on Vendor…better to have some client side architect..or developer(thats why 2 handler)

    The term “process” describes some theoretical concept…to make fulfill in the real life people involving in the process need to be more work oriented than blah blah…..

  • admin

    True. Too much of process is no good for small setups. I considered only the small companies that might wish to outsource 1 or 2 people work. Bigger team dynamics would be quite different.

  • Thanks for your effort in describing all the steps involved in Outsource software development….
    I really gathered lots of information from all the 3 post…

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>