Work for Free?
The consulting work we did for Brasil Telecom involved several projects, spread across different contracts, and became the main focus of the company in Brasília. After the risk analysis project, we were called in to help with another job. Brasil Telecom had decided to increase the security of its email using PGP Universal Server, a commercial version of PGP that included a number of features useful in the context of a large organization.
We had the traditional project kickoff meeting, in which the client’s representatives gave us information about the scope. They handed us a list of the licenses they had purchased and defined the expected deliverables. In a big company like Brasil Telecom, access to production systems was very restricted. The security team couldn’t install anything directly in that environment; it was necessary to produce an installation manual, which would be handed over to the production team for execution. In the case of the PGP project, the main objective was precisely to produce such a manual.
I was assigned to be the consultant responsible for the project. I grabbed the list of software that had been purchased, spun up a series of virtual machines, and started installing the products, generating screenshots to be included in the manual. During this work, I read the software documentation pretty carefully and began to suspect that the licenses they had acquired didn’t match the scope of use defined by Brasil Telecom. I talked to my boss and, since our company was also a PGP reseller, we managed to get in touch with the manufacturer to validate the list of licenses we had been given. Meanwhile, I finished the manual based on the information available to us.
When the manual was almost ready, with only a few final revisions to go, we got confirmation of the actual list of licenses acquired by Brasil Telecom, and it was completely different from the initial list. I then went to the person in charge of the project on the client side. I showed him the new list, presented the draft of the manual, and explained that we had validated that the licenses actually purchased did not match the information he had given us at the start. That compromised the validity of the manual produced, since the screens and features of the licensed product were different from the ones we had documented. A significant part of the material would need to be redone.
His reaction was immediate and tense. He said we’d have to redo it all and that we needed to deliver a manual fully suited to Brasil Telecom’s needs. The conversation escalated quickly and, faced with his insistence that we should fix a problem created by incorrect information provided by the client’s own team, I ended up reacting with something along the lines of: “but you want me to work for free?”
Obviously, my response didn’t go over well. Combined with the fact that he didn’t want to admit his initial mistake, the situation ended up turning into friction between us. The next day, my boss called me and said we’d have an emergency meeting at Brasil Telecom to try to resolve the “mess I had created.”
The meeting started in a pretty tense atmosphere. The manager for the client’s department laid out what he described as proposals from companies willing to work for free for Brasil Telecom. I thought the whole thing was odd, but my boss steered the conversation in another direction. He explained the situation objectively: the client’s team gave us a list of licenses, we did the work based on that list and, going beyond the contracted scope, we identified that the list was incorrect. Correcting the manual we had already produced would require a few additional days of work. When the manager realized the situation was actually an attempt by his employee to hide his own mistake, the tone of the meeting changed. We reached an agreement to extend the project, contracting us for a few extra days of consulting to produce a manual appropriate to the company’s actual needs. Later, some of my Brasil Telecom colleagues told me that wasn’t the first time that same employee had tried to conceal a mistake, and that the manager had been pretty annoyed with him.
Another interesting project we carried out for Brasil Telecom was the creation of information security handbooks. They were short manuals with practical guidelines for carrying out activities more securely. Some dealt with hardening of systems, like Windows or Linux; others were aimed at developers, with recommendations for building more secure systems. One of the handbooks I wrote covered security in software development with Java, a subject I was already familiar with and about which I had published a paper with Gisele during my PhD. Some time later, I revisited that material and published a new version that was available online or as a e-book. Today, the content is certainly outdated in some respects, but many of the principles should still be valid.
Despite the difficulties and the typical tensions in the relationship between consultancies and clients, it was a period marked by interesting projects and a lot of learning. The consultants I worked with were pretty smart, though very young — the company avoided hiring more experienced professionals, on the grounds that they didn’t want “gray-haired folks.”
Advice nobody asked for but I’m writing down anyway:
- Trying to hide mistakes is a mistake. ;) To err is human and we all make mistakes. My experience has shown me that admitting mistakes and showing a willingness to fix what went wrong works much better. I’ll talk more about this in other chapters.