From 'over the wall' to 'inception workshops', by Arjan Franzen

When I started becoming involved with outsourced software development, I worked for a medium-sized IT solutions provider. The teams we managed were located in India. Before we started, we were given a cultural sensitivity/how-to-interact-with-remote-teams course, and then we began working with the teams. I wondered what made this ‘over-the-wall’ way of working so dominant. I saw my colleagues operating in a similar way with their projects. This project management method can be summarized as a very simple customer-supplier type relation. In this specific case, it was also an internal relationship since both the India team and the NL team were part of the same company. The NL team can be viewed as the customer and the India team as the supplier. Essentially, the NL team was the intermediary between the ‘real’ customer (paying endcustomer) and the software developers in India. The solution provider built the software according to end-user demand. In my experience, this model is the simplest way to work together. However, this model is based on a number of incorrect expectations:

• In a relationship built on little trust, end-customers are expected to purchase a commodity in the form of software features.
• The specified requirements are sufficient to deliver a valuable product to users.
• End-customers expect the outsourced teams to ‘hit the ground running’.

These incorrect expectations need to be managed from the start. It turns out that the background for this ‘over-the-wall’ collaboration was by company design. The classic method of working was to create batches of work based on technical skills. This means that requirements are established first, then they gain approvals, and then they progress to the design phases, etc. Since this way of working was the standard, the end-customer intermediary team (our NL team) was essentially in charge of finding a solution for ‘the wall’. It may have been my first project with outsourced development; however, it certainly was not the project manager’s first. The NL team quickly set about managing the expectations and tearing down the wall.
Improving

We quickly learned that no amount of detailed specification (design or requirements) would render the exact software system you envisioned when writing the specifications. This means that there is a constant need for communicating with end customers (users, influencers, and purchasers). We needed to demonstrate a usable product based on the initial requirements. We had engaged the end-customers with per-feature communications about details, priorities, and designs. This approach solved 2 of the 3 project risks. There was, however, a challenge to this approach: the first workshop. This was the moment when the end-customer would realize how far along we actually were as well as how well we had understood their problem in the beginning. These initial workshops would take the longest with new customers, and we faced the risk of negatively influencing the end-customer relationship if we were not well prepared.
We learned to prepare these meetings in such a way that allowed us to uncover details that were not addressed in the initial specification. We included the entire team in the workshops, meaning we co-presented features and designs (if technical representatives were present) to the end-customer using a video conference solution to include the India team. We had taken steps not to separate development from design. This allowed feature design and development in lockstep. Achieving this was possible because we had established open communication and cultivated trust between all locations involved. Changing the way we communicated, from being focused on skills and phases to concentrating on value and features, ensured that we quickly gained a good understanding of the end-customer’s problem.