A Personal Work Log is essentially a work diary. The purpose is to record and keep track of all aspects of your work on a project.
Keeping Track of Your Work
All projects are encouraged to keep track of many aspects of the project as it proceeds through the SLDC. This includes things such as planning, schedules, budgets, team assignments, issues, decisions, testing results, etc. For a large project, this may accumulate many, many documents in all sorts for forms.
On a personal level, it is wise for each team member to keep their own personal work log. The idea is the same: keep a history of assignments, plans, issues, questions, research, decisions, etc. Why is this important?
There are three basic ways in which a personal work log is valuable:
- It records information, such as requirements and assignments, when they are made
- It records research, ideas, decisions and opinions of the developer, as they are made and affect the work
- It provides a secondary history source - for the developer - of how the project progressed
- It provides "protection" for the developer for future faulty memories
Let's consider why these are important.
Projects are sometimes long and complicated. Sometimes they start, then pause, then get redesigned, then restart. It is not always a smooth flow. Team members change. Management changes. The client changes directions. How all of this happens may or may not be documented in the main project files. Some people may remember how it happended, or there may not be anyone that remembers it clearly. After 9 months, the client may be mad when a project is delivered without a certain Feature X. But a keen developer will keep track of what was assigned to them and what decisions were made. And if the keen developer can look back through their personal log and see that they were assigned to complete Feature Y, and that Feature X was cancelled - by the client - they can correct the impression that something was missed or done incorrectly.
A second category of valuable information is about research and decisions. It is very common that a development team does not know exactly how to implement a feature, what the options might be, or what the best practices are. It can be very helpful to be able to look back and say "Yes, we researched that option and it was not practical because...", and "the decision was made to instead do ...". Unfortunately, this is not something that is always recorded in project documentation. But a keen developer will always document critical decisions that affect their work, why they were made, and what options were also ignored or overruled. In this scenario, it is very possible that the project manager might task with someone with researching the issue again, and time would be wasted finding out what was already known - that the option was not practical.