Asking the youth for the simple solutions

Every year the organization “Operasjon Dagsverk” (eng. Operation Day’s Work) arranges for students in junior high and highschools to contribute one day’s work to a charity cause.

The students takes responsibility for finding a place to work for a day. The company that accepts the student pays NOK 300 to that year’s charity and puts the student to work. This year the money goes to an educational project in Guatemala. The day was this Thursday (31st October).

My oldest son, Niklas (14) asked if he and two friends could work at Å ( Obviously I took the opportunity. I got the idea of charging them with the task of creating two generic business models – one for Project Management and one for IT Service Management.

The boys got to work and in less than two hours, they delivered an intriguingly simple model for Project Management. Their “SUKK”-model pinpoints responsibilities in a project far better than the ruling model of PRINCE2.


Their model for IT Service Management was even more succinct and with excellent focus on exact responsibilities. While ITIL is perhaps the best professional model for corroding responsibility in an IT organization, their SAO model goes straight for the kill with no wishy-washy or overlapping responsibilities.


In addition to this, I got them to define the term “delivery” and had them write down exact deliveries for roles such as “a baker”, “a teacher”, “a student”, “a Prime Minister” and “an architect” as well as writing down their own personal deliveries in life. I have done this exercise many times with groups of executives and experts from businesses and government agencies. These boys were amazing and I believe they did a better and more efficient job than any other group I’ve seen.

The NOK 900 generated amazing value as I will use the results from this day in many seminars and talks to come.

Thanks to Niklas, Isak and Alf-Johan.

20 thoughts on “Asking the youth for the simple solutions

  1. Wonderful, uplifting blog post, Geir. I clicked on the diagrams to see the enlargements of them, but unfortunately for some of us they are in Norwegian. I did get the general idea from your post, though. Kudos to those bright boys – the parents must be proud!

    One thing I didn’t get what you meant about ITIL being the best professional model for “corroding” responsibility. Was that a typo?

      1. Ah! I was too fixed in my idea that you were more positive about ITIL than that, but it’s been a while since I read your article on it.

          1. The aspect of corroding responsibility would pretty effectively outweigh any benefits, however, wouldn’t it?

            1. Yes, it you would implement it by the book. Just like implementing LRH’s writings by the book pretty much gives you the messy scene we see with the CoS today. And that is precisely why you have to cherry-pick what works in there and discard the crap. And that leaves it up to the user’s responsibility to judge what can work in a given situation and not. One cannot rely on any real or perceived flexibility within the system. One must be man (or woman) enough to discard shit that should be filed in the circular bin.

            2. With what you say above, we are in complete accord – as far as it goes. We only get into disagreements as to basic principles and tech and interpretations of those – which you still feel require cherry picking and so far I haven’t seen that.

            3. Marildi: We only get into disagreements as to basic principles and tech and interpretations of those – which you still feel require cherry picking and so far I haven’t seen that.

              Chris: IF one doesn’t actually put the tech to use, then there’s no reason to critically think about or scrutinize any particular part of it. Hence, one can pretend anything about it is consistent and true since it will never be put to the test.

      2. I hate ITIL with a passion. That and ISO20k get bandied about the office like they were the great white saviour come to save us all from the apocalyptic horsemen. In reality both are little more than buck-passing exercises. OK, correction: they provide loopholes in which the buck can be passed and the passor does not get held responsible for their passing.

        Both systems (and Scrum too for that matter) seem devoted to finding ways where $SOMEONE_ELSE has to make every decision you need made, however $SOMEONE_ELSE is left undefined.

        So in real life I actively seek out opportunities to bypass these methods and just do what needs done anyway. IT is too fluid and too variable to let it get bogged down in reams of paperwork. Of course, I apply brainpower to the decision just – taking down a customer circuit for no good reason isn’t something I would ever do.

        1. Great comment. I fully agree – and I spend a great deal of time warning my clients about these effects of ITIL and many other such frameworks and methodologies (PRINCE2, Scrum, Kanban, Lean, e-TOM…). They try to fix the symptoms from bad recruitments by adding an overlay that is supposed to make the bad apples look OK by automating stuff that shouldn’t be automated – like responsibilities.

          [me want more splog comments]

          1. 🙂

            Let me first say that there *is* a place for methodologies. New staff are often out of their depth when dealing with big systems, so processes and docs help them along. When our Facilities people need to do maintenance on the power, the system sends me a mail so I can prepare, or object if it causes issues.

            Nothing wrong with any of this. It’s where it goes next that is the problem. Just because the new guys need process to find their feet doesn’t mean everyone must be subjected to the same amount of process to the same degree.

            Some things really do need to be owned by someone, doubly so if they are willing to be responsible for the system and for their own actions. With that in hand, let the guy who is taking responsibility just get on and do it. But my biggest gripe of all has to be the insistence on writing documents for an inappropriate audience, like the real audience is very skilled sysadmins but the doc must be written for someone with less experience than a bash script has…

            Which brings me to why I think this all happens at all. The decision makers in these matters are often experts but know little about IT. To make sense of it all they have to dumb everything down to vague high-level concepts or just consider it to be “magic”. And it’s that level of understanding that is reflected in the proces they produce.

        2. LOL, I almost understand your comment! Well, like any ideology, it may contain some benefit but it doesn’t ever seem to be a good thing to let your ideology do your thinking for you.

  2. First, reading the post I was just smiling and smiling, eyes wide open, later the mouth too! As I also work with kids, I know how creative they can be. Oh yes, their heads are not yet full with learnt stuff, they can still look and see in the world
    and love contributing out of their still free minds and hearts.
    Amazing idea of a father, Geir, to involve your kid a little bit in your work. HaHa…if you did that more frequently, your business may even boost!
    Thanks for writing this personal story, this is exactly what I asked for just a couple of hours ago – you were indeed fast! Also, you may think that small, everyday situations, ordinary events and jobs are not interesting ( I don’t know if
    you think that or not) but they are very interesting as no two views are the same.
    Congratulations! To Niklas and his two friends too!

  3. I was amazed when I heard and saw the results from this work – but I was not surprised. I knew it would give you some great examples to your future lectures. Bright boys! 😀

Leave a Reply to Geir Isene Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s