Ask any experienced project manager of outsourced software development the question, "What’s the #1 problem in outsourced software development?" and you will invariably get the answer, "Communication!"
Communication is a problem that does not seem to be a problem when it is seemingly happening, but bites you really badly down the road if you get it wrong in the initial stages of a project. Eventually, projects degenerate into shameless finger-pointing and recriminations between the provider and buyer.
I wrote some time ago about one technique that is almost 25 years old – Contextual Enquiry – in my column some months ago – Agile Outsourcing: The Power of Contextual Enquiry.
Contextual Enquiry advocates "pairing" with users that actually do the work. In business process outsourcing this is fairly common among the good service providers as they make it part of the transition process – a process owner from the provider will sit with people executing the process to observe and also practice doing the same process themselves.
In outsourced software development, this is less common, but it can save lots of hassles down the road when practiced diligently. In addition to listening to users and reading their requirements for a software system, Contextual Enquiry or Contextual Design advocates observe and interview users as they do their work. This is to ensure that requirements that users did not report, or alternative ways of solving the business problem of the user, are considered and included in a system’s design rather than just going with what users think they need.
Karen Holtzblatt, et al wrote a very good book on this almost 10 years ago: Contextual Design - A Customer Centered Approach to Systems Designs.
She has come up with a much better and sort-of Companion Workbook for this: Rapid Contextual Design – A How to Guide to Key Techniques for User Centered Design.
The new book on Rapid Contextual Design is much more practical and quicker than previous approaches and suggests activities and timelines, even down to individual days and sessions. Although this level of specificity may not work from very large development projects to smaller ones, the book offers a structured way to approach things during requirements gathering and design stages.
With many agile methods, the distinction between Requirements gathering and Design is fast fading away, anyway. Designs are iterated repeatedly to refine requirements, and the requirements refine the design.
This book may be a useful resource for people trying to apply agile methods to real and varied software development projects in the outsourcing context.
Making mental connections is our most crucial learning tool, the essence of human intelligence; to forge links; to go beyond the given; to see patterns, relationships, context. – Marilyn Ferguson
