Work plan guidelines

Work plans

A work plan (WP) has many benefits:

  1. Allows your team to collaborate efficiently.
  2. Allows your team to focus on HILE requirements.
  3. Seniors get a quick overview of progress. Boosts service quality.
  4. Allows seniors to assign developers in an efficient way.

These are our internal guidelines on work plans. They’re part of our principles and method of being radically transparent.

Work plans are typically used only for software development projects. Read the time overview (TO) guidelines before reading the rest here.

Here’s an example work plan (you need to be logged in with your @lbit.in Google account). A work plan needs to be set up for all projects except non-sprint-based projects (NSBPs) such as very agile projects and maintenance projects.

Transfer the ownership of all work orders and other Google documents that you share with the clients/other employees to the project director from the start.

The invoice time overview (ITO) can sometimes show a quite big requirement size dispersion as invoices may be sent frequently due to credit limits. Aim for minimal dispersion in full work order TOs and long-term TOs.

For NSBPs where the client is active you can send an inline mini work plan instead of a full WP:

I will work on this next and in the following order. I will complete it tomorrow morning. (Hourly estimate within parenthesis): -Advanced search: add fields CTC, experience and location (3) -Import: Tweak to include CTC field and re-import all files (3) -Advanced search: add fields key skills, headline (2)

Requirements should be prioritized so that you focus on core features: HILE requirements.

Name work plan “Project – sprint X – work plan” so that we easily can access it by just typing the name into the browser address field or using macOS Spotlight.

Projected result can be calculated as Estimated minus spent minus remaining. Remaining hours can be updated frequently so your team will quickly realize if you are risking going beyond budget and take appropriate measures.

Place a hyperlink to the time spent report (including GET variables) so we quickly can access it from the work plan.

Color code features to get a fast overview. For example: Completed features could be marked light green. Tested and approved features could be marked with dark green. Tested and disapproved features could be marked red.Use filters so we can easily sort by developer, status etc.

Add some extra days to the work plan, so we have some buffer time in case a developer would fall sick or there are some other unforeseen circumstances that may cause delay. This is especially important if the client is very strict and inflexible on the deadline.

Like time overviews and time entries, work plans can be of legal importance in case a client fails to pay and we need to take legal action. Your work plan should be reflected in your project’s time sheet overview.