When You & Your Client Have Failure to Communicate
What we got here is… failure to communicate.
Firing a client is an emotionally anguishing action, but one that sometimes is the best strategy in a situation where you can’t see eye-to-eye on the scope of a project and its requirements. How you get to this situation is often a confusing mess of poor contract writing on your part, poor communication of requirements on the client’s part, and a muddle of clarifications, expectations, and sometimes a total lack of understanding by the client of underlying technologies and the possibility that you acted without full understanding of their project needs; all of which leads to their disappointment and your frustration.
How the Situation Was Created
I was recently hired by a software start-up to polish the content and its look and feel for a marketing website that supported a new suite of software. The website existed and was live. It was based on an Open Source platform called Joomla! that I have extensive experience creating for and managing.
During my initial briefing, I was told that they had previously hired two designers who had tried to create a template to define the look and behavior of the website two separate times. I was also told that the designers had been fired because they were too slow and couldn’t produce a viable template. The term “template” means something very specific in Joomla! sites and I made my first mistake—I assumed that the CEO meant the same thing when he used the word “template.”
I made my first mistake—I assumed.
The CEO had now given the job of creating the site to the System Administrator/Lead Programmer who was also in charge of developing the web application they were selling and managing ongoing business. The scope of my work was to take the raw content and publish it in Joomla! as well as ensure that the site gained a professional polish. The fact that they had hired great artists who didn’t know the technology and had subsequently given the underlying coding to their traditional programmer rather than a Joomla! guru should have given me a clue that all was not as smooth sailing as the CEO made it seem. So, I made my second mistake, I accepted the challenge.
I wrote the contract using my standard language for a Joomla! site and a copywriting project. I made it very clear that I would take the template that I assumed from my briefing had been created already and polish it and its contents for navigation, flow, and marketing values. I was very clear that I had to work with the Joomla! infrastructure to ensure that contents were displayed professionally. The client accepted the contract.
The client worked in a time zone across the International Date Line and we communicated via Skype. That was no problem except as I gained access to the site and began my work, I noticed a pattern and the time zone difference made fixing this problem through continuous communication problematic. The Joomla! site was definitely not finished and was built without proper code to enable it to function as a content management system. In addition, each time I went to work, the site structurally and technologically behaved differently.
It turned out that the programmer was performing his coding work piecemeal on a development site served from elsewhere that bore little to no similarity to the live site they had me working on. (One of the great things about Joomla! is that the platform is stable and once installed isn’t edited much and one only has to “install” add-ons to get behaviors and applications needed to make the site interactive. So there was no need to have the site in pieces.)
He would tell me after I questioned the issue of missing formatting and graphics and actual code in the template directory, that he hadn’t gotten around to moving the updated code to the live site. We clearly had a disconnect between his priorities and what I was hired to accomplish (or at least my understanding of what I was supposed to be doing). In addition, he admitted to me that he had no idea how Joomla! or a content management system functioned at the level of Administration.
He was confident, he kept telling me, that he would get to the coding at a later date to “joomlify” the pieces that were missing. Because the entire project was on a very tight deadline which was important to the company, the programmer’s priorities were focused on getting the money-making product off the ground and not on completing the marketing site built to support sales and service. I couldn’t understand why the site was not whole to begin with, but I learned as I went that the programmer was using Joomla! as sort of a testbed for home-coded applications. It was a definite non-standard design.
So, the days passed and I tried to produce copy and pull my hair out that it wouldn’t display properly and I wasn’t allowed to fix the PHP code. Unbeknownst to me, the development team would meet and make decisions and they made assumptions about the display problems (becoming justifiably frustrated due to these assumptions and expectations). They began to blame me for slow work and bad results. And they were right because I couldn’t work where the systems in place were not actually connected to the output and wouldn’t be because I had no control over priorities but was supposed to do my job anyway. It was definitely a case of Catch-22.
I had no control over priorities but was supposed to do my job anyway.
I followed their protocols as they tightened their control, but I was getting no feedback on what I produced as well as a lot of flak about making changes to titles and menu names nobody had told me were frozen. In addition, because no one seemed to be reading my documentation entries in their Project Management and Change Order systems as well as their Wiki, it was difficult to convey my reasoning. I also could not get through a language barrier concerning how Joomla! worked versus assumptions by lay people on how they assumed content was created.
For the week I was on this project, I would be briefed in emails by the CEO as to what sections I should concentrate on and then get other information from the Marketing Manager as to where supporting materials should have been located, but wasn’t. I realized by the end of that week of begging for fixes and content, that the project leader was totally on a different priority page than the marketing manager, and together they were on a different page from the CEO who hired me. I began to worry that when the project did not meet its deadline that I would catch the grief. I found myself more and more up all night worrying about the quality of my work and the lack of feedback I was getting, and my stress began to affect my private life and family. This situation couldn’t continue.
The straw that broke this camel’s back came in an email where I was told that I couldn’t post work using Joomla’s editor (which is the only way you can get materials into the site) and that the software was frozen with only the programmer allowed to perform changes. But, I was still responsible for the look and polish of the content. That sounds rational in a typical software development project and absolutely good business sense, except that I couldn’t do web design with my hands tied behind my back, which is what they had done to stop changes I had made to try to remedy what I saw as the situation.
I made the difficult decision to quit before the miscommunication became hatred. I blame myself for not understanding the enormity of the gap between what I thought the job was about and what the client thought the job was about. I wrote a long explanation of my side of the story and the confusion of expectations and assumptions on both our sides. The CEO graciously accepted my resignation and apologized for this chaotic time, and asked me to consider coming back at a later date when things were more settled. That offer cemented my conviction that I had done the right thing.
What went wrong? How could I learn from my mistakes?
- Ask more questions about the project management work flow and players and how I was to interact.
- If I had changes I wanted to make, get approval before making them and don’t assume they fell within the scope of my work.
- Listen carefully to what is not said as much as what is said about the project. For example, the client’s marketing manager kept speaking of me doing the writing and fixing the CSS. The problem was that she was assuming that Joomla functions like classic web design and that each page is sculpted independently by massaging CSS and text. But Joomla is database driven and the CSS is called on but not edited to create articles that the software creates pages from on the fly. These are totally different concepts. I didn’t realize our disconnect until too late.
- Work with programmers and win their trust before making large steps. Or, be leery of working on large-scale enterprise web design projects where my freelance experience would get in the way of the more top-down methodology. Stick to collaborative endeavors where I was comfortable.
- If all else fails, then have an exit plan that doesn’t burn bridges.
- Don’t be afraid to fire yourself.