1. Software home page menu
  2. Nine Commands on menu
  3. Simplified considerably
  4. Managing Director
  5. Managing Director
  6. Managing Director
  7. Managing Director
  8. Managing Director
  9. Managing Director
  10. Managing Director

Developing for 2020

Priority 1: Simplify, simplify...

Written By Claude Berman January 2019
Customers wanted this:
For the new year, and onwards into the next decade, I undertook a massive development project involving just about every aspect of the software. Experience working with customers and the industry convinced me to the following design goals

  1. Simplify the user interface, and this led to the next conclusion.

  2. Provide a turn-key solution for the customer rather than a software product.

  3. Enhance capabilities to allow for optional fixture count precision on a per-room basis.

  4. Solve the task-frequency 'bookkeeping' problem; by which I mean that the software must quickly reschedule tasks based on the shift, and type of cleaning (light or heavy).

We'll look at these priorities one-by-one in detail. But just note that once I fully grasped the issues and how they tied together, well I experienced a period of profound "why didn't I think of this before?" 

In fact, priorities 3 and 4 were intertwined in such a way that both could be addressed in one fell swoop. After banging my head thinking about the last 25 years of work and how much of it had to be thrown out the window, I got to work.
But we gave them this:
In retrospect, it was obvious what happened. I'm an engineer and I like power in software. Lots of power to make setup faster and provide options for users. My distributors liked the power, because they make money on setting up the software and it made their jobs easier.

And, over the years, customers requested new features. Worse, some of them made it condition of sale. And, on occasion, I'd look at a competitor's product and notice something I liked and figured that if they had it, their customers may want and use it too.

And finally, sometimes I realized that given the expanded capabilities, I could easily hand on some other feature. And so it went, endlessly adding functionality, and cluttering up the menus so that it took a while for users to find the functions they actually needed. In day-to-day operations, even the most detailed-oriented clients only used, perhaps five of the hundred pages.

So, the first thing to do was to isolate the features customers really needed from all the many one-time-use setup features and move these one-time-use to an admin user level.

Once that was done, well what was left was either really needed features or things that seemed good at the time they were developed, but that really could be removed. It pained me, but I got out the pruning shears and actually destroyed some of my past work.

Funny, that swiss army knife example above is used again and again in the software development world. The images are used all over the place. I don't know who came up with it originally, but this well-written article from 2010 may be the source and since it was written in Switzerland, well, it's very possible. Below is an example, using the all-important Area Types & Tasks menu.
  1. Managing Director
  2. Managing Director

Priority 2:
​Provide Solutions

Not Software, the solution is in the answers it provides

Face it, nobody really wants more software. A good friend of mine in the industry, who likes my software better than the package he's forced to use, has offered this simple advice for years:

"Customers don't want software, they want answers"

And, actually, my distributors figured it out years ago since they make as much money consulting with their clients as they do on software licensing fees.

While iManage does do consulting, which primarily involves software set-up and training, in the end we avoid what we don't like to do. So, if I could, I'd duck the consulting job and pass it to my associates.

Considering the time-line:

  1. When we started 25 years ago, the software was very simple. It didn't do much, so it was possible to train users to do their own setup if they wished. Usually, we'd migrate their space inventory for them and then train them to set up their area types and tasks. But, now it's a whole different animal, but like all humans, I was stuck on a particular 'rail'.

  2. Setup is a one-time event with usually minor modifications needed along the way. Sometimes a building is remodeled or added. But since its not frequently done after initial setup, it doesn't make any sense at all to train users to do this. It may cost a little more up-front to package the setup together with licensing fees, but in the end it costs a lot less. 

Implication: A change in the business model needed

It takes some courage to realize when we've been wrong, to admit our past mistakes. But in the end, there is no other logical thing to do.

So now, we've changed our business model. Setup must be included in the inital negotiations. It's required since it's our reputation that's at stake. Not only is our reputation, but the reputation of the customer who brought us into the facility.

Since we've found that customers charged with learning the setup as well as the day-to-day use functions results in stress, frustration, and failure. Since no one can afford failure, we simply will no longer sell our software without setup.

It may take a week to set up a small college, or a month to set up a medium-size hospital, but in the end everyone is happy. Its a little harder to sell, since the client's upfront investment is higher, but the true costs are much lower

Priority 3:
Enhance Capabilities 

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:

  1. Implementation method, obviously users can't be bothered to individually set thousands of rooms with area types. Solution: It must be automatic.

  2. 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:

  1. The original area types are marked as templates.

  2. A new area type is created for each room based on its template

  3. Existing frequencies in the new area types are all initially set to never. I'll explain why later.

  4. 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.

Work assignment page showing 4-way toggle to add or move a room into an assignment with options for primary and secondary cleaning task frequencies