Managing Personal Activities

Recently, I was asked about amount of activities that someone should be involved in:

- I have quite a few manifold activities, and I'm curious if being involved in such variety of things makes sense at all? Is it possible to estimate percentage of effort, that really produced expected return? Do I complete all the tasks, that are important, on time and in proper quality?

There are some good personal time management theories, that describe how to deal with such "increasing" number of responsibilities. However, there is also some other opinion that doubts if you need to do anything about it at all ☺

So we have:

1. The things (activities), that have to be done
2. The person (let's call him/her a manager), who is assigned to these tasks
3. The team (for the purpose of this article, the team size can be of any size including zero)
   
4. Limited time frame
5. Personal manager's preferences to one or other activities
6. Manager's perfectionism

The amount of work, that manager performs himself, is being controlled... automatically. With time, the manager delegates some of his responsibilities to team members keeping the activities that are:

• most interesting for the manager himself/herself;
• are so "important", that the manager can't afford giving anyone else;
• are so "complex", that can't be done by team members with satisfactory quality.

Actions

Until the manager doesn't feel personal overload and the results are positive, it means that automatic control system works. No correcting actions are required.

If the manager feels overworked, it most probably means that either the team size is too small, or that he/she has too high level of perfectionism. In this case, correcting actions can deal with team size, amount of activities, and the actual person's role.

If the work results are not satisfactory, it can be caused by one of the following: lack of skills/experience, lack of motivation, or recent enormous overwork. In most such cases, I would recommend to reform the team relocating the manager to another task.

Starting a Project

Most projects are quite similar in some way:

• You have to create code;
• You have to create some documentation;
• You need to provide introductory materials for new members when they join the team;
• You need to integrate parts of code created by different developers;
• You need to make sure that recent changes do not break old functionality;
• You need to track the progress;
• etc.

This list can be extended or even detailed if we specify some restrictions, like the projects are in Java, or the projects are Windows applications, and so on. But, for now, let's treat it just as a simple argument in support of the fact, that even if two projects look quite different, they probably have a lot of common needs, which can be combined and described by a pattern.

Of course, it's not surprising, and there are already a lot of methodologies (or processes) describing the rules that have to be followed to cover some or other project needs. And I'm not going to invent just another one technique. All I'm going to propose are some steps, that can be done in the beginning of a project. These steps do not contradict popular existing methodologies, but help people to follow their best practices by focusing on them from the beginning.

So the steps are:

1. Organize online collaborative environment for the project team (hereinafter, I'll be calling this environment wiki, however it's not the only possible solution). Having a place where every team member can write her/his comments about the project doesn't mean that all of them will provide valuable feedback by default, but if there is no such environment you can be absolutely sure that you'll miss documenting a lot of important information.
   Note: even, if you it's planned that only one person will work on the project, and this person is you, it's still worth thing to do. First of all, it will be a good place for yourself to store project references and materials. And the second, because the plans has a tendency to change :)
2. Create a section in wiki, that have references to all other external project resources (version control system, file storage, dedicated project server etc.). From the beginning, this area can be about empty or even empty, but it has to be updated when new resources become added.
3. Create a version control environment for the project. I believe it's not arguable ;)
4. You'll need to define the workflow and track the progress, so create some To-Do in any format, that you are comfortable with and that conforms to your company practices. It can be MS Project Plan, SCRUM Product Backlog, one column with the tasks in a spreadsheet, anything... Nothing to write to the plan yet? No problem. Add just one item: "Do Work Breakdown and update the plan". Then start following your plan creating and updating new items when you got or explored new information.
   Note: it's a good idea to have some high level plan before step 1, because it's the good source for high-level project estimate.
5. Organize bug/issue tracking environment.
6. Need to create Software Requirements Specification? Do it... The only advice is to keep it together with all referred artifacts in wiki, instead of creating static Word document (if it's not contradict with existing company standards or with agreement with the customer)
7. Ready to start development? Cool! Start it from creating readme.txt and whatsnew.txt files. If you plan to deploy the results to someone else one day, you'll need some supplementary project files anyway.
   Disclaimer: if you are sure you do not need them, then you do not need them... Never do unnecessary work.
   Note: There is a good principle in XP: You Ain't Gonna Need It (YAGNI), which says "never do the work, that is not required yet". So I've ignored it here... I've ignored it here, because actually these files are required already. See the next items.
8. Create some fake project, add it to version control system, and build it (it can be simple "Hallo World" application).
9. Update wiki, adding information about project/solution files location and any pre-configuration steps that are required to build the solution locally.
10. Create the 1st deployment package. It's about empty... Anyway, create it.
11. Create the one-click-script that knows how to compile complete deployment package.
12. If you need to deploy your package to some place for testing purposes, create additional script that deploys the package to test environment automatically.
13. Describe this simple build and deploy procedures in wiki.
14. OK. So we have the 1st version of our application... 1st version?.. OOPS, we've just forgotten about a way, how this version can be identified on the test and production environment. Add the version info somewhere to the project in a way, it can be easily transferred to the target application. Make sure, that testers and users do always have a chance to find exact project build number that they are using.
15. Find a way to keep version information consistent among all related files (e.g. project file, readme.txt, installation script file, etc.).
16. If you are developing something, that should be installed by users themselves, it's a good idea to create simple installation scrip on this step, and include it to the build process. I mean to create it on this step :)
17. Integrate unit testing environment into the project before creating actual source code
18. Disclaimer: Actually, this step can be somewhere above.
    If it's a time to extend the team, you've got the 2nd team member, and have to make project introduction, then it's a time to create new wiki page: "Introduction into the Project". This page will be the start point for all new team members in the future. The content have to list all step-by-step instructions including but not limited to: project vision, link to a page with references to other external resources (version tracking; bug tracking; etc.), links to the materials that newcomer have to read. In other words, it should list all items that must be completed by new team member before he/she receives the 1st personal task.
    Important: Make sure, that each new person knows that she/he is allowed and encourage to add or modify the information in your team wiki, to create new issue records (bugs or ideas) in the tracking system, and to communicate with the rest team members.
19. Before the 2nd developer starts writing source code, establish continuous integration environment.

Of course, completing this steps still doesn't guaranty project success. However, it gives a good basement for the future results, and will help if the team continues using the system.


P.S. By the way, it's possible to create so called "project templates" and use them when new project is being started instead of repeating counterparts of the steps described above.