mandag 18. februar 2013

Policy as focus tool

I've been working for a while for an employer whose concept of "plan", "policy" and "procedure" is not only a foggy area through which one can not tell the three apart, but are further muddled by an unwritten current practice to which you are held responsible but not told.

The two first months of the year is spend writing document after document with "plan" in the title, albeit the contents range from a list of investments to policies, not to mention the "goal plan", filled with some vague unmeasurable purposes to which you're supposed to come up with actions whose effect may not be tested beyond "completed".

While some will call this "politics as usual" in the public sector, the vague framework causes real problems with communication between departments and expectations. In order to survive the work day, everyone becomes their own boss, and many of them decide to become the boss of everyone else.

As a rememdy for my own department, I wrote up a policy framework just for us. It's not big. It's based on the purpose of our department as described in the founding document: Technical support, maintainance and development projects. I use the broad definition of the term "development", as it not only includes in-house software development, but any changes to the IT system: Installation of new software, modification to the infrastructure, etc.

I elaborate on what we do in order to follow up on each of the main points, link in procedures where needed. Writing the document up gives a deeper understanding of what we do and what needs to be done. But for the team to really benefit, they need to understand and respect The Document. For all purposes, there is only one way to do so: involve them on a regular basis.

So this is our current schedule:
  • Every friday, we do a retrospect meeting over a pizza. The retrospect has several functions: 1) Status reports on the most important tickets and projects, 2) Feedback to team members, thus making them feel valued, 3) Solving unsolved puzzles by involving the entire team, 4) Lifting work off our shoulders, so that the weekend can be enjoyed better, 5) Raise awareness to other developments, meetings, system changes.
  • On the first work day of new moon, we run a Kaizen session. The department's policy framework is used as the framework of the meeting. We may not be able to go through the entire policy in one sitting. Giving this time, however little, helps the team own the policy. And that makes all the difference.
  • Status reports, policy changes, notes from meetings we have attended, etc, all go into a report headed for top management at the end of every month. This helps make our work more visible to top management.
It may cost us 10 hours of work per team member every month. Alas, from even the first meeting, you shall see the rise of morale. And from that comes an increase in productivity.