I wrote my first blog entry for the Crimson company blog this week, you can go here to read it
I will be interested to see the content from other work colleagues
Paternity leave promotes good practice
One person at work is on the verge of paternity leave; the baby is now eight days overdue and doesn’t seem to be in any rush to enter the world, obviously this isn’t the good practices I refer to in the title.
Whilst Almost Dad is getting things prepared he emailed a few people asking us to configure outlook so a number of people can monitor the Support Desk emails/issues whilst he is away. This highlighted to me a good practice Companies should get into; don’t rely on just one person.
I always view it as a danger when there is only one person working on a project and because that person is the only person working on it, he doesn’t bother to document things because he knows it all off by heart. This system works fine until that person is off ill, goes on holiday and then someone else has to step into the breach and work out how to do anything.
I never like to store information in people; I also like to have it written down on the intranet. Crimson creates an intranet site/area for each customer project we have and then we store useful information here. This is vital when you have different people working on smaller parts of a project and need to learn about the project, the customer contacts, the server locations etc.
It’s also important you encourage everyone to keep this information up to date because keeping good up to date records is a habit and if people start to get out of it you only usually notice it when it is a problem and you can’t figure out how to do something or where a vital part of a project is kept.
I have thanked myself on a number of occasions when I have found I have documented a procedure which I had forgotten how to do. Documentation is particularly important in support projects which might not have any activity for a while and then suddenly someone will have to investigate a problem. I view project documentation as a knowledge/brain dump for myself and other people who will be working on the project in the future.
It can also save different people solving the same problem/issue, once someone has a solution then other people can follow the documentation solution which can save hours and sometimes days of diagnosis.
In the example I used at the start of this blog post, we already had a few people monitoring the support Desk inbox (me being one of them) but the email acted as a good reminder for people and sent out instructions for more people to keep an eye on the Support Desk inbox. It got me thinking information and projects shouldn’t just be reliant on knowledge which is held only in one persons head, get them to document it.