Vad är en IT-kostnad?

Jag fortsätter funderingarna runt Ekonomistyrningsverkets (ESV) rapport Fördjupat it-kostnadsuppdrag – Delrapport 2: Kartläggning av it-kostnader. ESV tolkar lyckligtvis sitt uppdrag inte som att blott försöka kartlägga "IT-kostnaderna" (en notoriskt svår klassificering) utan "att bidra till en effektiv statsförvaltning genom effektivare användande och tillhandahållande av it." (sid 10) Men som alla läsare av bloggen vet så är det inte genom att titta på kostnader som vi får kontroll över effektiviteten, utan man behöver se på kostnad per nytta i varje enskilt värdeflöde. Här krävs ett bredare tankesätt.

Att det är svårt att isolera IT-kostnader konstaterar rapporten. Det görs inte på ett enhetligt sätt vilket gör att verket inte kan jämföra myndigheterna med varandra. Men frågan är om det alls går att jämföra vad som är en "IT-kostnad" i två olika verksamheter. ESV betraktar som IT-kostnad allt som kan härledas till IT (sid 14). Där beskriver man också hur gränsdragningen kan gå till: utrustning som kommunicerar automatiskt kan räknas som IT, medan kostnaden för en äldre version av samma ting som inte är uppkopplad inte kan bokföras på IT-kontot.

Med den gränsdragningen blir måttet "IT-kostnad" snarare ett mått på hurpass mycket myndigheten berörts av digitaliseringen. I vad mån det berott på egen styrning och i vad mån det berott på att tillverkaren försett de artefakter ens verksamhet använder med en IP-adress framgår inte. IT-kostnaderna springer iväg för den myndigheten, men är det bra eller dåligt? I förhållande till vad springer kostnaden iväg? Vilken blir skillnaden mot förra året och vad kan vi förvänta oss nästa år? Och är min myndighet bättre än din?

Alla vettiga nyckeltal ska man kunna agera effektivt på. Bra coachande frågor för den som funderar på nyckeltal är: "Vad händer om nyckeltalet faller med 50 %? Vad händer om det ökar med 35 %? Hur möjliggör nyckeltalet ett rationellt agerande?" Om svaret är att man inte vet, så är det förmodligen inget nyckeltal värt att lägga tiden på. En ökad IT-kostnad som i den ena myndigheten beror på att de tvingas till dyr refaktorering av koden i misskötta äldre IT-system (hög teknisk skuld som nu måste amorteras) och i den andra myndigheten på att tillverkarna av stödutrustning integrerat sina system så att större delar av dem kan anses vara digitala och i den tredje myndigheten för att man skapat ett effektiv värdeflöde med hög grad av digitalisering, en sådan siffra på kostnaden säger ganska lite. Data är som vanligt i första hand något kvalitativt, inte kvantitativt.

Rapporten konstaterar även detta och är betydligt mer ödmjuk i sina slutsatser runt nyckeltal. Riksrevisionen har enligt rapporten tidigare påstått att ett enhetligt sätt att beräkna IT-kostnader på gör myndigheternas arbete med IT-kostnader effektivare, fast jag misstänker att det framförallt förenklar för Riksrevisionen som då inte behöver sätta sig in i varje myndighets unika situation när de ska granska. Rapportens författare är noga med att påtala att det här arbetet med att förstå IT-kostnader är en process som kräver dialog och att nyckeltalen som föreslås i rapporten inte utan vidare kan användas för jämförelser (sid 32). De formulerar det på ett underbart sätt som jag önskar hade funnits på skärmsläckarna hos varje politiker och myndighetschef:

Nyckeltalen måste dock hanteras ansvarsfullt, och tolkningen och analysen kräver ofta djup verksamhetskunskap och måste utgå från verksamhetens förutsättningar.

Det citatet är en av de få eviga sanningarna här i världen och jag har skrivit en hel del tidigare om nyckeltalens fallgropar.

Frågan om IT-kostnader är helt enkelt en hårig frågeställning. Vad beror det på och hur kan vi göra det mindre hårigt?

Jag tror att svaret är delvis historiskt. "Det där med data" har alltid varit en främmande fågel. Sedan Gustav Vasa och Axel Oxenstierna via Max Weber har förvaltningarna haft en särskild sorts informationslogik som bara bit för bit försökt använda informationsteknik för att replikera denna fast på ett mer "effektivt" sätt. Men informationstekniken har sin egen logik. Webers förvaltningsidéer må bygga på stringenta definitioner av processer, men det är ju ingenting emot datorernas krav på omutlig exakthet i allt. I jämförelse med en dator är den torraste och mest korrekta tjänsteperson ett svamlande hav av känslosamt godtycke. Förvaltningen vill kunna hantera information men datorerna kan bara hantera data, det vill säga information helt berövad varje uns av tolkning och kontextualisering. Datorer kan skyffla runt symboler, och ingenting annat.

Så vi har en särskild sorts logik som kräver en annan sorts kompetenser att bemästra och en annan sorts anläggningsinvesteringar och en annan sorts driftskostnader än vad förvaltningen hade haft utan datorer. Denna nya sorts förutsättningar kontrasterar emot de gamla. Det har gjort det naturligt att dela upp tillvaron i "verksamhet" respektive "IT", där "IT" är "Den Andre" för att tala med Hegel och Husserl. Och hur mycket kostar inte oss "Den Andre"? Hur dyrt blir det med "Den Andres" alla knepiga krav? Bör vi inte hålla koll på det? Särredovisa "det där med data"?

Vad som händer i och med digitaliseringen är att datoriseringens logik blir norm. Det handlar inte längre om körningar som sker mitt i natten en gång i månaden, inläsning eller inknappning av innehållet i ett pappersdokument, eller samtal med en handläggare som tittar i sin terminal för att muntligen kunna återge vad som står där i ett personligt möte med en medborgare. Det handlar om att människor har tillgång till terminalerna dygnet runt i byxfickan, att de förväntar sig smidighet och korrekthet i allt och att fysiska begränsningar ska upplevas som helt borttrollade så länge som det gäller sådant som kan representeras digitalt.

"Transportation is waste" konstaterade Taiichi Ohno på femtiotalet, och pappersblanketter, kontanter, att behöva få tag i en handläggare för att fixa ett rutinärende, väntan på ett beslut om det är en algoritm som fattar beslutet, väntan på beskedet och väntan på en utbetalning: all sådan informationsförflyttning kan ses som onödig efterfrågan, fördyrande tillägg, och en konstlat försvårande process i ljuset av att det ju går att skapa detta sömlöst med hjälp av lättillgängliga digitala hjälpmedel.

Datorerna ska inte komma in från vänster för att effektivisera små bitar av ett förvaltningsflöde som slagits fast på förhand. Informationshantering behöver ses som i första hand digital om vi alls ska få någon god effekt av datorerna. Vi behöver utforma våra värdeflöden utifrån den smidigaste vägen givet dagens verktyg, och inte använda dagens verktyg för att imitera en karikatyr av gårdagens möjligheter.

I ljuset av det blir hela uppdelningen mellan "verksamhet" och "IT", mellan "beställare" och "uförare" skadlig. Det kräver ett omtag. En ny gemensam förståelse av vad syftet med IT-stöd är.

Som tur är finns det beprövade sätt att riva muren, sätt som används redan idag och som har använts i årtionden med goda resultat. Hela familjen av lean och agila metoder och smidig tjänsteförvaltning ger ett strukturerat sätt att åstadkomma precis detta. När vi leder systemutveckling på ett smidigt sätt fokuserar vi på syften, nyttor och effekter istället för på verktyg och att effektivisera det existerande (och ni som var med på digitaliseringsworkshopen i Almedalen 2016 fick höra mig prata om detta).

Vi arbetar med effektkartläggning och med små mätbara experiment i form av förändringar av befintliga tjänster och en fördjupad förståelse av behov och beteenden hos dem som vi försöker betjäna. Det handlar om att ha ett tjänsteperspektiv (vilka mänskliga behov är vi satta att möta oavsett om det sker via en skärm eller ej), ett livscykelperspektiv (hur säkerställer vi nyttohemtagningen kontinuerligt under hela den tid då behovet ska mötas av tjänsten), och ett integrerat synsätt (hur kan vi samverka på bästa sätt löpande för att möta alla dessa behov antingen vi är databasutvecklare, myndighetschefer, kundtjänstmedarbetare, verksjurister, apputvecklare, handläggare, webbprogrammerare).

Att i ljuset av det perspektivet försöka isolera IT-kostnader som en särskild post är förstås lite svårt men absolut inte omöjligt. Dock: är det hjälpsamt? Vad ska vi ha datat till? Det känns litegrann som att försöka särredovisa användningen av skiljetecken i myndighetens skriftliga kommunikation jämfört med användningen av siffror och bokstäver, istället för att titta på effekten av kommunikationen.

(Och en gång i tiden var skiljetecken en ny och konstig innovation som inte alls var integrerad i normalt skrivande.)

Ekonomiskt sett är det förstås nyttohemtagningen per tidsenhet och tusenlapp som är det intressanta nyckeltalet. Det är också den som rapporten från ESV i synnerhet önskar få se mer av. Men då är det också hela värdeflödet som ska mätas. När de effektivaste värdeflödena levereras av djupt integrerade grupper med en mix av kompetenser och verktyg är det verkligen frågan om fokus ska ligga på att försöka särskilja en viss sorts kostnader och försöka sig på att jämföra olika myndigheter med varandra utifrån den aspekten.

Man kan fråga sig: "Vad är en IT-kostnad?". Men kanske är en bättre fråga: "Vad ska jag med den informationen till?"

En reflektion om nyttohemtagning inom IT

"Effekthemtagning", eller som det också kallas: "nyttohemtagning", är ett begrepp som handlar om hur mycket goda effekter man får av en förändring i en verksamhet, till exempel av en tjänst. Man vill ju inte att en tjänst ska finnas till bara för sin egen skull, man vill ju att den ska leda till något man värdesätter.

Inom tjänsteutvecklingen, och i synnerhet inom systemutveckling, har frågan om nyttohemtagning blivit viktigare med åren. Det kostar mycket att genomföra förändringar i tjänster, inte minst i form av ledtider. Får vi rätt effekt av förändringen?

Jag är mycket angelägen om att myndigheter i Sverige ska fungera smidigt. De är bland de viktigaste verksamheterna vi har, och till skillnad från företag kan vi inte bara byta ut dem om de tappar stinget. Myndigheter hanterar ju dessutom ofta ärenden som är särskilt känsliga: ser till att brottslingar grips och vi får leva i trygghet, försvarar vårt oberoende, ger oss sjukersättning, utbildning och annat viktigt. Därför måste vi alla hjälpas åt så att våra myndigheter verkligen fungerar.

När jag har arbetat åt myndigheter med att hjälpa till med att införa agila metoder inom IT-utveckling har jag flera gånger stött på strukturella hinder för att få till smidighet. När jag grävt i det har jag hittat regler och direktiv som på olika sätt försvårar smidighet, fördyrar förändringarna, och minskar chansen att lyckas. Naturligtvis inte med avsikt men systemeffekter av regleringar tar ju inte hänsyn till regelmakarnas goda vilja.

Ekonomistyrningsverket (ESV) granskar och följer upp hur myndigheternas investerinar i IT-stöd genomförs. Det finns inom Myndighetssverige en stark önskan om större smidighet och att man använder digitaliseringens möjligheter bättre, så man är villig att satsa på IT. Men man kan konstatera att effekten av satsningarna inte alltid blir vad man har tänkt sig. Varför? Det är en av de saker som Ekonomistyrningsverket ska ta reda på.

Jag har börjat läsa igenom verkets rapporter nu, och det som slår mig är att det som rapporterna önskar delvis motverkas av precis det som rapporterna föreslår. Inte minst för att det man föreslår förutsätter IT-utveckling som bygger på projektarbete och på uppdelning mellan beställare och utförare. Det kan vara svårt att förklara vad som är problematiskt med andra människors förslag om dessa bygger på en tankemodell som på avgörande punkter helt skiljer sig från den man själv har. Men jag kan ju försöka.

Vi tar ett exempel. I rapporten Fördjupat it-kostnadsuppdrag – Delrapport 2: Kartläggning av it-kostnader finns ett resonemang runt just nyttohemtagning. Man har kartlagt hur stor andel av ett antal myndigheter som har en modell för nyttohemtagning och konstaterar att myndigheter generellt är svaga på detta. Men sedan fortsätter man

ESV anser att det inför projektstart är självklart att göra en kalkyl som även omfattar effekter av eller nyttan med projektet. Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem. En modell för nyttohemtagning som tillämpas konsekvent i alla projekt säkerställer att de effekter som projektet syftar till faktiskt fokuseras och realiseras.

Ett av skälen till att agila metoder alls finns är att vi i början av något antingen kan bestämma oss för vilka nyttor vi ska sträva emot, eller så bestämmer vi oss för vilken lösning vi ska ha, men vi kan aldrig garantera bägge. Det beror på att vi saknar kunskapen.i början. Vi står inte helt handfallna utan oftast brukar vi kunna skapa mer eller mindre välgrundade hypoteser. Men så bra kunskap att vi kan prognosticera vilken effekt en viss lösning kommer att få, det har vi inte. Inte ens efter en förstudie. Särskilt inte om det finns organisationspolitiska skäl att genomföra projektet,då kommer tillräckligt många att helt enkelt anta goda effekter. Kalkyler är väldigt enkla att utföra när man saknar data. Och prognoserna kan bara verifieras i efterhand.

Så vi kan bestämma oss för vilka effektmål vi vill uppnå, och vi kan utforma den initiala idén om lösningen i den riktningen, men vi kan inte se in i framtiden.

Den andra meningen får mig också att fundera: "Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem." Men efter ett genomfört projekt kan man inte säkerställa någonting alls. Då sitter man med det man fick i knäet. Förhoppningsvis kan det vara till nytta för någon, men det går liksom inte att göra om alla de vägval som gjorts under resans gång.

Om man läser den tredje meningen så att den syftar på att arbetet ska bedrivas på ett sådant sätt att vi löpande siktar mot effektmålen under hela utvecklingen, då går det att genomföra. Det är under resans gång man når insikt om vad som faktiskt hjälper oss att uppnå målen. Inte innan, och efteråt är det för sent.

Men för att förverkliga det behöver å andra sidan myndigheterna ge upp projekten (som flera myndigheter lyckligtvis är inne på att göra). Samtliga projektmodeller jag sett som faktiskt används bygger på idén att lösningen ska vara detaljerad på ett mycket tidigt stadium, och sedan styr man mot den fastslagna lösningen i enlighet med den på förhand utlagda planen. I många beställar/utförarmodeller försöker man dessutom aktivt förhindra nya insikter genom att strypa kommunikationen mellan beställare och utförare så att inte den ursprungliga idén (som togs fram när kunskapsnivån var som lägst) hotas.

Agila arbetssätt bygger istället på löpande omplanering och omdesign. Vi vet vilka effektmål vi ska styra på, och utifrån det kan vi designa en minimal lösning som vi förmodar leder till dessa. Den hypotesen prövas och kunskaperna vi får fram matas in i nästa iteration och så vidare. Planerings- och budgeteringstekniker anpassade för arbetssättet ser till att effekten per krona blir optimal i varje stund. Löpande effektkartläggning och andra tekniker ser till att vi filtrerar fram de bästa hypoteserna att bygga vidare på.

Mjukvara är kodifierad kunskap. Kunskap tas fram successivt i samspel mellan de som har pusselbitarna (verksamhet, IT, medborgarna). All erfarenhet av systemutveckling sedan 60-talet har pekat på att tätt samarbete mellan beställare och utförare där man tar fram lösningar löpande är det som snabbast och billigast tar en till målet. Det är det som måste vara vår mentala modell för hur systemutveckling ska bedrivas om vi verkligen vill säkerställa nyttohemtagning.

Do-be-do-be-do: Do and become!

"Agile" are so many things. From an outsider's perspective it is what some organizations and other collaborations are: They respond quickly as the society changes, they are fast to sense people's needs and invent a way of meeting them, and they seem to learn and evolve continuously. Together. Like a super-competent individual with a thousand arms and legs and eyes and ears and mouths.

So agile is definitely something you, as a group of people, can be together.

You get curious. You wonder what magic that lies behind all this. So you walk closer and tries to find things that you can imitate and copy. And you really see a lot of things.

People working in groups. Moving stickers on a wall. Organizing their decision making in a certain way. Handling budgets and projects in ways that you may be unaccustomed to, even removing them altogether and still maintain control. And you read descriptions of collections of things that you can do in your organization: SAFe, Scrum, XP, LeSS, DaD...

It seems like agile is something you can do.

So you tell people that this is what they should do. Do like this. Use this template. Standardize on this agile method. And you track them to see if they are doing as they are told.

But you notice that not all groups in the organization get the same result out of the things they do. Some seem to "get" it, and some don't. And among the groups that don't get it you see groups where they have deviated from the things you told them. So you correct them. No wonder you don't get the right results if people don't do as they are told!

But among the groups that seem to get it there are also groups that deviate from the method as it has been presented to them. They can even present even better result than groups that follow the method. So it seems like the magic doesn't reside within the methods, even if the methods play a crucial role for enabling agility.

The answer is that agile also is something that you think, feel and value. It is a mindset and a set of values. When we apply the methods, we uncover hidden things in our collaboration that blocks agility. The wisdom lies in seeing this when it happens and selecting the right tool from the toolboxes to handle it with.

That wisdom comes from an agile mindset and agile values. The groups that eventually develops agility from experimenting with agile methods all share a set of foundational values. The others typically don't.

As Simon Powers points out: the mindset is not easily seen, but it is definitely the factor that brings the most effect to your path to agility. It has the least visibility but the largest power.

So you can definitely become agile by doing agile, but it will not happen unless you also nurture the values so you start to think agile. That will bring understanding to the practice, and wisdom for people to select those agile tools that will benefit the whole.

When "doing agile": focus on effect!

So, we have an organization that works somewhat agile in places, maybe having a pretty decent level of agility in certain teams. We have a wish for more agility for the whole. Someone or something has led us to look at frameworks of methods that seem to be designed for creating agility in collaborations involving many persons, such as SAFe. Should we blindly progress and implement the collaboration techniques from the framework?

I suggest that we don't. While the techniques from SAFe or any other of the more known frameworks are all tested and tried ways of working that can do wonders, they are often presented as prescriptions with a general applicability, making silent assumptions about preconditions that might not hold true in our particular situation.

Each collaboration technique has a purpose. You want to see an organizational effect when doing things like a two days collaborative planning of 8-12 weeks of work for a group of teams (called "PI planning" in SAFe), or enforcing forecasting based on relative-size estimation with "ideal days" as the common unit, or any other technique. The thing is that it is the effect that in the end will give you more or less agility, not the behavior.

Think about it: is it possible for a group of people to behave in a certain way without achieving the effect? Absolutely. There may be situational factors that makes the behavior lead to other effects than what is anticipated.

Is it possible to attain the effect in more ways than through a certain behavior? Absolutely. And for certain situations, the current behavior may be a better way to achieve the effect than any other proposed alternative.

So it is possible to destroy something that works by enforcing a new behavior? Yes, and if the effect is already present it is unnecessary. We want organizational agility, not compliance.

So what I very much would like to see from any writer of material that tries to collect agile collaboration methods (myself included) is a lot more focus on what organizational effects you would like to see, what the preconditions are for the techniques to work as intended, how to assess the current situation, and how to apply the techniques in a safe way that don't break what is already working.

Basically, this is what we agile coaches do. And when talking to the people behind the frameworks you often notice that they have a very sensible approach to their own frameworks, both in terms of limitations and preconditions.

But that attitude isn't helpful when the specific wording of the framework is commanding and unconditional. The creator of the framework has the knowledge and expertise. People in organizations that need improvement in their collaborations are on the other hand insecure. There will be a bias towards doing exactly as it is written, and pointing out that there might be reasons to be careful with a certain technique in a certain situation will be met with suspicion. "The framework clearly states that it is necessary that we..."

The book Extreme Programming Explained is the star here. Kent Beck reasons about how and when the different techniques work, and gives a lot of examples on how to apply them in order to achieve the desired effect.

I believe that we would gain more from all frameworks and techniques if they presented themselves using that approach.

Flow is the general concept

One thing I often hear when I talk about creating effective service delivery or development and mentions its root in the Toyota Production System is that it would be a bad thing to use insights from manufacturing in other domains. There seems to be a fear that using ways of thinking from a production system automatically will make one treat everything and everyone as things to produce or cogs in a machinery. Seldom that criticism comes from people who has knowledge of what the thinking from Toyota actually says, though.

While it is true that some of the techniques that Toyota invented in the 50s and the 60s are only applicable in a manufacturing context, most of them are about general human concepts such as leadership, human collaboration, improvement of quality, and last but not least: flow.

Value is about meeting human needs. A value stream is what we call the organisation around the sum of all things that is done to capture and understand that need, and to finally meet it with a delivery of some sort. A smooth and fast slow is what we aim for since that would increase the value output per time unit.

Henry Ford optimized for flow when he designed the Highland Park factory that opened in 1912. Frederick Winslow Taylor optimized for flow when he wrote The Principles of Scientific Management in 1911. But even if the methods these persons enforced to increase flow such as predefined work divided into repetitive moments isn't suitable in any context outside of manufacturing (and maybe not even there), the aim for a steady output of value was not wrong but something that increased the income so much that they could pay the workers way more than the workers in other factories.

Flow has always been a core factor in successful service delivery: how do we handle a huge variation in demand and still provide adequate value to recipients? And what is true for service delivery tends to be true for product and service development as well. The Wright brothers solved the problems of creating a propelled heavier-than-air flying machine by a steady series of many experiments, and so has effective development work been conducted ever since, including within Toyota.

Lean thinking has from the beginning been about general concepts such as mathematical facts about collaboration systems in general and psychological facts about the human nature. The two pillars of lean is the continuous improvement of the flow, and respect for the fact that we people are as we are. William Deming's system of profound knowledge is based on the same two fundaments: flow (understanding systems and variation), and psychology (understanding knowledge and the human mind and behaviour).

If you are interested in general lean concepts I recommend This Is Lean, The Machine That Changed The World, Gemba Walks, Lean Thinking, and Toyota Kata. If you are interested in lean service delivery I recommend that you look at Vanguard by John Seddon. And if you want to implement lean thinking in knowledge work, I recommend that you check out Lean Software Development by Mary and Tom Poppendieck. For a thorough walkthrough of several economic principles that apply to product development using lean thinking, I recommend Flow by Don Reinertsen.

It s all about flow, not about factories and manufacturing.

How long should I have to wait?

After being asked to explain why I and others don't believe that a project is the best way to organize development of services that involves digital assets, I thought that I should try to do that. But I am not interested in bashing projects, but explain what requirements digital service development has on its control structure.

What would a reasonable control structure for development of digital services, a "project method" if you want to call it that, look like?

Services are about meeting human needs, and the question we have is how we can organize a collaboration, a system of people, to be able to meet those needs. As anyone who has had a need knows, one of the most important metric in service delivery from a recipient point of view is the "cycle time": How long should I have to wait from the moment someone has discovered my need until it is either met or rejected?

There are other metrics that are important as well, but the cycle time is special since it both has a strong economic impact and is an indicator of many other things in the system. The value of a delivered service can be translated into a cost of not having it delivered, a cost of delay, so it is fair to say that a suitable project method need to make it possible to optimize for short cycle times.

There are luckily a lot of ways discovered how to reduce cycle time, many that have been discovered by japanese industries in the 50s and 60s. One of the most important ways is to reduce the batch size of everything. Small work packages will flow faster through the system, while large batches increase the variation within the system and cause the system to underperform. So the project method should be able to handle several small batches of changes to the service in parallel rather than focusing on larger change.

The value is created when we meet human needs. It is not created when we spend time on activities. Activities are costs, while meeting needs is valuable. What activities that in the end will lead to value creation is something that unfolds during development of a service. It is impossible to say in a complex environment that we now know what sequence of activities that will lead to value creation in the end. We can guess, and at some point in time create a plan out of our guesswork, but the risk is high that the sequence of activities in our plan needs to be modified as more information unfolds during execution.

So what we need is a project method that allows for continuous replanning of the needed activities. The method needs to keep track how far we are from the goal of value creation, allow for continuous discovery of the best path to the goal, and helping the particiants in doing constant evaluation, discovery of needs and paths, and creation of new plans and forecasts, in a coordinated way.

Good coordination between people is hard to achieve. It takes time. Luckily, while the different changes we want to implement in our service really are separate pieces of work, the very domain where the value creation takes place stays the same. So it is possible to form stable collaborations of people who knows the domain both in a business sense and in a technical sense, and help them making their joint work effective. So the project method needs to support stable organizations and avoid temporary ones.

The discovery of needs within a domain often has a pretty stable rate. Especially when you are going digital. Most services need continuous development in order to stay fit for purpose and be competitive, so there is really no end state here. We will probably always find new needs to meet and will always need to find new ways of meeting them. So the project method should be able to go on forever. Managing constant funding and value generation.

Now, constant work in a constant organization doing continuous small batches of changes in order to meet a need in an exploratory fashion isn't what most project methods are designed for. There is in fact already a name for what I have described here: service life cycle management around value streams. That is a model for development that suits digitalization pretty well and gives the business the agility to experiment with fast feedback loops.

I don't suggest that we abandon projects, but that we realize that they are best suited for large changes that requires a temporary organization and where we actually can create those detailed project plans (often broken down into who should do what activities and exactly when) that the project methods prescribe. For going digital, I instead suggest what I have mentioned above.

First Draft of Module: Psychological Needs

I finally finished the first version of the module on psychological needs. This is a module that has grown out of the segment on group development in the Scrum Master course and when I coach agile coaches. I have turned more and more into describing the individual psychological factors that affects us when we try to grow together as a group.

This module explores some basic facts about the human need to feel safe, free, and good (doing good and being good at it); both alone and within a group. It presents a couple of simple models that helps us navigate our understanding of how we work on the inside. No infographics yet, but I am sure that I will create some in time.

What do you think? Read it here: documentation-psychological-needs.pdf

Kostnads-"paradoxen"

Den amerikanske leanpionjären, kvalitetsgurun och ledningstänkaren William Deming formulerade sig gång på gång ungefär så här:

Om du fokuserar på kostnadssänkningar så kommer kostnaderna att öka. Om du fokuserar på kvalitetsförbättringar så kommer kostnaderna att sjunka.

Det här kan upplevas som kontraintuitivt och paradoxalt av dem som lärt sig att låg kostnad och kvalitet är två kommunicerande kärl. Tron är ofta att ju mer man satsar på kvalitet desto dyrare blir produkten, och vice versa.

Men det är inte Demings ord som är paradoxala. Det är folks intuition runt kostnad och kvalitet som ofta är fel.

När folk försöker styra verksamheter på toppnivå med hjälp av numeriska utfall är risken oerhört stor att de misslyckas. Det är för att den verkliga relationen mellan siffrorna i flera fall är okänd. Och om man har låg förståelse för den egna strukturen, hur den egna organisationen faktiskt fungerar och skapar värde, så kan man inte använda siffrorna på något produktivt sätt i sitt beslutsfattande. Man saknar förmåga att agera bra på dem.

Det är därför som grunden i metodiskt kvalitetsarbete, som Deming lärde ut till japanska bolag efter Andra världskriget och som blev ett fundament för det vi idag kallar "lean", handlar om att få en strukturell förståelse för det egna systemet. Innan vi förstår hur värde skapas så är alla frågor om hur mycket? värdelösa.

Det finns i princip två sätt att minska kostnaden per skapad värdefullhet (produkt eller tjänstetillfälle eller vad det nu är för ett värde ni skapar):

1. Försök skapa lika många värdefullheter till en mindre totalkostnad.
2. Försök skapa fler värdefullheter till samma totalkostnad.

I alldeles för många kalkylark framställs dessa två alternativ som likvärdiga: priset per värdefullhet sjunker. Men medan det är svårt och riskabelt att försöka sig på det första alternativet (sänka kostnader) så är den ökade produktiviteten ofta enklare att åstadkomma snabbare. Kostnads"paradoxen" igen! Vad kommer det sig att jag inte fritt kan välja strategi 1) eller strategi 2)?

Svaret ligger i hur värde faktiskt skapas, strukturellt. Om värde skapas på ett enkelt sätt, kanske av enstaka individer som kräver få interaktioner med varandra eller med maskiner för att kunna möta ett mänskligt behov, då är förhållandet mellan kostnad och värde lättöverskådligt. Slutar folk sjunker både kostnad och produktionsvolym.

Men få värdeskapanden är linjära. Värde skapas ofta i komplexa samspel, och ju mer kostnadseffektivisering vi utsatt dem för desto komplexare är de. Inte sällan även mycket känsliga för variation.

Om ett samspel inte utsätts för mer variation än det kan hantera så kommer samspelet att nå ett naturligt optimum där det skapar värde i en stabil och uthållig takt. Om systemet inte är hundraprocentigt utjämnat så kommer man att se bubblor av "överkapacitet" på sina ställen. Det kan vara en vilopaus, ett extra lager med grejer, en administratör som gör enkla administrativa sysslor och så vidare. För den som saknar förståelse för systemet ser dessa bubblor ut som effektiviseringsmöjligheter. Och det är här problemen börjar.

Ibland är det verkligen effektiviseringsmöjligheter. Men ofta så är det det inte fråga om någon egentlig överkapacitet utan en vital del i systemet som hanterar svängningar och gör att utflödet kan ligga stabilt. Bara om man följer den felaktiga intutionen att systemets effektivitet är summan av effektiviteten i dess delar så är man säker på att lokal överkapacitet alltid är del i den globala överkapaciteten och kan tas bort. Det inledande kapitlet i "Detta är lean" förklarar det här utmärkt, eller så googlar ni efter "Niklas Modig effektivitetsparadoxen".

Men oavsett om den observerade överkapaciteten verkligen är en överkapacitet eller inte, så kommer själva reduktionen, själva akten att ta bort den, att påverka samspelet negativt. Det blir ett avbrott. Samspelet måste omorientera sig. Vi får ett produktivitetstapp. Kanske återhämtar vi oss, men det är inte säkert.

De varianser som "överkapaciteten" buffrade för kommer att dyka upp på andra ställen, ofta förstärkta om vi inte observerat dem och planerat hantera dem. Och då orsakar de extra oförutsedda kostnader, förutom att de kan minska produktiviteten genom att blockera värdeskapandet, och därmed öka kostnaden per enhet kraftigt. Den här effekten förstärks ofta av att samma oförstånd som dragit igång "besparingen" i det här läget drabbas av panik när det inte gått som man tänkt sig och därför börjar göra mer av samma slags destruktiva åtgärder.

Det är sådana scenarion som inspirerat till talesättet: fokusera på kostadssänkningar och din kostnad kommer att öka. Kostnadssänkningar tar i sig inte hänsyn till systemet. De är ofta lokala, men systemet har ju en global effektivitet som kommer att påverkas.

Strategi 2) fungerar bättre på grund av den förbättringsprocess man behöver införa för att genomdriva den. Ska man inom en befintlig struktur med kända ramar hitta mer effektivt värdeskapande behöver man se vari värdeskapandet består så att man kan rensa bort allt onödigt. En av onödigheterna är defekter som beror på "bristande kvalitet" (eller som vi säger: okontrollerad variation). Det är så som metodisk strävan efter bättre kvalitet inom givna kostnadsramar driver den systemiska förbättringen av produktiviteten som Deming pratar om.

Och sanningen är att den som väljer strategi 1) - införa resursminskning på flera ställen i samspelet, också måste ta till strategi 2) - produktivitetsökning inom givna ramar, för att lyckas. Besparingsåtgärden åsamkar skada på den befintliga strukturen. För att kunna komma igen krävs att man hittar tillbaks till värdeskapandet och sedan också förbättrar.

Det är här som många tar miste. De tror att strategi 1) och 2) är likvärdiga, och förstår inte att det är strategi 2) som åstadkommer själva förbättringen. Strategi 1) är ingen strategi, det är bara att bestämma sig för inom vilken ram förbättringen ska ske. Förbättringen som sådan måste komma till, annars går det inte.

Så alla måste till sist välja strategi 2) ändå. Och då gör många nästa misstag: att man inte förstår att i ett komplext samspel är det personerna som befinner sig på golvet närmast värdeskapandet som har bäst förmåga att förbättra det, om de ges verktygen och förutsättningarna. Att ge "golvet makten" fungerar inte, men att ge golvet verktygen och makten, det fungerar. Mycket bra till och med. Där finns hela verktygslådan från lean och agila metoder att ta till.

Men ofta krävs det att alla i ledande ställning först och främst förstår att den här kostnads-"paradoxen" inte är någon paradox, utan att deras fokus bör vara att ständigt förbättra värdeskapandet inom organisationen, så snart man har bestämt sig för vilken kostnadskostym som verkar vara rimlig att agera inom.

ASLA - The Domain and The Stewards

In order to support flow and effectiveness, people in the different functions need to have a common understanding of what the collaboration do and why it does it. No matter if you are operating the service or designing changes in it, you need to see things in about the same way.

This can be done by looking at the domain.

The domain is the arena where all of the services that your collaboration provides play out. It is like a stage in a play. There are characters (user and providers of the service) that have needs and wants and direction, and there are certain limits that everybody relates to.

In practice, the collaboration can and should form a group, a Steward Function, consisting of people that can represent all relevant aspects of the collaboration's services: market needs, business needs, technical needs et cetera. The Steward Function takes full responsibility for

• The full life cycle
• of all of the collaboration's services

Therefore, it is the responsibility of the Steward Function to maintain the domain: decide what facts about it that should be considered canonical and continuously incorporate new insights about the needs and how the collaboration should try to meet.

The domain can be maintained in a number of ways, but a common form is for the Steward Function to be the owner of a set of documents that tries to describe the domain in a clear and relevant way. The documents may vary but often includes:

• A persona gallery that describes key user groups and stakeholders. Also anti-personas: the groups we are NOT designing the service for.
• An information model with a domain dictionary that models the key terms and definitions together with their relationships, cardinalities, and main attributes.
• A list of important business rules that affects the behaviour in the domain.
• Descriptions of the main ways for the personas to create value: important flows and journeys.

New ways of modeling domains are being invented all the time and the Steward Function explores what they feel should be the best way for them to maintain it.

ALMA - Sponsorship

We have an intuitive notion about leadership and dominance that affects how organizations traditionally have been governed. While coordination is necessary when many people want to be productive together, relying on our primitive intuitions are in many cases not the most effective way. The issue of governance and management need to be addressed in a more thoughtful manner.

In ALMA we regard governance and management just as a bunch of Capabilities (realized by Processes). Since the Capabilities needed for good governance have a special impact when it comes to the design and the performance of the organization, we consider them with extra care and group them under the overarching theme of sponsorship.

Under the umbrella of sponsorship we group all Capabilities (and Processes) that provides

Direction — Saying that we should meet the needs of people is a no-brainer. Saying what needs to meet is something that requires a thoughtful decision. Pointing out the purpose of the collaboration and in what direction everyone should go is part of the sponsorship.

Prioritization — If you are experiencing conflicting priorities, for instance if you have encountered a bottleneck in the organization's ability to deliver, you need clear direction on how to prioritize. Either directly where you bring up the issue to a board or an individual, or indirectly via rules - general or more specific - that you can rely on.

Approval — If you aren't sure that an agreement is within the line of what the organization needs, or if you feel that an agreement between parties isn't being upheld, you need to escalate this to someone who can take a look at the whole and decide what to do, from a holistic point of view.

Resource allocation — In order to do something you need tools, time, and friends. In an organization, these three have a cost (at least the cost of not being used elsewhere), so there is a need for a mechanism that can make these kind of allocation decisions in a fruitful way.

The responsibility of the Functions that provides sponsorship Capabilities is to guarantee that what they do is in line with the purpose and limits of the whole organization. Functions that provides sponsorship Capabilities should be aware that when they are needed, they are needed quickly because something that no one else can solve is currently blocking the value creation. This is why many lean and agile organizations tries to distribute the sponsorship Capabilities to many Functions by extensive delegation. It is also why many of them also have instituted rules that states that no issue can be lying unsolved more than 24-48 hours before it is escalated to the next higher hierarchical level.

A common way of organizing this in effective operations that handle life-and-death situations (like in the military or at hospitals) is to always have an appointed person in charge of sponsorship decisions at all times, and make sure that this person has the necessary backup when needed.

Remember that no matter if you are a private or public company, or if you are a governmental or non-governmental non-profit, there is always an underlying power structure! Things and time are owned by people, as individuals or in a collaboration, and law-makers have connected certain responsibilities and rights to this ownership. ALMA opens up for delegation, collective decision making, and other forms of distributed responsibility. Note that this is done in order to create effective power structures, not to ignore the issue of power!

A "manager" in a more traditional sense would be a Function consisting of a single individual who are responsible of providing all these sponsorship Capabilities. It is an observation that in a complex environment the burden of all the sponsorship responsibilities is too heavy for a single individual to carry. The processes need expertise knowledge in many areas. By regarding them as Capabilities that can be provided by many Functions, where each Function is made uf of many individuals, ALMA opens up for the possibility to create a more effective leadership that won't burn out people.

There are reasons to abandon the concept of "managers", but management will always be needed!

ALMA - Services, Functions, Processes and Capabilities

The distinction between services, functions, capabilities and processes is borrowed into ALMA from other service management frameworks, but with an agile and lean twist. The insight that capabilities of the different collaborations in the organization are central are borrowed from the emergent practices of capability mapping and agile enterprise architecture.

A Service is something that a person would happily use if we were to offer it on its own. "Fork Delivery" could be a Service on its own, but in the context of a lunch restaurant people wouldn't be happy if they didn't also get the plate, the food, spoons and knives and chop sticks when needed, and so on. "Fork Delivery" is therefore more likely a part of the Service "Lunch Delivery", and not something valuable on its own. A Service meets a human need all the way from the notion of the need to delivery.

A Process is the actual way of providing the part of a Service. When we perform our Processes and measure them and design improvements for them, it is important that we consider the whole Service and the human need it is supposed to meet. Else we run into a huge risk for sub-optimization which breaks the principle of flow.

A Capability is what a part of an organization needs to have in order to provide their part of the Service. It is distinct from Processes in that a Process defines exactly how a part of a Service should be done. But defining a Service in terms of exactly how it is delivered will be against the root principle of improvement. We need to be able to investigate different ways of providing a Service, and as long as we provide the needed Capability, we should be free to experiment how to do it.

"Fork Delivery" would be a Capability needed to provide the Service "Lunch Delivery", and we can experiment how to optimize the fork delivery in numerous ways. The larger investigation whether we actually need forks at all must also be possible to do in the name of improvement, but that would require that many more people would be involved in the experiment. In the small, within the limits of a Capability, people should be free to experiment without having to ask.

A Function is an organizational entity: a group of people who work together performing one or more Processes. An individual can be a part of several Functions but be aware that this can lead to priority conflicts within the individual, unevenness in their work, and overburden. People need to have a home. It is better for one person to belong to a single Function.

A Function can be represented in another Function. People from one Function then participates in the other Function's work. This is great for Sponsorship Functions (management and governance) where limited resources have to be distributed and priorities be made. By forming the governance Function by asking the Functions that are closer to the gemba for representatives, we ensure that the decisions made by the Sponsorship function is more in line with reality (the principle of empiricism at work).

By handling governance in this way we also combat the misconception of the organization as a hierarchy and lower the risk that it will be misused as an arena for persons to play games of political power. There is a power structure in place that should be recognized and designed in an effective way, but the presence of a power structure doesn't mean that forming hierarchies is a good way of governing it.

A Function may handle one or many Processes. A Service may be delivered by using only one Capacity, performing only one Process. But it is more common that the Service will require many Capablities, and therefore potentially many Functions in collaboration. They really must cooperate well in both designing and operating the Service, defining the Capabilities and their interaction.

It is often efficient when a Service is delivered by Capabilities and Processes that all can be performed within one Function. The Function can then experiment with improving the whole Service. It is resilient if many Functions can deliver the same Service in parallel so that more needs can be met faster. It is seldom efficient but brittle if a Function consists of only one person. Dependency on single individuals make the organization vulnerable. People need to have peers.

ALMA -The Core Principles

The core principles of ALMA are

Sustainability. As long as a service is useful it should sustain. That means that everybody involved in the service needs to continuously improve its sustainability. This includes being sustainable environmentally, mechanically, economically, and humane in respecting the limits of people. This combats the disease of overburden (muri), which is a source of much waste but often disguised as value ("Come on, of course you can push it a little harder!").

Flow. Smooth out unevenness, batches, variations, waiting, where it can be done without breaking the first principle. Unnecessary variation that can be removed without making the service less valuable should be removed by clever inventions. Variation that is caused by the inherent variability in the human nature shouldn't be removed but handled, by clever inventions. This combats the disease of unevenness (mura).

Effectiveness. Do the right thing. Don't do the wrong thing or the useless thing. Don't try to make more of what is not the right thing. What is good enough for now and safe enough to try? Do that and proceed. This combats the disease of wasteful actions (muda). Remove waste, but not so that you introduce unnecessary unevenness or overburden.

These three principles will result in a truly efficient flow, but efficiency is not a core principle of ASLA. This is because when you aim for efficiency, you often fall in the trap of suboptimization by trying to maximize resource utilization in all parts of the flow. This causes overburden on people and tools, work waiting in queues which is a terrible waste, overproduction in parts of the flow which makes other parts of the flow instable, and in numerous other ways worsening the output while increasing the cost per item.

In order to sustain an effective flow, you need to build upon the foundation of the gemba, the floor, the place where value is created and waste is discovered and removed. The foundation is created as we saw in the section about the gemba from two other principles:

Transparency. Overburden, unevenness, and waste always hides. By making things visible, we enable action built upon empiricism (real data and true understanding), and so supports

Empowerment. It is the people who are doing the work that should decide on how the work is done. This means that they need to be enabled, not only by transparency, but also by given the tools and abilities to act in a fruitful way, and given the permission to do so.

So: try to improve the flow in a sustainable way by looking at the whole, work together with who you are and what you have got, stop doing what is not valuable, and respect the principle of the gemba: make everything transparent and empower people to act for the better upon what they see.