Single Point of Contact is a Best Practice

It is important that I begin this post by defining 'Best Practice'. The title of this post is not 'Single Point of Contact is a Good Rule' for a very specific reason. The word rule implies certainty, authority, and rigidity to change. Conversely, a best practice is the best way we have found so far to achieve a given objective.

Rules are easy, all you have to do is follow them. A Best Practice on the other hand can be much more demanding. It implies an openness to change should an improved methodology be discovered.

When striving to provide clients with the highest level of support we have discovered that working with a Single Point of Contact yields the best results, both for the client and our development team.

I've been making a big deal about the value of experiential learning. Recognizing that mistakes are inevitable allows us to incorporate these opportunities for learning into the constant evolution of our daily work flow. Without exception, having each client provide our development team with a single point of contact significantly improves the efficiency of the development process and yields better results.

Why? Here are some of the benefits we've experienced:

1. This individual makes important decisions regarding prioritization of work to ensure development stays focussed on the client's priorities.
2. The client develops an in house expert that quickly becomes both knowledgeable and proficient in managing their OpenEdit application.
3. Answers to critical path issues are answered promptly. This leads to rapid development cycles which allow more iterations and better delivery times.
4. Our development team and the single point of contact develop positive working relationships which promote smoother communications. We aren't robots and neither are our clients. Getting to know each other is important and impacts productivity.

It stands to reason that if having a single point of contact is important for the client then we should provide the client with a single point of contact also. Correct? Yes. During any development project we provide the client our team lead as well. This person might change throughout the project depending on the skill sets required during the various phases of development but providing the client with a contact throughout their development project is important. When an application transitions from development to support, we then transition to our online issue tracker. This tool allows the client to manage their application support by prioritizing the support requests they submit to the support team.

This all sounds very simple. The confusion occurs when you consider that quite often direct communication between various team members is critical to the project's success. To address this issue, we find the best way to accomplish effective communications within each project is message boards and file sharing. These discussions and files are accessible to everyone involved in the project and provide complete visibility of all communications to the Single Point of Contact so task prioritization remains intact.

Remember, this isn't a rule. This is a best practice. It requires education. Both the development team and the client need to understand that the Single Point of Contact is not supposed to be a bottle neck restricting the flow of information. The Single Point of Contact's primary role is to provide task prioritization, decision making, and progressive acceptance of each iteration delivered through out the project.