Personal Information Security; Baby Monitor

A video baby monitor in Texas was hacked via the Internet and abused by a very bad man:

If I connected security cameras at work to the Internet, authorities would come at me with full force. Surveillance is sensitive information and must be treated as such. One of the problems, then, is that most people are not trained to think of information security in their daily lives.

As a trained professional, I would look at the package saying "over the Internet", shake my head in disgust and put it back on the shelf - unless I was looking for a public web camera for Runde. Blinded by the convenience, however, a lot of people will cheer with joy for this invention, not realizing that they are opening themselves wide open to a malicious hacker ready to subvert their children.

The formula is fairly simple: Identify what is sensitive information (or sensitive access to your loud speaker as well, as in this case), identify who needs the information and the shortest route there, make sure you do everything you can to protect that channel in all nine aspects: Confidentiality, Integrity and Availability of Storage, Transit and Processing.

I will leave it for the reader as an exercise, before I reveal my own analysis of this system. 

Reflections on a Lean Hospital

Norwegian National TV recently broadcast a documentary about "The Health Factory" (film available to the world until August 19th 2013) where the first question was whether Toyota car manufacturing is the right ideal for healthcare.

Well into the program, former health care minister Bjarne Håkon Hansen presents the following scenario: He goes to Toyota, orders a specific model car he wants, colours, accessories. He is given a time he can pick up the car, and the car is ready at the time given. On his way out of Toyota, he calls the hospital, because he needs a knee operation. When he asks when he can have his operation, the hospital is not able to give him an accurate estimate. His conclusion: Norwegian hospitals have problems with logistics.

While I do not see any problems applying Lean principles in health care, one must keep in mind that there is a distinct difference between manufacturing and health care. And it is the same difference I experience between manufacturing and running a municipal IT department: It is not a production environment.

Manufacturing is a known process. It does not require diagnosis, and the risk of unexpected events are low. In contrast, a hospital will have a varying amount of emergencies, and many operations have a great risk of complications.

There is still value to be taken from Lean also in hospitals: Known procedures can be simplified. Quality can be increased. More things can be taken into consideration. Communication can be improved. However, it is important to understand that one must look at this holistically. The problems presented in the documentary seem to be what happens if top management attempts to implement Lean with a single focus on short term savings.

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.