onsdag 30. mars 2011

PK Scheduler Diary

I've been working on a scheduling principle for Personal Kanban.

Say what?

A way of scheduling my Personal Kanban. Kind of mixing my PK and my calendar. And make it all portable. There's a story behind it.

In the beginning, there was Personal Kanban

It all started with my experimenting with PK at work. Obviously, as the team leader, I have different tasks than the others. I do things that don't go into the support system. And PK in its simplest form gave me tremendous stress relief. Even though I know there is a backlog, I can easily see how much I have already done today, not to mention this week. Tear down finished tasks on friday for a retrospect. It worked quite excellent - for the first couple of weeks.

Then came the questions. "When will this task get priority?" "How about this task?" The concept that I'd pick the highest prioritized tasks every day was not a good enough answer. Some tasks might never get picked that way. And I did not get a proper overview of what needed to be done when, even when the dates were on the cards.

Then came the calendar

So I made a scheduled version of the backlog. That is, I made a small four week calendar with space for one card each day. Any task put into the calendar will be the main task that day. Anything put on the calendar will be processed the day that has been scheduled for it. I will also not promise that the task will be processed any sooner - so it can safely wait until that day.

If I have any spare time after the main task, random events, random support calls, scheduled and unscheduled meetings, I pull new tasks from the unscheduled backlog instead of the calendar.

When a week has been cleared, that column is immediately reused for appropriate tasks from the backlog. The system works like a dream, and I go home with the knowledge that everything that I promised has actually been delivered.

Freedom of movement

Then a virus came along, and I had to work from home for a while. This promted the problem of only having physical access to my Personal Kanban and scheduler. I would drop by the office once in a while to get stuff I needed to complete tasks at home, and update the scheduler. I brought a bunch of cards with me in my meeting book.

It doesn't take a rocket scientist to find out that the easiest way to carry my Kanban along was to use the first couple of blank pages as a portable Kanban board - of which I am not the first person to reinvent.

Except, I used those pages for the scheduling, and usually use the monitor for the board itself. Notes stuck on the left side are ready, below the screen is current, and completed on the right. At the end of the day, stick completed task in meeting book for future retrospect.

Combine with note taking

I delegated a meeting to the apprentice. I really don't expect anything ground breaking to come out of the meeting, but I believe the apprentice can learn a bit. So I gave him a link about note taking techniques. My favourite is a page split in two, left side for notes, right side for actions. Alas, my ordinary meeting book does not feature this layout, and although I could easily make this design by hand, I decided I just wanted something smoother.

Although the notepad generator is great, I wanted an entire book of these - one notepad per day. I believe we call these diaries. And indeed, the seventh sense diary that the municipality has bought features this layout.

So how do I combine this with my scheduled Personal Kanban? Easy! Put future tasks and relevant information on yellow sticky notes. Put them on appropriate dates. Left side (note side) I put in my appointments and other important information about that day. Right side goes for the important action item for that day. When the day comes, the page is my "ready" column. The monitor is still my "go" column.

When a task is completed, I use the notes section for the retrospect in addition to meeting notes - and throw away the used note. The right hand side is then filled with information about the new tasks required. At the end of the day, I produce new sticky notes for the new tasks that need to be scheduled on a different day.

For about two seconds, I wondered why I didn't just use the diary as a diary and write the appointments and todo-lists directly on the selected days? Before the two seconds had passed, I realized that the sticky notes represented a floating possibility of a future, plans might change, and the sticky notes make it easy to move them around easily. Anything written directly on the page, however, becomes the log of what has been done, learned and decided.

søndag 27. mars 2011

The wrong script: UC as a replacement for process

Conference room at Hotel Ivar Aasen

I went to a meeting with the municipal where a local service provider presented a telco-side UC solution. There was much to like, of course. To present their case, they had a video from a make-belief architecture company. The script went something like this:
    Someone about to go to a meeting with a client looks through the project drawings, believes that the drawing is made by an architect who is currently on another phone call. So he calls up someone else, they discuss the content and whether it is possible to change the roof angle, add the carpenter to the call even though he is out in the field, the carpenter believes it is doable, but will cost more.

    After a bit, the estimate comes back from the carpenter, and the project now costs 12% more, though everyone in the project group goes for it. The boss, of course, is on vacation, and has this strange feeling that he is behind on the project and pulls a spontanous video meeting to get updated about the progress and why it is now 12% above budget. He feels at ease after the meeting.
While this gave a wonderful display of how teleconferencing has been made so much easier, I could not shake the feeling of something being terribly wrong in this picture. It was just the wrong script. I shivered as I started to count all the wrongs:
  1. The drawing should have been marked, so you don't have to ask who drew it - you just look it up.
  2. The team is presented as a project team. It should be obvious to everyone on the team who does what, not to mention who made the drawing in this specific project. Why do you put someone to meet a client, if he doesn't know everything about the project already?
  3. The request for alteration to the plan was taken from thin air without first talking to the client, and for no obvious reason. Obviously, alterations are better discussed with the client. Keep them in the loop!
  4. Everyone keep interrupting eachother for no obvious reason. After all, none of the information required were critical to the continuation of the project - except perhaps the financing bit.
  5. For every meeting in the project, short and accurate notes were made. Yet, the boss decided to call in for a video conference instead of reading the notes. So why, exactly, were notes taken, if not for someone to read?
I envision going to the client meeting, mentioning the angle of the roof, telling that it can be altered and query if this is something to spend time on. If yes, then go ahead, otherwise all this work is for naught.

Alterations like these are routine for an architectural firm, there are already processes in place for such. Indeed, I have been in such meetings (as a client), and they are very structured.

The video presented the alteration as an extraordinary event, where people had to drop everything in their hands to deal with this one thing. Or in other words, technology helped them interrupt current work in progress for something that should have been dealt with by the proper processes and proper documentation that the firm did not have in place.

I am not against UC, but it is not a replacement for proper work practices and documentation requirements.

onsdag 23. mars 2011

CIPA part 5: National solutions

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5

Employees of the Norwegian Wealthfare Agency (NAV) complain about how their systems are outdated. Some must even "learn DOS commands", which we know is the umbrella term for black windows with white text where you must actually use the keyboard.

NAV is a "recently" established cooperation between local and state government bodies. Some of the IT resources are owned by the municipalities, while others are owned by the national government, and there is little information being passed between these as a result of content rights and personal data protection directives. Setting up a NAV office requires some planning to enforce all the information flow/blocking policies. Even copy/paste is disabled across the platforms, so you can't copy information between the municipal and the national systems.

And this is where the pain begins.

As each municipality runs their own systems, NAV must attempt to integrate all of them into the big conglomerate. But neither state nor NAV has the authority to override what is installed at the local municipalities as long as it conforms to certain integration standards. Because if national authorities dictated a shift of technology, then national authorities would be liable to pay the bill. In the short run, the cost of integration seems to be smaller than the cost of conversion. By publishing the integration interface, much of the integration cost is now pushed over to the municipalities as part of their annual software license fees.

The cost of convertion, as such, is what we my refer to as "the cost of exit." As each system has an entry and a maintainance cost, there is also an exit cost. What does it cost to change system? And what system should be our standard? After all, setting a national standard would kill the business of all the other tailored government system developers. Some commercial actor would be able to monopolize. So how do we get out of this?

In 2006, the Swedish police turned to an open source platform and hired its own software developers to build their own mySQL and JBoss based information system. From this, they gained tailored software, a flexible system that can quickly be altered to reflect the needs of the police, full ownership of how the system works with their own data - and economically? The project pays far more than the investment in software developers. Reduced licensing and consulting costs equals approximately 400 fully equiped police cars per year.

A similar approach may be used in other government bodies, where specific tasks have been defined. This is what you do, let's all do it on this one system which we all own. If a law changes, we can change our own software - or pay huge sums to 4-5 different software companies to modify their software for the new law.

And one could take this a step further by setting a national standard for ESB - or would that be a GSB (Government Service Bus)?

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5

søndag 20. mars 2011

EU Retention of Protected Data Directive

The Norwegian government has been discussing the Data Retention Directive for years, and the government has been fairly split about it. So split, in fact, that it has been declared that the vote is now dependent on one single party in the right wing. And their verdict just came out: "Yes, we want the directive, but slightly modified." (The no-side, obviously referring to the Data Protection Directive, which they claim is at odds with the DRD.)

While I'm all for solving crimes and preventing terrorism, I try to be a little bit realistic. Because logs of IP traffic, SMS contents and email headers are at best circumstantial evidence and will be difficult to hold up in court. Why? The data logged is about the communication between devices and does not guarantee the identity of the people using them.

The information might be interesting in terms of indicating where to look, as a tool of finding potential clues, but it is not real evidence in itself. Similarly, I once received a ticket for passing a toll road without paying - except both I and my electronically identified car was some 100 km away at the time - I had a time stamped photo where I was at the time.

How could this happen? The car that passed the toll road carried the same letters and numbers on its registration plates as my own car - except his registration plate was from a different state, and the system didn't pick up this tiny detail.

So imagine this going a little further - for some tougher crime: Someone steals a gun from the local home defence, shoots someone, and drops the gun. Police picks up the gun, reads its registration number and uses this as evidence that the local home defence did it.

As for the Data Retention Directive? Just because someone hacked into my Wifi doesn't mean I started the video conference that was logged. And no, I was not even near Düsseldorf during that bank robbery - my cell phone was there, yes, it was stolen! And I did not sent that text message, a friend "borrowed" my cell while I was in the bathroom.

The DRD does not indicate any automated analysis of the data, which would have some kind of use in detecting "suspicious behaviour" - whatever that is. There will be enough arguments that illegal activities can not be properly detected by automatic data analysis - though I suspect the most resoureful governments have been doing this kind of analysis for ages already.

Actual value is therefore limited to following circumstancial traces - akin to the situation you have when analyzing every finger print in a bank after a bank robbery. And at that point, you already expect the bank robber to wear gloves.

Real world results from the directive?
And in Norway? The final decision is scheduled for April 5th, where the only two parties that want the directive are expected to vote under the whip. And if they don't vote by the whip, the directive won't pass.

It's a bit scary to see that the secret service sees the directive as their "most important tool."

fredag 4. mars 2011

CIPA part 4: Local solutions: Gaining control

The public IT policy in Norway is one of purchase. That is, it is up to software development companies to create solutions that fulfill Norway-specific requirements, which the public administration in turn buys - at an ever increasing cost.

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5

In many ways, one can say that a small group of software companies in Norway increasingly "own" the public sector as a result of this policy. And consultants are having a field day. I have often wondered what the rationale is and observed the following points:
  1. Large systems are required, and it doesn't make sense that all municipalities hire their own programmers to develop their own systems. Let someone else reinvent the wheel.
  2. When using open source software, there is noone to call if something goes wrong.
  3. Anything built in-house is at the mercy of the developer - what if he/she quits or gets run over? Nobody else will be able to take over. (Interestingly, this is also considered to be true by many even if the local developer makes his work open source.)
  4. Spending money on the private sector makes money go around and does, eventually, return as taxes. Spending money specifically on the IT industry thus strengthens the IT industry in the country.
There is certainly merit to all of these points. Yet, the local IT department in most municipalities still tend to be undermanned and spending a lot of time on extinguishing fires. Because large systems do crash, even if they are provided by a large vendor, even a few good men can not know everything. And what SHOULD be obvious, yet most don't fully realize: the more that happens outside the control of the IT department, the less control the IT department has.

What is going on around here?

When I started in my current position, most of the operations were outsourced to a consulting company that also had the contract for equipment purchaces - an obvious conflict of interest. Documentation was scarce. Sure, there were the passwords, there was a "kind of network map" that went into great details - albeit some of the most meaningfull details were missing, and the map had not been properly updated for four years.

Only a few days into the job, I would get a phone call asking how a certain case was going. I had no idea, I didn't know the case existed. I had to check with the consultant, who was there only two days a week. My little sheet of notes turned into a bunch of yellow postits, which turned into a hierarchic digital notebook, which eventually was impossible to keep track of. And documentation was still scarce!

Tools to regain control

The overlap time was spent putting together as much documentation as possible. These tools worked for me, though they should be evaluated as any tool be evaluated before using:

Network documentation consisted of drawings of cables with tiny annotations indicating VLAN and port numbers. This was an excellent outdated physical map, but did little to easily demonstrate how the VLANs were routed. A created new maps using FreeMind - one for the physical connectivity and one for VLAN routing. One of the reasons for choosing FreeMind, is that the files produced are actually XML-files, which can be interpreted and put in a mySQL database - and even reproduced on the basis of a mySQL database.

Software documentation went into a local MediaWiki site edited by all IT staff - hereafter known as the "ICT Wiki". Exceptions were made for passwords and other attachments that don't make sense to put on a wiki. Any piece of software we found out was part of our operations would go into the wiki as soon as we discovered their existance.

As far as support went, I had one guy for all the schools, and 90% of everything else was dealt with by the consultant. With 700+ employees, the lack of a support ticket system was screaming at me. I installed eTicket just to get on top of things.

Cleaning up

Next, I told every department to call IT operations first, not the consultant. And preferrably, send email directly to the ticket system. This way, we were able to gain a better understanding of what the issues were, do more in-house, build documentation, make a more unified design and use the consulting company only when needed.

The contract was eventually cancelled, as we no longer needed them for the minimum amount required to fulfill the contract.

A clean-up job is something that takes a really long time. The bigger the systems and the larger the network, the longer you will have small surprises pop up at you. In this 700+ employee, 12 location organization, surprises from "the consulting era" still pop up three years after. We are not done cleaning everything up, but we're slowly getting there.

Internal strategies

Software tools are not enough to get on top of things, though. There is also work flow. As IT professionals, we tend to strive for continual betterment, which in Lean-terms is called Kaizen. We couldn't turn the entire organization lean over night, but we started to turn the IT department lean by focusing on the time consuming tasks:
  • New employees: previously a two hour cost for the IT department, now 50 seconds.
  • Password reset: previously a two minute cost for the IT department several times a day, particularly in august and january - now a self service.
  • Moving empolyee between departments: previously 5 minutes of research and 2 minutes of doing - now a 10 second service. This will eventually become a self service for the department leaders.
Every task we find ourselves repeating over and over again are reviewed for automation. One must, however, carefully follow the procedures and remember to document what has been done in every ticket. In order to keep focus on current tasks, we have turned to Kanban. This is currently being tried out in different fashions, and I will be writing about my own experienced in this field.

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5