Organization – The simple way (a OnePageBook)

Usually after having read a 200+ pages book, I wish there was a one page summary I could have read instead.

As Thomas Jefferson once said:
“The most valuable of all talents is that of never using two words when one will do.”

Brendan and myself decided to start condensing our concepts into OnePageBooks. First out is “Organization – The simple way”. In just one A4 page you will get a destilled model and how-to for building organizations.

Available on Amazon

cover

Hidden risk of outsourcing IT

There is a potentially undersold risk as a company considers outsourcing IT development or operations: The loss of internal productivity to mentor outsourcing consultants are often difficult to recuperate.

When we learn complex systems, our competence usually follows a Sigmoid curve (also known as “S-curve” or “Logistic curve”).

“Many natural processes, such as those of complex system learning curves, exhibit a progression from small beginnings that accelerates and approaches a climax over time.” (1)

sigmoid_curve

“In this case the improvement of proficiency starts slowly, then increases rapidly, and finally levels off.” (2)

When a company is looking to outsource the development or operations of proprietary complex IT systems, the consultants will usually follow this learning curve. But in order to eventually become productive, the consultant will rely on mentors to learn the ropes.

An internal competent developer or system administrator is assigned as a mentor to the external consultant. The mentor will experience a drop in productivity, and regain the productivity concurrent with the consultant.

Spreading the burden among several mentors may make the productivity loss less visible, but the combined loss of the mentors may even be greater.

According to a recent survey I did, the productivity loss of the mentor was at least 50%. The time needed from scratch to a fully productive developer was 24 months. The question is “How long would it take for the productivity of the consulatant to make up for the productivity loss of the mentor?”. Or in other words “How long until this scenario goes break-even?”.

To calculate this, we turn to the Sigmoid function:

sigmoid_function

Productivity of the consultant (p) is the Sigmoid function over time (t). We adopt the function to go from 0 to the time needed to become fully productive (T).

consultant

Then we adopt the function for the mentor’s productivity (P) starting from his dropped productivity and back to full productivity after T time. The drop (D) is the fraction of his full productivity (1).

mentor

The reason for the slight difference in the equations (the factors “7” and “8”) represents the fact that even after the time “T”, the consultant would on average still be a notch lower in productivity than the mentor.

The two curves combined with “T = 24” and “D = 0.5”:

comparison_curves

The accumulated productivity of the consultant over time is the area under the blue curve, i.e. the integral of p(t).

consultant_integral

To get the accumulated loss of productivity of the mentor over time, P(t), we first invert the mentor’s productivity to get his productivity loss, Q(t).

mentor_inv

And the integral of Q(t).

mentor_inv_integral
The big question is “At what time (t) does the consultant’s productivity make up for the mentor’s lost productivity?”

comparison

With:

integral_indef

… we get:

comparison_integral

…which reduces to:

comparison_integral_red

Graphically represented:

comparison_integral_graph

The question is so big that WolframAlpha cannot display the numeric result within its standard computational time. But with the help of my trusted old HP-41 calculator, the answer was achieved: It takes 19 months of mentoring for the outsourcing project to break even.

The hidden risk is that if the consultant quits before that time, the outsourcing is a losing proposition.

So, if a company considers outsourcing IT to let’s say a Baltic company, one must be very certain that the turn-over of their consultants is above this break-even by a good margin.

The risk management: First figure out how long it usually takes a new employee in the company to get up to full production speed. Add some time if the consultant speaks a different language, is of a different culture and especially if the mentoring is done from a distance. This will be your “T” time.

Then, by a few short pilots, figure out the mentor’s productivity loss. This will be your drop “D”. Along with WolframAlpha and an HP-41, this is all you need to calculate the break-even for the outsourcing project. With the use of some employment statistics from the outsourcing company or the IT industry of that country, you will have a pretty clear picture of the risk involved.

One can, to some degree, mitigate this risk through effective Knowledge Management. A competent Knowledge Manager with an excellent company wiki solution and efficient training setups could shorten the time to break-even by perhaps 20%. Nevertheless, it’s a serious risk to consider – especially since tacit knowledge from years of experience in the company is hard to transfer. Add to this the risk of the mentor quitting or is put on other tasks. Thus the consultant’s stay should exceed “T” with a good margin.

Update (2015-01-18)

An approximation formula will suffice for quick gain/loss calculations. This formula gives the net gain (if positive) or loss (if negative) for any given time (“t”):

gain_loss_simplified

The cult of ITIL

ITIL is the major framework for IT Service Management.

ITIL-V3

It comprises 5 books of Shakespearian English flanked by huge amounts of models, figures and diagrams. It is unwieldy and complex, leaving the reader in awe of its awesome.

chart-itil-v3-v1.9

ITIL has thousands of followers organized in country chapters of the IT Service Management Forum. Piles of papers are written every year, ITIL projects abound, and it remains a huge industry with vendors eager to leech off the ignorance of customers. And while organizations experience real IT challenges, they all too often jump to the conclusion that ITIL is the savior.

  • Problem with Peter.. Peter will not take responsibility? Enforce ITIL!
  • Trevor and Jack won’t work together? Go for ITIL!
  • Lack of IT documentation? ITIL!
  • Sandra shows lack of motivation? ITIL!!
  • Ben is a horrible manager? ITIL!!!

The less passionate employees are about their job, the less they feel a strong purpose, the less they take responsibility, the more ITIL seems required.

The ITIL congregation knows that it has the ultimate solution to every issue facing an IT organization. ITIL is the answer. Never mind the question. Bring out the Powerpoints and hard hitting argument. Oversell like mad and brainwash the customer into a true ITIL believer. The cult of ITIL rolls on in the all to recognizable self-serving fashion.

Sounds like Scientology, doesn’t it?

While the differences are obvious, the similarities are striking. Method before result. The tool becomes more important than the objective.

ITIL has been around since the early 90’s. My experience dates back to the early 2000’s. I used to be an ITIL evangelist, but the glare and glitter wore off along with my many ITIL projects. I did several high profile and very successful projects, but they often succeeded despite of ITIL rather than because of it.

Few ITIL projects succeed in making customers happy. Most fail due to some serious faults in the very foundations of the framework. Like the responsibility model, the complexity of the framework, the lack of true customer focus, the lack of real service focus, the lack of people focus. And above all, the belief that a certain method yields a certain result when the input is unknown. One should be very careful trying to implement a mindset of industrialization in the human spheres. What works splendid in a factory may wreck havoc on human initiative, creativity and motivation.

It is more important to help and motivate people than to enforce tools, processes, methods. The belief in the superior process rather than the superior will to deliver excellent results is the hallmark of a failed ITIL project.

People matters. More than the rest.

This is not to say that ITIL doesn’t have some excellent tools and tips. ITIL is good at describing the playing field and different typical
positions for people to play. It points to some good practices in dealing with IT issues, incoming requests, changes to systems that affect many, etc. But as with Scientology, one has to tread carefully in a minefield and wade through some rubbish to get to the good bits. As Scientology fosters a culture of irresponsibility, ITIL tends to do the same. Not by teaching irresponsibility per se, but by focusing so much on everything else as to leave little room for real empowerment and create a culture of self-thinking, responsible people with initiative and guts.

ITIL purports itself as “Best Practice“, but I was there when Sharon Taylor, the Chief Architect for ITIL version 3, said that the framework contains about 60% Best Practice and some 40% Wishful Thinking.

The best that Best Practice can do is to create followers. Leaders innovate, tread new ground and through guts and allowing themselves to fail come up with ingenious ways of doing things even better. Broad ideas and principles may be great guidelines, but when a framework becomes too detailed, it looses its punch and becomes a one-size-fits-few.

ITIL has created hoards of followers. Resembling a cult. But we don’t need cults. Rather than producing followers, one should strive to make everyone a leader in his own work area – even if the person leads only himself to deliver great results.

A few days ago I came across a blog post that was distributed by the LinkedIn news feed titled, “Top 5 ITSM Tips for 2014“. It reads like a gust from the past and serves well to underline what I wrote above. Tip #1 “Cost-effectively implement best practice ITSM” starts off with a whiff of fluffy business English:

Implementing best-practice IT service management not only ensures you are improving customer satisfaction and relationships with better reliability and quality of service, it will also give your service desk a competitive advantage.

Say what? Implementing this will ensure customer satisfaction? The answer is given. Don’t mind asking the customer. Maybe they don’t need anything even resembling ITIL. Maybe they don’t even need an IT department. Maybe they just need more care from the IT staff. Maybe something else entirely.

I don’t think the health profession was ever as narrow minded as this. Enter the doctor’s office. He has already decided what you need. Without even a second of examination. “You sir, is in dire need of an appendectomy!”

The article goes on with tip #2, “Measure your success”. Now this sounds very good. Except:

Measuring the success of your IT service desk will become ever more crucial as senior management hone down on overspending and look at ways to cut costs.”

The IT service desk… What if the customer got such amazing IT that a service desk was hardly ever needed? How about instead asking the customers what they think about the IT services and measure that instead?

Then tip #3 reads “Manage ITIL like never before”. So, instead of managing customers, and IT staff, we are lead to believe that ITIL is something to manage. Actually, it is the thing to manage. You don’t really manage ITIL or even processes. It’s like stating that the soccer manager should manage ball passing like never before. Nope. Manage the players like there was no tomorrow.

“Deal with the increased demand for accelerated delivery” is tip #4. Sound advice as long as your customers needs are assessed and as long as you are not relying on rubber stamp conclusions from analysts. Your customers matters. More than Gartner statistics.

And finally, the sales pitch for the ITIL certification industry: “Qualify your team”. If that would only advise the reader to qualify your team toward what your customers really need. But no, it means getting your staff through multiple choice questionnaires to pass a theoretical exam. A great exercise to produce followers. A louse exercise to enable IT staff to handle customers better.

The article manages to miss the major point in making IT successful – that what is really needed is motivated people that take 100% responsibility for delivering amazing service to their customers. The area of IT thrives through creative genius, people with heart, people who give it all to deliver excellent products and services, interested staff, real and honest communication and people with guts.

ITIL is traditionally very introverted. Not surprising given it’s a framework for an industry overrepresented with people having a hard time picking up girls. More extroverted contributors have come on board in recent years, but as the framework piles on with complexity, it still suffers from the internal focus.

To enhance IT, we need to inspire dedicated customer focus and a culture marked by 100% responsibility.

Get to the bottom of it!

The insistence on finding the WHY is pervasive. Psychoanalysis. Dianetics and Scientology. ITIL and Root Cause Analysis. The belief that one has to get to the bottom of a problem can be blinding. Because it is far from the only way to solve problems. Sometimes it is better to evade the problem, to find another path or to stop creating the problem altogether.

If you face a difficult situation or problem in life, do you need to find the cause of the problem to solve it? Perhaps. Or perhaps not. It depends. There is no ultimate answer to such a question. Maybe you need what you ultimately think you need in order to solve it.

If your car breaks down, smoke and fire erupting from the engine, do you need to find out why the engine broke down? Not if it is an old wreck of a car. It would be cheaper to buy a new one. And not if it is cheaper to replace the engine than spend much time investigating the source of the engine trouble. It all depends. On the business case. Maybe it was an omen that you should start get in shape by riding your bike more often.

The insistence that one must get to the bottom of it can create tunnel vision and lead to endless hours of therapy or auditing or figure-figure why it is this way or that way. At least sometimes it’s better to just give a fuck.

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 Å (a-circle.no). 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.

sukk

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.

sao

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.