Becoming the Distant Customer

July 3, 2005 by
Filed under: Process, Teamwork 

Most of the time when we train groups in the area of software requirements issues, they will be taking what they have learned to define requirements and build the corresponding system themselves. They will be working with an external client that isn’t involved in the training, and part of their role is to educate their client why it is worthwhile to spend the time up front so the requirements are in as good a shape as possible. Often the client has no software development savvy at all, and there is a clear distinction between the domain experts (the clients) and the implementation team – the group involved with the requirements training.

We recently had the opportunity to see an interesting reversal of roles in this regard. A large company that builds products with a significant software component, that generally does the work internally, is embarking on the path of software outsourcing. The group is about to make a major shift in roles – while originally both specifying and implementing the system, they are now being tasked with specifying the system, then acting as a distant customer to the group that will be implementing the system offshore. They have a huge challenge ahead of them.

As it stands now, it is relatively straightforward for the group to compensate for any shortcomings in the specification of the systems they build. Most of the team members have a long history with the company, and there is a great deal of institutional knowledge that has been internalized and no longer needs to be explicitly specified. Clarification of issues is a matter of a quick phone call, a short walk down the hall or simply turning to the next person in the lab. Even if team members originate from different parts of the world, cultural differences quickly dissolve as the team works together over a period of time, with the help of visual cues and familiarization with each other’s unique habits.

Indeed, many software teams succeed at delivering products with very weak specifications because of the advantages of collaboration in close quarters. It is one of the cornerstones of the agile approaches – collaboration in close quarters as a means of compensating for the challenges (rather than neglect) in thorough up-front specification.

With outsourcing, however, all the advantages currently leveraged by the group are about to disappear. Working with a group that is half a world away, who may have little experience in the domain and live in a culture quite different from our own, is an entirely new ballgame. There will be no short-cuts available as compensation for any problems with the specification, and the cost of these holes will be significantly greater than in the current situation. It is clear that the specification will become an even more critical document in the new environment.

Fortunately, the group is in a unique position where they have been involved in the implementation of similar systems, so they understand the feasibility and technical implementation issues. They can act as a wise customer that can convey the appropriate information required to specify the system, while at the same time capture that information in the form that needs to be passed along to the development team. They have all the pieces in place to produce an excellent specification.

But they cannot rest on that specification alone. Especially with an outsourcing situation, it is dangerous to rely on documentation, the lowest fidelity medium available, as the primary source of communication across the project. It is critical to emphasize close communication throughout the lifecycle, with constant effort to educate the development team, ensure that internalized assumptions are brought out and explicitly captured, and that a shared understanding is achieved. It is this shared understanding that must be captured as the information in the specification, and constantly validated with this ongoing dialogue.

It will be interesting to see if the group can make the appropriate adjustments to the rigor of the specification as well as the fidelity of the communication. They need to compensate for a dramatic increase in distance, time, cultural distinctions and difference of product insight. The challenge is great, and those that have successfully adopted the outsourcing model have relied on explicitly stronger specification and communication to perform well. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    January, 2018 – A workshop series to help you develop resilience in the workplace and in your life!

    Next open enrolment sessions start soon – contact us to get involved!

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • September 19-21, 2017 – Winnipeg, MB
    • October 3-5, 2017 – Regina, SK
    • October 20-22, 2017 – Winnipeg, MB
    • October 23-25 – Saskatoon, SK
    • November 14-16, 2017 – Winnipeg, MB
    • November 20-22 – Regina, SK
    • November 26-28, 2017 – Edmonton, AB
    • November 29-December 1 – Calgary, AB
    • January 17-19 – Calgary, AB
    • February 10-11, 2018 – Edmonton, AB
  • What People are Saying

    Fantastic course (Software Teamwork)! Great opportunity to interact with others in the field of project management with expertise in different industries. I gained knowledge from my team members and insight into my own self.

    — Jeanny Dhaliwal