Lessons From The Office: Part I

Lesson #1
Meaningful change is hard, meaningless change is easy.
Meaningful change isn't cheap, it isn't simple and it takes time. Meaningless change, on the other hand, can be accomplished almost immediately. Unfortunately, it can also be undone just as easily.

Great goals are not accomplished by issuing edicts and setting arbitrary deadlines. They're not accomplished by initiating a new weekly meeting or creating a new policy. They're not accomplished by single person with no support. They're not accomplished without defining that goal properly and then planning out how to get there. They're not accomplished by wishful thinking and thinking wishes.

Great goals are accomplished by thoroughly analyzing where we are. They're accomplished as a group, as a group that belives in the final goal. They're accomplished by testing the new ideas, revising them and testing them again. They're accomplished by not giving up on the change, even if it takes a long time.

That's not to say that small changes are always useless, nor that big changes are always useful. Everyone can use a nice haircut once in a while but too much plastic surgery doesn't always create a Picasso. (Or maybe it does?) The point is that slapping a new title on someone at work is probably a meaningless change but splitting one job into two separate roles can be of great benefit.

Real Examples
I've seen a lot of new policies over the years. Hey, I've been the cause of many of these new policies - just last week I trigerred a new one regarding the central thermostat. Heh. I was once introduced to a new policy that was comprised of two documents that came to a total of 6 pages, complete with flow charts. I saw that same policy summarized into one paragraph two weeks later. Meaningless change, though I'm sure that the goal was a nobel one.

On the other hand, I recently created yet another version of the programming standards for our dBase developers. It was about three pages long with a ton of very technical detail. It took us two 2-hour meetings with all of the programming staff to sketch out the contents and provide training. It took us several more hours and several more revisions to create the final document. That document will now provide the training outline for our new programmers and it helped our newest programmers improve immediately. Hey, another giant document can be meaningless but in this case we took the steps beyond just writing the document to make sure it worked. (I hope it worked, anyway.)

Some time ago, we decided to change the name of our software testing phase to "Quality Assurance" instead of "Beta Testing." This change was decided and done within two days, including related changes for our internal support software. This change was reversed within a few weeks, and just as quickly. As a result of this confusion, we started to refer to this phase by both terms interchangeably. If the terms are interchangeable then I'll give you one guess about what type of change this was.

Much later, we started to hire full time staff for the QA roles. Previously, this was accomplished by our Tech Support team also being responsible for beta testing. With the most recent re-organization, we formalized Tech Support and QA departments, the official team leads and we defined the job descriptions and daily responsibilities. In fact, the Tech Support staff still provide plenty of assistance but now they help the QA staff and they can focus on their primary roles when they need to do so. In this case, making a distinction about the QA department required much more work but it was also much more useful.

There are some procedures that we discussed as good ideas back in March or April. Some of these procedures are only being finalized now, and I had to consistantly work my butt off just to make them happen by this time.

As one example, we needed a formalized process for reviewing all incoming development requests and suggestions from clients. Previously, it was somewhat random as to who approved new ideas for coding and many requests became lost in the sands of time, so to speak. At best, I would create an ad-hoc list and steal fifteen minutes of my boss' time to review them quickly.

Early on, we created a new weekly meeting to handle this. It took us a while to finalize who should and should not be in this meeting. We changed the person that was designated to lead this meeting and this process, since it used to be me and then it was the Tech Support Team Lead. We created and revised several report formats for this meeting. We changed the process for submitting client suggestions to this meeting several times. In fact, I did a ton of coding over the past month on the weekends to revamp and simplify this process yet again.

It's not that we didn't know what we wanted to do. Our bosses had a fairly clear idea of that from the beginning. The process and mindset, though, took a lot of time to figure out. As it stands now, we have the benefit of getting expert opinions from our staff without killing ourselves with administration overhead to make it happen. It's worked out very well for everyone and it can probably survive on its own now without any cheerleading.

That's an example of meaningful change. And as it happens, this particular BAM! process (Business Analysis Meeting) would have been awfully useful several years ago during one of my early phases as Project Manager but we didn't figure it out until our recent re-organization. Meaningful change is hard, eh?