Paradigm 1: Apply the same area type to many rooms
The idea of using an area type and a set of tasks to represent many rooms is not new and it does have its advantages when used as a general guideline. It's a quick and dirty way to put one in the ball park, and as long as the times are padded generously, the cleaning staff has no reason to complain. Likewise, for purposes of budgeting, the manager has a nice, fat padded budget to present to the bean counters backed by the prestigious APPA organization.
It worked well until wide-spread outsourcing started to occur since BSCs could complete with a decent margin and still beat the calculated costs of in-house staff, not to mention their lower comparative costs due to less generous salary and benefits packages.
The problem from a development point of view was that with this paradigm if there were rooms of the same type cleaned on different shifts or days, or if some were cleaned slightly differently (think V.I.P. Offices versus regular Offices), then a new area type would have to created, with modified tasks, and then these new types applied to the rooms. This created a bookkeeping nightmare within the software and within users’ minds. And, when healthcare was considered where operations run 24/7, well the paradigm was stretched to the breaking point.
Another issue was that with a single set of tasks to represent a group of rooms, there was no way to adjust the actual fixture counts of individual rooms. We had to work on average fixture density. And that's fine if you get the average density correct, fine for estimating overall labor requirements. But what if you're a cleaner and the floor on your assignment is loaded with higher-than-average fixture counts, such as can be the case with desks in classrooms or fixtures in washrooms? You're screwed, and your colleague cleaning other rooms of nominally the same area types has an easy assignment.
But not at the expense of more complexity
What? I hear you say. You just went to great length describing how you cut out features to simplify the software, and now you're immediately talking about adding new functionality.
The answer is that, after 25 years of coding software, I'm finally at that point where I can have my cake and eat it too. You see, if you're really good, you can build in automation that allows the software to do things without user intervention, so there are no more apparent 'features' users have to deal with.
But the real answer traces back to a whole paradigm shift with the software and to describe that we have to go back in time to about 1992, when my late father-in-law, Jack Dudley, was heading up a committee at APPA to publish the first edition of their Custodial Staffing Guidelines (which is still on sale, now in its 3rd edition). It was a mathematical approach to workloading intended to be a guideline, or method of approximating cleaning times.
The task times used were simply an average of 10-20 participants' guesses, and based on room models, such as 1200 square foot classroom with hard floor. It was deduced by industry insiders that the task times developed this way were somewhat self-serving (overly generous). But since it was just a guideline, we threw out the high and low guesses and averaged the remaining guesses.
Now Jack was a trained and respected mechanical engineer, like myself, working in product design. Jack knew the difference between a 'standard' and a guess. Once I used the term 'APPA Standard' and he corrected me immediately. These were
not standards since they were not based on time studies or
any science at all. Over the ensuing decades, people started referring to them as standards, and I'm sure poor Jack rolls in his grave. But, search on the phrase
APPA Standards and you'll see what I mean. To address this issue, we have libraries of task times and all are fully customizable.
For simplification, as we only had spreadsheets then, we used a paradigm that was eventually incorporated in our software.
This paradigm and the one developed it to replace it are described on the right.
The solution had to transparent to the user not only for at initial setup time, but for all software tasks normally done by the user in daily operations. As it turned out the solution made easy work of priority 4 (task frequency bookkeeping), since, for once, we were able to knock out two birds with one stone by combining concepts and developing some very efficient algorithms. The solution is described below.
Paradigm 2: Create an area type and set of tasks for each room
The alternative is to create a set of tasks for each room. This way, each room can be customized for any modifications needed to the tasks without affecting any other rooms. This includes the issue of fixture counts as well as differing tasks and frequencies.
The only potential drawbacks are:
- Implementation method, obviously users can't be bothered to individually set thousands of rooms with area types. Solution: It must be automatic.
- Computation speed and efficiency: Speed can be negatively impacted since the software has to consider many more tasks. Solution: Optimize queries and develop methods to more efficiently perform calculations.
Solution: A Template-based Approach
For once, maybe the only time in my development career, one basic change solved two big problems
No, you really didn't want to see an image of two deads birds. I thought this might make you smile.
They're cuddling!
The Conversion: Normal to Advanced Mode
How it works in Operation
First of all, with many users happily using the current system, I had to find a way to optionally convert a user's database to the new paradigm. That way, users could operate in the old way, which I now call 'Normal Mode', or they could switch to the new paradigm which I call 'Advanced Mode'. The conversion (back and forth) is done via a toggle on the control panel.
Conversion to advanced mode can take the system up to 20 minutes or so depending on the number of rooms. In the process, the following things happen:
- The original area types are marked as templates.
- A new area type is created for each room based on its template
- Existing frequencies in the new area types are all initially set to never. I'll explain why later.
- Tasks that are item-based, such as sinks, are converted from their formerly 'average density' basis to a quantity scaled to the room size.
As it turned out, the way to add capabilities also enabled a way to finally solve the task frequency bookkeeping problem. With a set of tasks for each room, the real trick was in the method of setting those frequencies because, obviously, nobody has the time to do that.
The new "templates" now serve two functions, primarily.
First, when a room's area type is changed, a new area type and set of tasks is created based on the selected template.
Second, each template has only three frequency columns, primary, secondary, and project. These setting are applied as options when the room is moved into work assignments.
View and changing area types:
Throughout the software, area types are shown in lists. With thousands of area types possible using the advanced paradigm, the only practical way to handle this is to show the room's template 'type' rather than the actual type. Thus, the list choices come from a much smaller set. For example, one can change a room's area type directly from the list of rooms shown for a building and floor on the Room Dashboard page. When a user changes the area type here, behind the scenes a new area type and task set is created and the old one discarded. If the room is workloaded (placed in assignments), the task frequencies are automatically adjusted for the new template's primary and secondary settings. See below for more detail on that.
Setting Task Frequencies:
Formerly, the old paradigm, one sets the frequencies on any or all of seven shifts and the act of putting the rooms into work assignments did nothing other than tag the room with the assignment.
With the new paradigmthe frequencies are set automatically when one moves the room into an assignment. This automatic function takes into account the days-per-week setting of the shift (e.g. 5-day shift or 2-day weekend shift) as well as a user controlled toggle that designates primary or secondary and add or move for both (4 choices)
Believe it or not, from a user perspective, that's basically it, everything else is gravy and easy to digest.
Setting Fixture Counts:
The initial scaling of fixture counts done by the conversion process is pretty precise. But, optionally, at least some rooms can benefit by setting exact quantities. Assuming this is a requirement and data is available, we can make it easy via automatic import/export through our unique spreadsheet system.
