(On the topic of priorities vs. calendars, see The Power of Focus by Jack Canfield and First Things First by Stephen R. Covey, A. Roger Merrill, and Rebecca R. Merrill.)
When you do need to use a calendar, it is best to lay things out well in advance. If you just put them in outlook, you'll get a remind 1-3 days in advance (or 15 minutes). That generally doesn't work. For big things, you need to set the schedule, plan on it, and make it happen.
Calendars fail for the most part because people don't actually refer back to them. Items are set, but not set in stone. So they get moved around and forgotten. This gets to the basics of management. If it's important, do it. If it's not important, don't schedule it.
When your staff see that you don't make something a priority, they won't make it a priority.
. . .
So what kinds of things are we talking about? I won't try to give an exhaustive list of the things you might schedule, but I'll give you some examples. How you handle the scheduling of various task depends on the task, and who is responsible for the scheduling.
In an earlier post I talked about celebrating birthdays and anniversaries. That schedule is probably kept in Outlook, but could also be listed on your managed service grid (Excel spreadsheet) for tracking your clients. It is by the office manager.
1) Who is responsible?
2) Where is the definitive schedule information stored (e.g., in an Excel document on \\companyshare\operations\procedures...)
3) Where else is this information stored for ease of use (e.g., printout on bulletin board)
4) What is the process/procedure for updating this information?
I'm going to give some example schedules and processes. After you see a few of these, the "process" of managing a scheduling process should be very easy to replicate.
- - - - -
Example One: Quarterly or Annual Reviews
Background: I'm a big believer in quarterly or annual reviews for employees. Yes, you see them every day. But it is always nice to get a formal review about what's working and what's not. This is a perfect example of something that is easy to put off - with bad consequences. If you announce reviews and then put them off and put them off, then employees conclude that it's really not important to you.
Process: The office manager creates a personnel spreadsheet that includes the employee's name, date of hire, last review date, and next scheduled review. (Note: The actual review process is the subject of a future post.)
The office manager first determines which dates and times the manager would like to set aside for reviews. This often works best if you pick a standard time slot and let the office manager fill as needed. For example, you might do employee reviews on Tuesday mornings. The office manager will need access to the manager's calendar. Once times are established, the office manager contacts technicians and other staff to schedule reviews.
Reviews should be scheduled far enough in advance for the manager to review the employee's file, write up a paragraph or two, fill out the company's standard review form, and generally be prepared for the review itself.
When the review is completed, any action steps that are required should flow to tasks in Outlook or the company's PSA system. For example, the employee might be getting a raise or increased hours. The employee might be eligible for company-paid training. You need a process to make sure that decisions made as a result of employee reviews turn into actions within the company.
The office manager is informed that the review has taken place, updates the Excel spreadsheet, and creates a tickler to schedule again in three months or twelve months. You can see that a nice flow chart for this process makes it very smooth.
Example Two: Monday Morning Meetings
Background: When your company gets to a certain size, you might find that you are all running around and don't see each other much any more. You need to maintain/build a company culture. Part of how you do that is to get together in a "huddle" at least once a week. It doesn't have to be long. But you should create a forum to chat with one another, get to know each other as people, and keep the work focused on what needs to be done to stay profitable.
Process: For example, you might have a meeting of the managers each week, followed by a meeting of the company as a whole, and then perhaps the individual departments. Again, these don't have to take long. If the managers work closely together all the time, maybe they don't need a meeting every week.
Let's say you have a schedule like this:
- Managers meeting = 8:00 AM
- Company Meeting = 8:30 AM
- Tech Team Meeting = 9:00 AM
The key thing here is consistency. If you schedule a meeting every week, hold the meeting. If you cancel it every other week, then don't schedule it. Perhaps impromptu meetings work.
You'll notice that, even with a very small staff, there are people who will "save up" issues to bring up at the company meeting. If you schedule and cancel, you frustrate these people because they thought they had an outlet for their concern, but now it's shelved for another week.
You can say, "Well, it shouldn't be that way. Just speak up." But you have to remember that we all have different and unique personalities. Part of building a team is recognizing these differences and helping people learn to work together. That includes YOU being aware of the kinds of people on your team.
Example Three: Monthly Maintenance
Background: You should run a "Monthly Maintenance" procedure on every contract client every month. If you have a Remote Monitoring and Management (RMM) system, then your list of chores is very short. That's because many things are monitored 24x7 in real time, such as disc space. But you will still need to go to the client's office, shake their hand, look at their server, test the backup, and do some kind of checkup. This is partly tune-up and partly client relations.
Process: For starters, you need a monthly maintenance checklist. That's a list of things you will monitor or do every single month as part of the preventive maintenance that makes managed services work. If you need a place to start, check out my Newly Revised 68-Point Checklist. To download the latest version (68-Point Checklist version 2.0), just go to the White Papers page at SMB Books. No credit card required. Instant download in PDF format.
Once you have your standard checklist, you will refine it for each client. Clients have different backups, different databases, different network setups. So their checklists need to be customized.
You will need to execute four things every month with regard to monthly maintenances: 1) Execute the monthly maintenance checklist at each client; 2) Revise all monthly maintenance checklists as needed; 3) Make sure the revised MMC is published appropriately and "ready to go" for the next month; and 4) Each MMC must be filed away for future reference.
Obviously, you have a serious time crunch here. No matter whether you have ten clients or a hundred, you need to execute the MMC every month. Someone needs to maintain a calendar so that MMC visits are space properly (Clients look puzzeled if you show up on the 27th of February and then again on March 1st). This scheduling might be done by the office manager, but is more likely to be done by the tech department.
It's a good idea to keep a calendar of when MMCs were executed at each client so you can look back very easily. You almost never need this information, but it's handy when you do.
The revision process is very simple, but needs to be done! If you skip it, you just create more work down the road. Revisions include things like noting that the c:\ drive is too full for logs, so the logs have been moved to the d:\ drive. If that happens, the checklist needs to point to the right place. Normally, revisions are little things like that. Occasionally they are major, such as a new backup procedure.
In a perfect world, the checklist will be updated as the last item on the checklist. But if the tech is onsite, then it will likely wait until he gets back to the office. The problem there is that checklists tend to get thrown on a pile because something more important comes up. If that happens, you need to set aside a date or deadline to get them updated. As for "publishing," I simply mean that the revised document should be posted on your internal SharePoint site or uploaded to the PSA. We publish these in .pdf format so that they can be accessed and printed off from any computer, including a client server with no Word program installed.
Finally, you need to file away your MMCs. You might file them all together for one month, or put each one into the appropriate client folder. Which you choose depends on which you think will be more useful down the road. You will need to refer to these when you are looking for problems across clients and when investigating something with a specific client. For technicians, having them all in one place is probably easiest. For billing and client relations, having each client's checklists in the client folder works best. You decide.
All MMCs should be executed by a certain date. They should be updated and published by a certain date. And they should be filed away by a certain date. Every month. No exceptions. Determine who will be responsible for each of these schedules and develop a process.
Example Four: Patch Management
Background: Whether you have a professional RMM tool such as Level Platforms or you roll your own with Windows Updates, you need to have a process for applying patches. It can be pretty well automated, but you should still check up on it on a regular basis. And just in case I need to say this: You should absolutely be applying patches, fixes, and updates to you clients' machines!
We all know that Microsoft security patches come out once a month unless something really nasty is happening. You can stay tuned into these updates at http://technet.microsoft.com/en-au/security/bulletin/.
So you need a schedule for applying (or not applying) these patches. Some MSPs take the view that only specific, relevant patches should be applied. We take the opposite view. We think you should apply everything unless you have a specific reason NOT to. The days when patches blew up the world and destroyed things are pretty much in the past. Still, some caution is useful.
As a general rule, we apply all patches. But we don't do so immediately. Sometimes patches are recalled, or black-listed by our RMM tool. In such cases, we are glad that we proceed slowly.
We recommend that you schedule patches to be applied Sunday night. If there's a backup, schedule after the backups are complete. If you apply all patches every Sunday night, then all machines should be up to spec when you come to work on Monday. In the rare instance when a machine hangs or is waiting for an "enter" key, you can take care of it first thing.
In the old days, before RMM and before Microsoft patches were as reliable as they have become, we had a three-tiered process:
1) Wait a day to see if the patch is recalled
2) On the next available weekend, deploy the patch to our servers/workstations
3) On the next weekend, (assuming no problems) deploy to client servers/workstations
As with many processes, it doesn't matter exactly what your procedure is, as long as you have a procedure in place.
For the most part, the patch management "schedule" runs automatically, especially if you have an RMM tool. Still, someone should be responsible to make sure that things are flowing the way you want and that you're not missing any big patches.
- - - - -
Those are somewhat long examples, but the point is to show you that you can have a systematic approach to success. If you put these processes in place when you're small, then you'll have to fine-tune as you grow. There are plenty of other schedules and calendars in any business (holidays, tax deadlines, government paperwork, insurance, etc.). Some simply show up in the mail. Others need to be managed.
Once you create a system for one scheduling process, the second is easy, the third is easier, and so forth.
And you never have to be surprised when something shows up on your calendar!
Your Comments Welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at http://www.smallbizthoughts.com/events/SOPFriday.html.
- - - - -
Next week's topic: Checklist for Scheduled Maintenance
[NOTE: This blog post revised October 2012 to reflect the new location of the 68-Point Checklist v.2.0.]
Designing and Selling Cloud Services into the 1-20 Desktop Environment
Seminar on MP3 Download
This is an audio program with the PowerPoint slides in pdf format. Includes one MP3 audio file, one PowerPoint slide deck and one client-facing advertising example. All delivered in one zip file.
This seminar is intended for small computer consulting firms that want to learn how to develop profitable cloud service offerings for their smallest clients.
Only $39.95 !