Project and daily business: These two different capacity models occur together in almost all companies. The text describes the differences and how both models are mapped in Can Do.
What is the difference between project business and day-to-day business?
Day-to-day business and project business are two different types of business activities.
- Day-to-day business refers to the normal, recurring business operations of a company, where regular tasks are performed and routine activities are completed. These activities are usually standardized and can be automated.
- Project business, on the other hand, refers to the execution of a unique, time-limited project that usually has a specific purpose. Projects have a defined beginning and end, and the tasks performed within the project are specific and unique.
It is important to note that many companies conduct both day-to-day business and project business, as both types of business activities are important to achieve the overall goal of the company.
The third component is the so-called absence planning. This describes all times when the staff is not available at all, i.e. vacation or illness.
Day-to-day business explained in more detail
The people who are involved in day-to-day business can be divided into two groups:
- Persons who mainly or exclusively carry out day-to-day business, for example clerks. These persons have only a small remaining part of their availability for project business.
- People who only have a small part of their time for day-to-day business. GThese people mainly work in the project business, in work packages or agile stories. Here, the day-to-day business is rather a kind of background noise and is often also referred to as basic load. This forms a percentage share of working time that simply "disappears" due to conversations in the hallway, travel expenses, e-mails, etc.
How is day-to-day business planned and tracked?
The share of the daily business or the basic load in the working time of an employee is often expressed in a percentage, here are some examples:
- At Can Do, a developer has a 5% share of so-called "Development Management Activities", i.e. Daily Scrum, time tracking, etc.
- Support has 15% load for "sales support", i.e. processing technical inquiries from the sales department or fulfilling other supporting tasks.
- Management has 25% of its time for "management", i.e. the typical decisions that have to be made and processes that have to be observed. This includes, for example, the economic development of the company, the development of the key figures, etc.
- A purely administrative employee virtually "only" does day-to-day business.
The problem of day-to-day management with this information is that the amount is not the same per day. So it's not that a manager spends exactly 2 hours on "management activities" every day. Rather, this is a percentage figure that relates to a time period - usually a month. I.e. seen on the month, it is just 25% of all working hours which the manager uses for "management activities". This can be 4 hours one day and nothing at all another day.
The persons are required to book corresponding times on these activities in the time recording. From this, the following insights can be gained or questions can be answered:
- Is the planning figure still realistic for the next few months? Or has the amount changed in the past in such a way that an adjustment into the future is also useful in order to maintain the reality of the planning?
- Does the effort change surprisingly high? For example, the "base load" for employees rises sharply when they have to deal with increased bureaucracy and thus lose working time that would be better invested elsewhere. For example, in the project business.
How does this translate into scheduling software?
In the past, adventuros calculations were made to account for this overhead.
A first step was the calculation with so-called full time equivalents (FTE). This actually means that 2 half-time employees work as much as one full-time employee, i.e. the two half-time employees together have an FTE of 1. Now the percentage of the basic workload has been calculated. I.e. someone who has no base load has an FTE of 1, someone who has a 25% base load has an FTE of 0.75.
This completely ignores the fact that these base loads are not evenly distributed.
Also the consideration of the whole month is not meaningful in the project business, since the work packages are often clearly shorter than one month, the load by daily business however fluctuates. So it may be that during the work package there is no day-to-day business or a lot of it.
If I schedule an employee for a workshop for 3 days, he will not do any day-to-day business during this time.
Can Do solves this issue with a very special algorithm called "Watermodel". This very elaborate procedure simulates the work distribution of people in the boundaries of their work packages independently of a period. The exact procedure will be explained in another paper.
Through this procedure, the monthly load can be easily entered as a number. "Watermodel" ensures that the surrounding project planning perfectly takes into account these basic loads.
In Can Do, the table planner is used for this purpose:
A "project is created and the types of daily business are defined. Then the people are booked on this activity and a monthly percentage (or hours/days) is specified.
Hints and tips
- Specialists usually work on projects for a limited period of time. For this reason, 'day-to-day business' can always be specified as 100% per month for these people. In times when these people also support a project, the number is reduced. In other words, if the daily business is only 80% in a month, the person is only available for 20% of the projects. The Can Do algorithms simulate and calculate all the loads themselves.
- Not too many basic load elements should be stored per person for a period of time. There may be additional work packages from projects for the person. If there are too many work packages running in parallel, it is easy to lose track. Between 3 and 5 basic workload elements have proved useful.
- The person should record actual times. In this way, the person can arrive at the total working time in the software (e.g. 40 hours).