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

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.

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:

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:

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

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.

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.

No, you really didn't want to see an image of two deads birds. I thought this might make you smile. ​​

They're cuddling!

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.

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.

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.

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