Refactoring communication

As software developers, we strive to find increasingly elegant ways to solve problems. Sometimes this involves eliminating foreseeable issues long before they occur. At other times, minimizing the Lines of Code (LOC) leads to the simplest solution. Optimizations of these improvements are multipliers that allow you to handle progressively complex problems with the same resources.

The quest for elegant solutions can apply to other aspects of projects as well, such as this example of refactoring a recent team/customer communication workflow. In this example we have two companies, each with two primary partners and interactions occurring between the four participants equally. This works for awhile, and can encourage the creativity and collaboration needed at the beginning of a project. However, as the number and specificity of the requests/responses increases throughout the course of a project, ensuring the delivery of each one, and their associated responses, can easily become a time intensive and error-prone activity. There is a better way:

Even with this nearly trivial number of participants, establishing a point person within each company can cut the lines of communication (LOC) in half, thereby allowing the two teams to transfer requests and responses in a more efficient manner. Requests and responses can also be batch-managed by the point people as the traffic increases. This chunking can also minimize the number of interactions that need to occur, saving the time that is typically required to find an open schedule time to meet.

Many things in our lives are systems. Which of yours can use a little refactoring?

This work is licensed through Creative Commons.

Posted on Feb 11, 2009 by Robert Bousquet

Post Your Thoughts