General discussion


Putting it in Writing: Can It Break a Career Without It?

By comp1systems ·
Ok...if I haven't learned anything else over the years, it's
"put it in writing." This stems from projects I've been
involved in when information was exchanged verbally, and
later the clients come back and says, "you never said that,"
or, "we never discussed those arrangements," or, "that's not
the quote you gave me." It's an awful position to be in
because, for one, there's no documentation to back it up.
This applies to working on someone's computer as well.
Without the disclosure of set policies that make it clear how
things works, the client thinks one way while I think
another. And it all goes back to the cliche' that the
"customer is always right" even if arrangements were made
verbally. If it's not written down, what else can you do?

In an opinion, I think without having policies well
documented and available to the client, and conversations
noted, it could cause more harm than good and as a tech
repair person, end up losing money than earned.

It's terribly important to "put it writing" because it not only
identifies the policies of operation, but with well kept
notes, it confirms any agreements and arrangements that
were made at the time of the service call.

I truly believe that to protect the business and avoid costly
lawsuits, and other ugly situations everything, and I do
mean everything, should be in writing all the way down to
the last period at the end of a sentence. It's simply good
bookkeeping, business and common sense.

I don't want to sound off my rocker here, it's just a matter
of keeping from getting burned and the client from feeling
burned. Any other thoughts on this?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

It's tricky

by DC_GUY In reply to Putting it in Writing: Ca ...

You have to be careful not to overdo it. Many people don't believe that written records are important. These are usually people who are poor writers and/or poor readers, and a lot of them manage to do well in the business world. Even though they're probably wrong, when someone they do business with asks them to sign a lengthy contract or takes copious notes at a meeting, they think he's trying to take advantage of them.

Remember that no matter how carefully you prepare, you cannot avoid every potential problem, because many of them result from conditions that could not be foreseen.

So don't make a bad impression by being too formal.

Collapse -

for full records

by Jaqui In reply to It's tricky

of discussions, to be used to create the written guideleines for a project.
use a video camera. ( digital or not. )
give the client a copy of the recording, so that they can verify any details they have questions over with thier own copy.

end of tape is one person summarising the points for the agreement.

even if an individual has problems with the reading, the video record shows you are not out to get them,[ they can see and listen to it ] you don't have to write copious amounts in the meeting, and have a complete record of what the client wants, and what your understanding of thier wants is.

tell them, standard practice, for ensuring that the team has thier words exactly for working on the project.
( which isn't even a lie, as the team will more than likely review the video to clarify for themselves point of contention in the development cycle )

Collapse -

I've been thinking about this myself lately

by stress junkie In reply to Putting it in Writing: Ca ...

I'm at a point where I want to create a certain level of documentation to provide to my clients for the reasons stated in this post as well as other reasons. Some documentation stating your standards and practices seems appropriate. It seems, though, that putting everything that you can think of in writing is going to confuse and scare your clients. You would end up creating lists of potential problems resembling the labels on over the counter drugs, which nobody reads and which few people would be able to evaluate if they did read them.

One event in my history that comes to mind happened quite a while back. I was going to upgrade a VMS system overnight. Just before the department manager left for the day she asked me what was the worst thing that could happen if things went badly. I told her that in the worst case the computer might never work again. That wasn't exactly true, but she wasn't the least bit technical and I couldn't explain that my "belt and suspenders" approach to system administration couldn't cover all of the potential problems that could arise. Now that I'm older I wouldn't make such a glib remark but it still illustrates that I believe nontechnical people often cannot evaluate the risks of common procedures and probably don't need to know every possible risk in everything that we do.

I am beginning to return to an opinion that I've held throughout my career. That opinion is that if we tell our clients that we use standards and practices that are common in the computer support industry to minimise risks then they will probably be content. Naturally we have to do what we say we will do and follow such procedures as they apply to whatever we are doing. In that case I think that the risk of litigation from a dissatisfied customer is minimal and the risk of that litigation being decided against us is even more remote.

Speaking of litigation, I wonder how many cases are actually brought against computer support people. We talk about it a lot but I am not familiar with any real cases. I was once asked by a consulting house if anyone had ever brought legal processes to bear against me from anything that had happened in work. I laughed. Later I thought that maybe she or her husband had faced legal problems from supporting some unhappy client. I don't know. But I have never heard of any actual cases against computer support firms, consultants, or whomever.

I wouldn't lose any sleep over it.

Collapse -

VERY Good Point...

by comp1systems In reply to I've been thinking about ...

I like what you've said, and it makes very good sense. Here
I am wrecking my brain over it and thinking, "perhaps, this
and this and this should be in writing," whereas I'm putting
way too much thought into it. The opinion you mentioned
about using standards and practices, can I use that? I'd like
to reflect back on that from time to time. I'm very early in
my career in this whole scenario, so I'm still learning as I go
along, and what I learn, I use that to know not to make that
same mistake again.

Collapse -

Best Writing is Using Good English

by checker_chgo In reply to VERY Good Point...

Putting requirements and even small changes in writing helps the PM and the sponsor understand the initial scope and changes to it. For example, if the sponsor insists on 17 small changes over the course of a multi-month project and each change takes one day, you'll find that you are one month behind in the schedule.

It might also help if you use the right words when communicating, such as "racking" your brain rather than wrecking it. At least I hope your situation isn't so desperate that your brain is actually being wrecked.
Further, when you say "verbally", please understand that "verbal" means "to use words". It does not distinguish between spoken or written words. If you intended to say that the requirement was given to you via oral (or spoken) communication, please say so.

My strong recommendation is to document every request and review the list as frequently as is logical in your situation with the requestor(s).

Good luck.

Collapse -

Good idea all around

by gralfus In reply to Putting it in Writing: Ca ...

We built a house and the contractor didn't want to list his costs and such, and that if we insisted, we could find another builder. His work was so nice that we went ahead with it. The work was good, but not great. Water system was contaminated. No sump pump, so that had to be retrofitted. Bathroom wasn't to code, so when we sold it we had to compensate the buyer.

I learned from that to always get it in writing ahead of time.

Collapse -

Project yes, everything no

by JamesRL In reply to Putting it in Writing: Ca ...

I will tell you that I think its in everyone's interest to document a project well. Documenting an assumption or a risk forces you to think about about it more, and getting a clearly documented plan that everyone agrees to helps avoid many misunderstandings.

I have experienced staff who save things like instant messages, save emails forever etc. I dislike the CYA thing. They often use it as a bludgen on their co-workers when we all know that things change, and our perspective changes as time goes by and we get more information. I suppose its not the saving itself, but the way the information is used that can be irritating.


Collapse -

This is a lesson you can only learn the hard way.

by pepeledog In reply to Putting it in Writing: Ca ...

Once burned, consider it learned.

Collapse -

Communicating with clients

by Info-Safety, LLC In reply to Putting it in Writing: Ca ...

When working as a consultant with clients, you absolutely need to be clear up front about what you can and can't do, and what it will cost, either by the hour or by the job. For jobs large enough to require a contract, you should have a lawyer review for you, lest you end up paying to work.

As an employee, on the other hand, you should only document the really big projects. Those who find the need to constantly engage in CYA should look for alternative employment.

Good luck.

Craig Herberg

Collapse -

The only way to do business

by Dalmatian In reply to Putting it in Writing: Ca ...

I've read a number of the other posts but I have to say from experience that it is the only way to do business. It's a pain in the posterior, especially when you are just begining the practice, you have to get your clients used to it and you have to come up with the documents.

As a number of the other posts mentioned, it clarifies the relationship and what is expected. Even ignoring the potential for litigation, it avoids hard feelings down the road.

I once worked as a developer for a company where I spent as much time writing requirements, then specs then test plans as I did writing and debugging code. I thought it was excessive and a waste of time at first, then as I became a more senior analyst and dealt directly with the clients, I realized how valuable it was to have it all in writing. It really did save some relationships (not to mention my posterior) more than a few times.

I think the most difficult thing is how it is presented. I've encountered situations where the document is exceedingly restrictive and used as club on the other party. You really need to include some diplomacy to make it work as well as a handshake used to.

Related Discussions

Related Forums