lørdag 10. desember 2011

So what happened to trollsilm.com?

I was busy moving and spending time in hospital and preparing for the birth of my third child, all at the same time. So trollsilm.com renewal slipped, and soon after someone jumped on to it. I have tried to get in touch - after all, there should be a prize tag to get it back - but to no avail. Hence I have registered trollsilm.org and will be moving there soon.

If anyone has the time, determination and possibly money to bother the heck out of the squatters, feel free:

From http://www.ip-adress.com/whois/trollsilm.com
Registrant:
Above.com Domain Privacy
8 East concourse
Beaumaris
VIC
3193
AU

Tel. +61.395897946
Fax. 

mandag 25. juli 2011

The fertilizer man

I can not give this man a more fitting name. Some will call him "the devil" or "low life" or "insane" but after setting off a car full of fertilizer bomb, and knowing what that smells like, I will always think of him as "the fertilizer man" no matter how much damage he made and how many lives he took.

While most of the world seems to have arrived at logical conclusions around the entire incident, I have come across some - I'd almost say appologists - who seem to have failed miserably at their quest for logical reasoning as the perpetrator himself. From the point of view of the Fertilizer Man himself, the idea that multicultralism is destroying Norwegian culture, I beg to ask the following questions:
  • If the big enemy is multiculturalism, why kill Norwegians?
  • If the humongous problem is the destruction of Norwegian culture, why kill Norwegian youth?
  • If the big fear is massacres performed by foreigners, why make it so blatantly obvious that the self proclaimed protector of Norwegian culture also is the greatest mass murderer of those who could bring Norwegian culture forth?
  • And if protection of Norwegian culture was so important, why so much fear of the smallest group of cultural immigration, when it is so blatantly obvious that the greatest threat to Norwegian culture is Mickey Mouse and Ronald McDonald?
The idea that he blows up some government buildings - sure, I can see that happen. Happens all around the world from time to time. Many people have their secret wish to blow up the parliament every time some strange taxation law or other regulations interfere with their daily lives. The Fertilizer Man got that one down. Fine. You're angry with government, you blow up goverment, I get it.

But shooting youth who have barely reached legal age - and some of them not even that - is just an appalling act of evil. And a rediculous one at that. You first claim that non-Norwegians are a problem, and then you go shoot Norwegians.

The only logic to this is the idea is the "monoculturalist vs multiculturalist" scenario. So the monoculturalist went to war against the multiculturalist. And that's where some of foreign mass media have picked up.

Russia Today is repeatedly reporting about a "multikulti fail" in Norway:

Even the title is wrong, insisting that he turned "against his own." He did not. In his world, he was the monoculturalist against the multiculturalist. That's where the "us vs them" was.

Taken out of context is the Norwegian border closure. While they are still investigating the possibility of the Fertilizer Man not acting on his own, police want to make sure they know who leaves the country. This, however, is being portrayed as a sign that the European Union is falling apart in distrust.

To make sure everyone gets the problem with multiculturalism, Russia Today interviews the Spokesman for the Union of Russian Communities in Sweden, who apparently met the Fertilizer Man in his youth:


His opinion is clear. Multiculturalism is bad, he says. Spokesman of Russian Communities in Sweden. What are you doing in Sweden? You're not Scandinavian. You're a spokesman for the Union of Russian Communities. Preserving Russian Culture. In Sweden. Side-by-side by with Swedish communities. What do we call this, again, when several cultures live side by side? Multiculturalism?

It is obvious that Russia and Israel are vested in monoculturalism and therefore support this view. Since the Fertilizer Man was a monoculturalist, and the media of both countries blame multiculturalism, they are fairly appologetic: It wasn't the Fertilizer Man's fault, he was forced to do this by the multiculturalism that wouldn't let him sleep at night.

Again, if blowing up the government in protest was all he did, fine, it's a protest. Absurdely aggressive to be in Norway, but it's a legit target in war, and to him, this is war. Youth camp? Sure, it was a political youth camp, but still.

With all the talk of "multikulti fail" and the preservation of Norwegian culture, I can't help but think of what Norwegian culture has been for the last few thousands of years. As a friend in Atlanta once pointed out - our genes look so incredibly diverse to be such a small country.

Guess what, even our genes are multicultural, as we have been trading, importing culture, slaves and wives from large parts of the world since at least the viking age. And we traded and lived side by side with the Sámi people, even paying them local taxes whilst visiting anything north of Trondheim until Sápmi was annexed by the king of Sweden.

Multiculturalism is nothing new in Norway, it's monoculturalism that's new. The strange, suspect idea that we can preserve a culture that has been in constant change since before our written history. And people like the Fertilizer Man are trying to kill Norwegian culture by the sword - or rather by dung heap.

mandag 6. juni 2011

Who needs sticky yellow paper?

Post-its are all too often used to keep your username and password safe and secure to your monitor for everyone to see. As ICT Leader, I rip these away faster than I see them. Even if it should be at a publicly accessible airport terminal - which is probably why an airport has found a way round the "missing post-it" problem at their self service check-in terminal. (IMHO, This photo should be submitted to The Daily WTF)


Photo/observation tweeted by Per Thorsheim

fredag 3. juni 2011

Mission completed

I can not say it has been quiet here in the home of the trolls. While troll mom has been dealing with the troll kids, I have been away completing a decade old dream: To bicycle from Paris to Amsterdam. Indeed, it's the European version of my 1997 bicycle trip from Montreal to Toronto, with a few more personal touches and detours added, not to mention time. Over a 12 day period, I bicycled 900 km, which means an average 75 km/day.

Accomplishing personal goals, I believe, is vital for your psyche. It is easy to see how corporate support to achieve personal goals could increase morale - That is, if my dayjob paid all my hotels, spend work hours planning for the trip, etc. And certainly, had this been part of my job, I would probably spend work hours finding similar businesses to hook up with during my trip.

But be careful: It would be tempting to upgrade my bicycle to an electric one. It wouldn't be the same. I would spend more time stopping than riding, and I already spend about half my bicycling time doing other things than bicycling. It would feel more planned and with less freedom.

In short, as long as everything was in my own hands for the entirety of the trip, I was energized by self realization. This, in contrast to my trip to New Zealand about ten years ago, when I had this "wow, how did I end up on the other side of the planet, how cool is that?" form of self realization the first couple of days until work wore it off.

So the key leans more towards self realization than accomplishing the actual goal. In other words: support, but do not interfere. Or in the words of Dan Pink: You probably want to do something interesting, let me get out of your way.

Completing my mission motivated my wife to bake :)

mandag 25. april 2011

Pending name change

For a while, I have known that Agave has trademarked the name sqML for a product that is similar to (but not nearly as functional as) Trollsilm SQML. This has not been a problem, since development of Trollsilm SQML has been resting on a shelf for the last six years.

As I have pulled the product off the shelf, blown the dust off and started development again, I now see this as a pending problem. Not just in the form of possible law suits if I continue to use the name, but in the form of confusion between the products.

The new product will be open source, and it would therefore be fitting to open source the naming. SQML change 0.8.1 is therefore the actual name change, which will also affect the default extention used on the script/template files.

Suggestions will be accepted as comments to this blog post or to the facebook discussion until May 12th. As I ride from Paris to Amsterdam, I shall ponder the results.

søndag 24. april 2011

Unlean branch blocks road

After finally fixing up my bicycle for the season and going on my first proper morning trip (6.4 km), I encountered this branch half way:

[Photo of cut off branch locking the road]

My initial reaction, of course, was the knowledge that this branch would never have been "lying around" on the road for motorized vehicles. And so my brain started working on what process might be broken here, realizing that the lack of process might be the reason why the branch was still there.

I could go on about how counting the number of branches cut and then the number of branches cleaned away would make it blindingly obvious that one branch had not been cleaned away. Then again, just looking at the street should suffice.

But then, this was more likely the work of kids pulling a branch out, purposely blocking the road, long after the branch had been cleared. As such, the solution would be to bring the branch home, chop it up and dry for next winter.

tirsdag 19. april 2011

Using SQML in the IT department

Ordinarily, on doesn't use home grown technology at work. "Who is going to maintain it if you go?" is the typical caveat. "Let's use open source instead," says the government. Well, guess what. Open source technology is home grown technology. Mostly.

So I started implementing eTicketSupport in SQML. I mean, the application is already up and running, all I'm doing is change the gateway to it, using SQML to modify the database directly through my own GUI.

Points I've implemented so far:
  • Support technician may now respond "as user", so emails sent directly to the technician may be copy/pasted to the ticket as if the user had sent his/her email to the support address.
  • Response by email is optional.
  • Private messages are embedded as ordinary messages, though visible only to IT department. This way, it is easier to follow how these messages came to be.
  • Added another table with template responses based on ticket category. Once category is selected, you may click on template, which then gets pasted into the response edit box.
  • Users log in with their AD login information instead of ticket number+email address. Session is stored in cookie and valid for a week after last access.
  • Once logged in, their first view is all open tickets, followed by tickets closed the last 7 days.
  • Department leaders and super users get to see all open tickets within their own and all departments under them, and are allowed to add more information and follow what's going on in their own department.
  • Archive of old tickets on separate tab.
  • Integrated with overview of who works in your department and ability for department leader and superuser to add "new user" requests and reset passwords.
The code for this shall be open sourced soon.

And if I go? Well, I will continue to develop (it is open source), and I may give support as a consulting job - as will probably many others. And either way, this is merely a new entrance to existing systems. All I have done is to make it more efficient.

mandag 4. april 2011

Polishing old gems

As I have done a few snippets of code here and there to make my life a little easier, I still have not found the ease with which I did things when I used my own Trollsilm SQML, not to be confused with SQmlTM - Which reminds me I should change name of the language while I still have the chance.

I wrote the SLOB database in 1999, the markup language in 2001, and stopped developing it ca 2005 due to time constraints. The tool is still being used by an ISP in Norway, hoping that development will commence. Because just like myself, their experience is that they just haven't found any alternative that allows you to whip up full blown web applications in such a straight forward and intuitive fashion than this.

This might sound like bragging, but as I am now faced with new challenges at work, I long for this tool. I looked up "the competition" (Ruby-on-rails), and found out that they were not really competition after all. Does SQML - or should I call it "TrollML?" - have the right to live again? Should I spend time continuing its development?

You betch'a! There are caveats, of course. Currently, the SLOB database is the one getting the most out of the language. I need better SQL integration that makes it as easy to deal with mySQL as it is to deal with SLOB. And most of all - an Apache module release. I have a good list of things that need to be done, and in which order. And most importantly, I can feel my fingertips getting tingly in anticipation to work on this project again.

Business model? Open source. It's not the technology itself I wish to monatize on in the future, but assisting people who wish to use it.

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

mandag 28. februar 2011

CIPA part 3: Reasons for hiring consultants

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

The department lists a few "official reasons" why consultants are so widely used in the public sector. However, I read these reasons as the typical excuses, not the underlying reasons. As seen from the ground floor, the underlying reasons are usually:
  • Lack of in-house knowledge and skills.
    Surely, the public sector can not compete with the private sector in terms of salaries. Therefore, a lot of local government agencies struggle to hire well educated IT personell.

  • Lack of in-house overview and organization
    The in-house systems can get quite elaborated, as there is pressure to expand at a high rate, install new software and offer support, usually with only half of the work force needed to accomplish it all. Without good procedures for documentation, the overview is effectively lost.

  • Ability to skew blame if something goes wrong
    Let's face it. The IT department is the first to get the blame for anything, even if proven otherwise. If everything was outsourced, you can just point at the consulting agency. "They did it, I haven't touched it at all," is a good strategy to keep your job safe. In the job world, this is known as "office politics", and only leads to more and more outsourcing. I have seen an employer officially declaring that the responsibility for an in-house work conflict had been outsourced.

  • A wide spread belief that consultants are experts, while in-house experts are considered incompetent (thus the expression, "Noone becomes a prophet in their own country"). So in order to leverage anything, keep in mind that management is more likely to listen to the consultant than their own employee. And the consultant is also more likely to leverage their own sales than anything that gains the organization.

  • A wide spread belief that the use of consultants will reduce the work load of the in-house IT-department. Experience shows, however, that anything done by an external company must be double checked and often fixed. This is because the consultant is hired for one specific job and they don't have the full overview of how things are or should be put together.

  • A wide spread belief that outsourcing is a magic bullet to bring down costs. After all, you don't have to hire so many people full time. Then again, as each consultant knows only their own part, you end up with nobody having the overview, and the one person you have on staff is completely unable to do technical support on their own.
Truth is, in order to make good use of consultants, one must possess a good overview of the situation. In fact, to do anything good, you must have a good overview of the situation and proper documentation of the details. This overview must exist in-house and preferably not just in the head of a single person.

When consultants are not used properly, the overview is the first thing to go out the door. First of all, a whole bunch of details tend to never be documented. Outsourcing technical support means that a lot of the user feedback never comes back to you, so you don't really know what the situation is like. Outsourcing the daily administration means you don't see the warnings and errors produced by servers, you don't see the statistics and the details of the systems, and just have to accept anything that the consultant tells you. And guess what. The consultant wants your money.

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

fredag 25. februar 2011

CIPA part 2: Welcome to mount meta

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

As I mentioned in my previous article, DRAC is requesting a method for performing a study with the purpose of reducing spending on Consultants In Public Administration (CIPA). This is basically a meta-meta-request to enable work on meta-information on public work processes. Indeed, anything that begins at a meta-meta-level tends to continue downhill in a meta-meta-meta fashion.

I have actually been in a meeting discussing how some people are dissatisfied with the fashion in which we make plans for meetings that discuss how to conduct the meeting that are supposed to bring order to the meetings discussing the actual work flow of the project.

Hard to follow? Here it is in reverse and in layers:
  1. We had actual work. This work had meetings-on-demand, discussing hands-on issues.
  2. So administration set up regular meetings to discuss how the work meetings should progress with least impact on individual work flow.
  3. The layer-2 regular meetings were interrupting work flow, so in order to fix this, they set up meetings to discuss how the layer-2 regular meetings should be organized.
  4. Quite a few people were dissatisfied with how the layer-3 meetings were interrupting work flow and seen as an unnecessary neusance. So new meetings were set up to discuss how the layer-3 meetings were to be organized.
The meetings containing actual work flow information (layer 1) were pretty much unaffected by this, other than the fact that all the meeting activities took a whole lot of time away from actual work.

Of course, layered meta-meetings is a hallmark of public administration, and is probably a good place to start changing things. Turn it into something more lean. The most meta you should get is discussing the actual work flow and how to eliminate trash observed in the processes. Hence, I believe this particular request is to begin work at the wrong end.

This should not come as a surprise. Sitting at the top of the administration, you can only observe the statistic trend in accounting, and rely on accurate reporting from those who spent the money. The questions posed show a will to reduce spending on this specific account, which is not really addressing the real issues at hand.

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

onsdag 23. februar 2011

Motivation in the trash

How do you make people recycle more?

This question has been asked by the local waste disposal company SSR. What they have been trying for the last couple of years is this: Reduce the monthly fee, and add a harsher fee per kg waste. Recycling paper and plastic is free.

The total amount of waste was greatly reduced - though not due to the production of waste. Albeit some got really good at recycling, which was the intention of this new policy, people just can't help the fact that they do produce waste. And does fee avoidance make up for the time spent separating plastic from paper from trash?

Indeed, it seemed that a lot of people just found new ways to get rid of trash. Among other things, more bonfires were seen in the villages - possibly burning toxic waste, not just twigs and leaves.

When the company finally threw in the towel, still owing millions for the scaling system now attached to every waste disposal truck, non-recyclable waste to dispose grew by 5 metric tonnes for january alone.

Monkey business

Motivational expermients with monkeys trying to see if human hazard gaming is genetic or cultural, show that monkeys/humans approach danger in different manners, depending on how it is presented. As do humans, causing collapses of financial markets.

Customers were given a choice of loosing some money, with the option of being punished by loosing even more money if they produce more non-recyclable waste. So the game was: how do I avoid the additional fees? Answer: Reduce the amount of waste any way I can.

A better approach would be to pay a full fee to start, and reduce the fee by the amount of recyclables delivered. Then the game would be: How do I reduce my existing fee? By recycling more.

Want to make it more fun? Put in a lottery, where the number of tickets you get depends on the amount of recyclables delivered.


søndag 20. februar 2011

CIPA: Consultants in Public Administration

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

The Norwegian Department of Renewal, Administration and Church (probably the weirdest combination for a department - hereafter know as "DRAC") has an article addressing the effective use of consultants in the publics sector - or rather, lack of efficient use. Consultants are used all over the place. Particularly, one is concerned with the use of IT consultants.

The typical excuses to use consultants are:
  • Access to increased capacity in periods when capacity is exceeded
  • Access to skills and knowledge that the organization doesn't have
  • Obtain legitimacy through external experts before decisions are made
  • It is more economical to buy services from consultants than using your own employees
  • Buying consulting services is seen as a requirement to follow national guidelines
DRAC is beginning a study to answer the following questions:
  1. Is there a potential for more efficient use of consultants and/or reduce expenses on consultants, and how much is possible?
  2. What measurements can be done to secure better use of consultants?
  3. What measurements can be done to reduce the use of consultants in the state, and what are the consequences of such measurements?
And their first request is: "What is a good way to perform such a study?"

In the next few articles, I intend to go into the depths of the request as well as address the use of consultants in public administration, answer all three questions and recommend the remedy as proven by the Swedish police force.

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

søndag 9. januar 2011

WikiLeaks lessons

ENISA identified three major incidents from "WikiLeaks Cablegate". In summary, these three incidents are:
  • The leaks themselves
  • DNS and Cloud Service interruption
  • Hacktivist DDoS attacks
To address the first issue, the US government has distributed an internal memo, which ironically has been leaked. The memo focuses on assessments of the technical solutions and policies. While these areas certainly are important, one must keep in mind that the leaks were done by people who see their loyalty to "the world population" rather than "the boss". Hence the "leakers" are known as whistle blowers, rather than parts of a broken system.

No matter how strict you define your policies and attempt to enforce these through access restrictions, this will never account for the whistle blowing humans you employ. Hence the real issue for each agency should then be the psychology of whistle blowers, not system cracksdowns.

In other words, the system will take care of internal policies and access control, and you could tighten up firewalls against external threats, but WikiLeaks is about whistle blowers - the people you thought were loyal to you turn out to be loyal to their personal ethical principles instead.

Principles of whistle blowing
  • The sound of the whistle is something that was supposed to be secret.
  • The whistler has something to gain by whistling, for one of these reasons;
    The tone of the whistling is in disharmony with the whistler.
    The whistler gains something politically, economically or other.
  • The whistling is amplified by a party that gains something by doing this job.
Hidden information leakage between agencies are known as espionage and are not considered leakage. While an employee is still the weak link in the security chain, the reason for leaking are quite different, and therefore differs also in psychology and machinery: While espionage is dependent on nobody knowing that the espionage has occured, leaking is based on public disclosure as a weapon. This, again, means that the disclosure is effective only when the content is to the benefit of the public - either directly by the disclosure of disharmonious behaviour (the most common forms of leakage) or indirectly by amusement.

Further, one might claim that information that only causes amusement is not directly harmful. On the other hand, secret information that is to public benefit typically means that the information is in regard to organizational behaviour in disharmony with public opinion.

So how do we avoid leakage?

Be good.

No seriously, don't do anything that the public would hate you for if they knew about it.

lørdag 8. januar 2011

Snail Mail explained

By using SIT (Snail Imprint Technology), an e-mail can be etched into the shell of a snail. The trained homing snail then sets off a journey of thousands of miles to its recipient, who uses an SIR (Snail Imprint Reader) to decode the secret e-mail.

Caveats:
  • Conflict between distance and average snail life span.
  • Recipients may have to decode thousands of snails before the correct snail is found.
  • Good homing snail programs have not been developed.
  • No RFC available at this time, specifying the exact coding.


Beyond the caveats, we are excited to present this idea to the world community!

See also: RFC1149 Standard for the Transmission of IP Datagrams on Avian Carriers
RFC1149 Real life implementation

fredag 7. januar 2011

Child aged zero or more


What about children aged less than zero? Are those considered children?