Seraphis to Spreadsheets

Offshore development is a trade-off of cost and skills against communication. It will always be this way until, of course, demand exceeds supply and the only reason organisations consider offshore is for premium skills. Communication will likely always be an issue; as it is when broaching any two cultures, time-zones and work ethics. It is however unhelpful to blanket term – communication.

The issue with offshore communication is communicating project goals (and also progress against them as this is the only real way to confirm understanding). Operational (day-to-day/immediate communication) is generally OK (and much of the reason why non-French speakers can order food in Paris and be understood). Even complex operational communication can be understood offshore. The problem is in appreciating (and buying into) the end-game or goal and that means keeping it simple.

Ancient Greeks understood this when they simply bolted on Greek Gods to Egyptian religion (creating The Cult of Seraphis) as a goal-bridge to help them manage Egypt.

The simplest method of maintaining project tasks is to place them into a single spreadsheet (easy comparison between developers) and to establish a daily process for recording developer feedback e.g. proportion of tasks they have worked on the previous day/changes to effort estimates based on greater exposure. We will certainly want a way of “parking” tasks for a while (if one of their pre-requisites is not ready). Next, we will want a system generated “estimate” for when the task will be completed (based upon daily progress). This will be necessarily different to both the original estimate and the ongoing developer estimate. Finally, we want web-enablement. That is it; the minimum required to capture/communicate developer progress against common goals/estimate when code will be complete.

The process of being code-complete further refines the goal (coding is usually not the bulk of a project). Developers can intersect actual communication (bugs, “please make it do this...” etc.) with code to obtain an accurate representation of what is really required. Further communications – testing, QA/UAT, environment support etc. is easier.

A reusable example of the spreadsheet we have just described is here. Cell comments aid interpretation. Just apportion 1.0 of a day over the tasks for each developer and do it every day. Simple spreadsheets like this have genuinely helped manage complex offshore development projects. Project servers, operational BI, timesheet integration etc. add complexity and detract from the “what/who/when” simplicity required for communicating goals.