As a consultant I've learned the hard way to document everything. Decisions taken together with the customer, what I have done. Keeping a work journal has become second nature and has saved me numerous times. When I'm lazy and sloppy with the notes I usually regret it.
Often, the work journal becomes the tool I use to do work itself. If I'm going to investigate some technical issue and send an email afterwards I'll do the investigation documentation in the journal, and can then just copy-paste the result into the email. Just adding a note in the journal that the when email was sent and to whom.
The tipping point was when I worked as an ASIC designer in Copenhagen, Denmark. We had meetings when a decision was made regarding functionality to be implemented. Only having the customer come back two weeks later and change the requirement. The customer then blamed on language issues for me not understanding the requirement in the first place and therefore the new functionality was what was stated from the beginning. As a consequence I as a consultant therefore would carry the cost of two weeks worth of work without pay. The first time this happened I was unable to prove that the customer in fact had changed the requirement. So I Started keeping a very detailed journal.
The next time I could ask if it fact wasn't the case that Mr XYZ in a meeting 20yy-mm-dd had decideed that we should do ABC, but now wants instead wants to do CDE. If so, that is not a misunderstanding but a changed requirement. After two such incidents the customer stopped with those tricks. And I've kept keeping journals ever since.
1 comment
[ 4.3 ms ] story [ 7.0 ms ] threadOften, the work journal becomes the tool I use to do work itself. If I'm going to investigate some technical issue and send an email afterwards I'll do the investigation documentation in the journal, and can then just copy-paste the result into the email. Just adding a note in the journal that the when email was sent and to whom.
The tipping point was when I worked as an ASIC designer in Copenhagen, Denmark. We had meetings when a decision was made regarding functionality to be implemented. Only having the customer come back two weeks later and change the requirement. The customer then blamed on language issues for me not understanding the requirement in the first place and therefore the new functionality was what was stated from the beginning. As a consequence I as a consultant therefore would carry the cost of two weeks worth of work without pay. The first time this happened I was unable to prove that the customer in fact had changed the requirement. So I Started keeping a very detailed journal.
The next time I could ask if it fact wasn't the case that Mr XYZ in a meeting 20yy-mm-dd had decideed that we should do ABC, but now wants instead wants to do CDE. If so, that is not a misunderstanding but a changed requirement. After two such incidents the customer stopped with those tricks. And I've kept keeping journals ever since.