The translation of an organizational need into a technical solution is a technology project’s core. That translation requires detailed knowledge of the organization’s operation environment (and their desired future state) to be married up with the technical skills from which the solution will be created. The size of the gap between those two pools of knowledge is a common source of troubled projects.

One project I recently observed had allowed a six step gap to form between the intended users of the system and those who were physically implementing the code. The user group spoke to their manager, who then spoke to the customer side business analyst, who then validated the requirements with their own manager before interacting with the vendor side business analyst. The vendor side business analyst then spoke to the technical architect and project manager, who then worked with the developers who were implementing the system. Needless to say the team was suffering from some serious communications breakdowns.

In the case outlined above, the team was not consciously aware of the gap they had created. The process of defining, approving and passing requirements had more or less grown on its own without the team ever sitting down and asking themselves if it made sense. Once drawn out on a whiteboard everyone involved agreed it was ineffective and was the source of many of the problems they were having.

Some interesting examples of the same problem have come up recently. As part of the Australian Justice department’s $54M CJEP program (Criminal Justice Enhancements Program ) one component (E*Brief) had to be scrapped and rewritten because the UI design used by the development team failed to meet police standards or needs. Similarly, one component of the UK’s massive National Health System project ($24B) was rejected by the ultimate users because the UI design was too clunky and difficult to use.

The gap between user and developer is a critical element in the success of any project. In many ways I think one of the great values in the agile development community has been to shrink the gap to the minimum (users and developers working side by side). Some organizations however still struggle with that as a concept because of a perceived lack of control. The balancing act however is to put in place whatever controls the organization feels they need without destroying the flows of information that are central to the ability of the project to deliver something of value.