This week I was working on a project that my company has had for a very long time. In fact, it is not only our oldest project, but also our longest running piece of work spanning almost five years. As a small consulting company, this type of longevity is hard to come by.
In some respects, the work has been fantastic because it has allowed us to design and develop a modern, high technology solution for a client and set of beneficiaries that, generally speaking, do not often receive this type of consideration. However, as with so many things in the development and aid world, there is another side of the story as well. The work has been fraught with challenges such as long delays, massive scope creep and handover between three different project managers at our client.
I’d be lying if I told you that these challenges haven’t produced quite a bit of tension between a variety of stakeholders at various points. One reason for these challenges is simply because of the type of technological solution we’ve developed. Everyone has different expectations for how technology should look, feel and function and this project is no different. It has been difficult for us to get to a final delivery specifically because of these mixed expectations.
In order to make sure we have addressed all of our clients needs, we created a document that contained all of the feedback we’ve received and our response to that feedback. In my eyes, this document was a mechanism for ensuring we covered all details and created an agreed finish line for our project.
From my perspective, this document was a part of a conversation. A tool that we were using to facilitate a shared understanding of the work that was requested, what remained outstanding and what had already been completed. It was an informal but useful management tool.
While reviewing this document with our client recently, I noticed that they kept requesting specific changes to written comments and language – things that I considered unnecessary because this was simply a shared management tool for the project. After the fifth change request of this type, I paused the conversation and asked my client why they were so concerned with specific verbiage. The answer I received was surprising: It was their understanding and assumption that this shared document would become a part of the permanent record of the project.
This small missed understanding was incredibly important for me to grasp at that moment, and gave me insight about how we might be able to bring closure to the project even sooner. The fact was, that the document contained many notes that I had taken from meetings with our client, our project team and others. Some of these notes recorded complains, reasons why issues remained unsolved up to this point and many comments that, frankly, many people couldn’t even remember what they referred to. Yet, all of this verbiage was important to my client because this document would become a part of the project’s permanent record (and therefore, something that might be a part of an audit at a later stage).
The critical point: while I was focused only the actual technological solution we were delivering, my client was also looking at the potential political ramifications of how the project was conducted as it could have implications for them as a team and individually.
While this may seem like a small point, I truly believe this is another example of a small, completely solvable or avoidable, issue that has the potential to make a project go (or continue to be) pear shaped. When you’re working with your team or client, make sure you not only know what’s in your contract and listen to what’s being communicated, but also what’s not being communicated. That may be the difference between success and a long painful fail.
