Delaktighet

Delaktighet och medarbetarengagemang på Castra

Konsultbranschen är i ständig förändring och dagens konsulter har höga krav på sina arbetsgivare. De kräver frihet, flexibilitet och möjlighet att påverka. Dagens konsultbolag behöver vara föränderliga, snabbfotade och tillmötesgå branchens förändringar och konsulters krav. På Castra tror vi på ett företag där framgång kommer från delaktighet, medarbetarengagemang och arbetsglädje. 

För att främja engagemang och delaktighet arbetar vi på Castra bland annat med delägarskap, advisory board och projektgrupper. Vi tycker det är viktigt att man som medarbetare har möjlighet att förverkliga sina idéer och tankar, både kring ens eget dagliga arbete men också hur bolaget ska drivas och verksamma. Genom delägarskap, advisory board och projektgrupper har våra medarbetare stora möjligheter att påverka bolagets utveckling och forma den arbetsplats de vill vara en del av.

Advisory board

Vi är ett team som arbetar tillsammans mot ett gemensamt mål och alla har en viktig del i att nå målet. Vi ser det som en självklarhet att involvera medarbetare i arbetet att ta fram värderingar och att arbeta med organisationens strategi för att öka delaktighet. Därför har varje regionbolag en styrelse eller advisory board som fungerar som ett styrorgan i bolaget. 

Alla medarbetare erbjuds möjligheten att sitta med i bolagets advisory board och här beslutar medlemmarna om allt som har med bolagets välmående och utveckling att göra. Här diskuteras större frågor så som företagets strategiska arbete, mål och fokusområden. Här tar medarbetarna ett kliv framåt och uttrycker fritt sina önskemål och åsikter för företaget i stort och hur vi ska jobba framåt. 

Delägarskap

Delägarskap är ytterligare ett sätt att tillmötesgå konsulternas krav på medverkan och frihet. Castra är ett entreprenörsdrivet företag med korta beslutsvägar där alla våra medarbetare har möjlighet till delägande från första dagen. Som delägare har den som önskar stor möjlighet att vara med och påverka verksamheten och beslut gällande strategisk inriktning, långsiktiga mål och den dagliga verksamheten. Delägarskapet bidrar till ett härligt, engagerat företag som vi bygger tillsammans med medarbetarna. Gemensamt formar vi den arbetsplats vi vill vara en del av och tillsammans skapar vi ett roligt och givande arbetsklimat. 

Projektgrupper

Castra har ett antal interna projektgrupper som arbetar med specifika frågor. Många projektgrupper är självinitierade av våra medarbetare och arbetar med utveckling av frågor de själva tycker är intressanta. Just nu har vi projektgrupper som bland annat arbetar med utvecklingen av kulturarbetet, hur Castra ska bli en mer attraktiv arbetsgivare för kvinnor samt varumärke och marknadsföring. Konsulterna som dagligen är ute hos uppdragsgivarna bidrar med ett annat perspektiv och kan komma med värdefull input för hur marknaden ser ut, vad som fungerar och inte och hur vi kan jobba framåt i dessa frågor. 

Delaktighet och medarbetarengagemang är en tung grundpelare i hur Castra arbetar. Vi ser det som självklart att bolaget byggs tillsammans med våra medarbetare. Castra är ett bolag där alla respekteras och åsikter och input faktiskt ageras på.

Läs mer om Castra här.
Spana in våra lediga tjänster här.

4 TYPES OF DOCUMENTATION

– towards Pragmatic Knowledge representation

There is a lot of confusion caused by the Agile manifesto simplification regarding “documentation”. I will address this and also highlight a concept you just HAVE TO learn and know about (if you did not already), Parsimony!

Parsimony

Parsimony is also called ”Occam’s razor”. It means that given two equally accurate answers, science prefers the simpler.

Einstein’s classic quote is a bit false as he was AGAINST simplifying to the point that laypersons might understand –  if it were simple enough to understand, it wouldn’t be a discovery worth lauding!

The full quote is in fact:

quote_1

and

quote_2

It is sad that the use of ”make it simple” has been ”stupefied” to a degree where we can actually choose an apple instead of a full dinner plate, stating that it is simplification without reflecting on parsimony.

The second part of the famous quotes from both Einstein and DaVinci which is so often left out or ”forgotten”, means that we can not compare things regarding ”simplicity” if they do not have the same effect and context.

BLOGG - 4 types of documentation – IMG 0_jpg

The act of simplifying is about transformation: to start with a complex statement or representation and to make it more naturally understood and remembered. BUT the transformation result must maintain ALL the needed complexity. Any simplification risk compromising the “truth and the real problem”, and along with the validity of the statement can be completely lost!

In software development, ”simplify” often result in ”stupidify”, as we lose knowledge and/or represent the knowledge in an ambiguous way, even if we use nice colours and happy smiling hand-drawn cartoons.

Remember: The complex does not disappear if we hug each other or hold hands in a ring. The result of a stupid simplification will often lead to stupid decisions!

Comprehensive documentation

So what does ”comprehensive documentation” really mean. If you do not understand that there are different TYPES of documentation with different needs depending on the situation and the involved stakeholders, then read the quote by William Blake: ”if you generalize, you are an idiot!”

BLOGG - 4 types of documentation – IMG 1_jpg

Too much of the WRONG TYPE of documentation is BAD, but not enough documentation of some other type of knowledge representation can be even worse and extremely stupid!

In fact, if a ”map” helps you to understand and get from ”A to B” faster and is more ”economically sound”, then ”draw the f…ng map!”…

draw the fucking map

To talk about the weather does not solve the problem. To talk about all the details in a blueprint without having a blueprint is just stupid!
Talk ABOUT the blueprint (and do the updates in the ”map”).
So which types of documentation should we consider to become smarter?

The 4 types of Knowledge representation

We need effective and efficient communication in Agile methods because of its focus on short feedback cycles and personal interactivity.  We should not only talk but rather “talk about” something i.e. an important knowledge representation that can be read at any time, can be updated and changed iteratively (=“update the map with input from the reality”).

We should Identify the need for a “keeping knowledge” longer than “the timespan of the mechanical wave that results from the back and forth vibration of the particles of the air” (i.e. talk) and give a Rationale (logical explanation) why it is important to “store” the information, for whom, and what can happen if we do not represent the talk with a more persistent representation (= the possible impact)

BLOGG - 4 types of documentation – IMG 2

It is often so that specific domains, products, project contexts require certain information in a specific format or representation for specific regulators to follow the law. And some information has a lasting value beyond the initial development effort.

We need to be able to predict which knowledge will be needed in the future. In those cases (and they are many!) verbal communication is not enough semantically powerful, and “only talk” often lead to inefficient, misleading communication and different interpretations where the “internal models” do not match at all … But the participants are not even aware before it is too late, and bad decisions are already made.

Representing knowledge (e.g. writing, drawing/modelling) is also necessary as a means to improve and support the thought processes and the “mental model” for understanding. The improved thinking and understanding will last even if the documents created, is “thrown away” and not stored or updated, as the process of “drawing the map” forces people to ask questions that enhance understanding and often creates a new way of thinking!

BLOGG - 4 types of documentation – IMG 3

If we use the “right type of map” it will make us smarter!  We will also get a better understanding and updated thinking when we communicate using “a map” (= Knowledge Representation) than without!

However, we need to become experts in identifying the important Knowledge that we need to represent in a smart and persistent way.

A good way to start is to NOT only talk about “documentation” as an Agile zealot, but classify all possible documents according to the 4 types of Knowledge representation as shown above.
We should definitely ask ourselves if a “living product/project backlog” is sufficient. For real!

Legally Necessary Documentation 

Certain product- and project contexts demand certain information in a specific format for a set of identified regulators. Just to follow the law!
It means that the specific Knowledge Representations MUST be a part of the product, and without it, we will be breaking a set of laws and standards! In other words, we MUST create, read and update these documents to obtain legal approval for the product/project work we are doing.

For example, building a dog house or a simple website is not the same thing as building systems (both processes and automatic systems!) for nuclear plants or in the health care sector. The lack of the correct set of documentation can thus have a huge on the company as a whole…yeas I am thinking about Boeing in the avionics sector.

Preservation Documentation 

We need to know which information that has a lasting value beyond the initial development effort.

We should ask ourselves what is the “shared archive for the team, product and organization”?

Can we live with the risk of being dependent on the memory capacity of the individual team members and “the risk of someone forgetting”, which is a reality when dealing with tacit knowledge, only in the head of the people involved and those who happened to be present in the set of meeting in which the concepts were “discussed”…

How you come across situations like: “why did we decide to implement this?”.
In many cases, we gain time and are agile by keeping some sort of representation of discussions about decisions “outside the head”. If we do not all have the same idea on the goals that the system was built to achieve or which use cases that are the most important for the automatic system and the manual process, then we will probably have some major problems in the future (or giving someone else an impossible task). We need to save decisions made during development on why we have included or excluded certain functionalities, constraints and why we have focused on certain quality attribute values and not cared about others. Or why we did not involve stakeholders from group X, but we spent a lot of time with stakeholders representing domain A and B…

It is often the team itself that identify what they want to preserve & “formally remember”.

To be agile is to be smart!...do not be agile stupid and “throw away” a “map” that can help you to understand and do your job faster and more effectively as well as enhance communication. To throw away important knowledge because some “manifesto guy tells you to simplify” is like not using a hammer while building with wood and nails. Just stupid.
If you need requirements and test cases for specific parts of the system, just represent that knowledge!

Documentation for Communication 

One size does NOT fit all, and direct verbal communication is NOT always the best!

Verbal communication is often not enough semantically powerful… which can lead to inefficient, misleading communication and different interpretations, “internal models” impossible to validate, etc…

There are in fact a lot of communication challenges related to the verbal focus:

When dealing with distributed teams and when you have time restrictions for stakeholders, it is not easy to “just talk”. We often have language barriers and cultural differences that can complicate already complex information to unsurmountable mountains. Talking about a complex “map” is almost impossible!

Do the test: explain a route in a country you do not know only using words. And then try to do the same but also using a map. Talking ABOUT the “map” is a sure way to communicate better!

To re-read and iteratively update a “conversation”, you have to have an eidetic memory, for most people it is impossible. Using a diagram to represent a complicated algorithm is not only smart, but it also guarantees iterations and enhancements as the diagram will always be open to enhancements (“let’s continue where we left off”). The conversational situation will NEVER be found again and can not be “re-read” by external parties that were not present in the moment.

We should also be open and agile for the fact that a lot of stakeholders prefer written documents, visual diagrams and info graphs, rather than just meetings, talk or reading the source code

We should never document for the sake of documenting, but IF communication documentation is successful then we should definitely archive the knowledge representation.
Everything else would be stupid!” …and we do not want to be agile stupid, do we?

Documentation for Thinking!

One of the most important uses of representation is to improve and support thinking & understanding. We want to represent knowledge (e.g. writing, drawing/modelling to enhance our thought processes and the “mental models” and to be able to do that not only individually but also collaborate on a “collective mental model”

think

The happy part is that improved thinking and understanding will last even if the knowledge representation created for the specific problem is “thrown away” and not stored or updated!

The process of “drawing the map” forces people to ask questions that enhance the understanding and often creates a new way of thinking! AND it is possible to SHARE!

A common example is to stop talking or textually writing a use case, and instead of creating an activity diagram of the use case flow. This forces the talker/writer to THINK about concrete interactions between the system and the actors including, exceptions and alternative scenarios etc..

It means that the Activity diagram is specific Knowledge representation tool to store the knowledge and understanding of a system. Talking about the system via the activity diagram enhance the communication by the power of the syntax and semantics.
And it has nothing to do with drawing funny cartoons on flip charts.

Be happy. Be smart. Don’t be agile stupid!

To get more inspiration:
Read some of the excellent IREB documents from FL, AL modelling and the RE@Agile courses.

Stefan_BLOGG_bild_text_EEKENULV_3

Good Enough Is Good Enough!

More is More..

En av världens mest omtalade gitarrhjälte genom tiderna är svensk. Yngwie Malmsteen är arketypen för en Rockstjärna med stort R. Utanför den stora villan i Miami, radar han upp sin samling av Ferrari bilar och givetvis samlar han på Rolexklockor. Senaste uppgiften är att han har mer än 517 Rolex klockor.

More is More_diagram_with_yngwie_800x600

“I didn’t just want to play it safe…people kept on telling me to slow down, like: “Hey slow down… remember that less is more!”but how can that be? How can less be more?!! It’s impossible! More is more”
Yngwie J. Malmsteen

Yngwie inspireras av klassiska kompositörer som Paganini och Bach och har alltid kopierat duktiga gitarrister för att utveckla sin egen teknik. Han har en grym drivkraft att hela tiden bli bättre inom sitt område. I hans tolkning av världen, att ”more is more” driver honom hela tiden att förbättra sig genom att bli snabbare, mer virtuos och mer komplett som gitarrist.  Det är intressant att Yngwie är som störst i länder som Japan som har en kulturell fascination för teknisk perfektion.  Allt japanerna gör drivs av en strävan efter perfektion, förbättring och fokuserat mästerskap.
Det gäller att inte rädas det som är svårt och stort och omfattande. Att inse att man kanske måste ägna hela livet åt fokuserad och medveten förbättring för att kunna uppnå mästerskap. I det sammanhanget är ”more is more” en passande devis.

Se gärna det klassiska Yngwie-clipet, som inspirerade mig att skriva denna blogg: http://www.youtube.com/watch?v=QHZ48AE3TOI

More is less

Barry Schwartz är professor i Social Theory and Social Action vid Swarthmore College.  I en av sina senaste böcker ifrågasätter han det klassiska antagandet att ett större utbud och ökad valfrihet ger ett bättre liv.
Den traditionella konsekvenskedjan är enligt följande:
maximerat antal möjliga val à maximerad frihet à maximerad välfärd à ”ett bättre liv”
Enligt denna logik innebär det att om man kan välja från ett större utbud, så upplever man större frihet och därmed en ökad välfärd.
More is Less_diagram_with_Barry_Schwartz_800x600

Men Schwarts argumenterar för att en medveten begränsning av antalet valmöjlighet faktiskt kan minska stress, förvirring och ångest över att man borde valt något annat. Det stora antalet val gör att man i varje stund har så många möjligheter att man inte är närvarande och nöjd med det man har; ”allt ser så fantastiskt ut, det är bara en tidsfråga innan man blir missnöjd”.
I dag har ansvaret för produkten flyttat över från tillverkaren till konsumenten, eftersom om man köper en telefon som man inte giller eller som inte fungerar perfekt, kan man skylla på den dåliga produkten, men egentligen är det vårt eget fel att vi inte valde något annat. De flesta har svårt att hantera dagens enorma utbud av alla produktvarianter och vi tvingas lägga ner mer och mer tid på att jämföra produkter och att gå igenom val- och beslutsprocesser. Den enorma stress det innebär gör att friheten inte upplevs som frihet och vi njuter inte av välfärden, utan oroar oss för att vi ”valt fel”.
Det är lätt att glida över till vårt svenska ordspråk, att ”man ser inte skogen för all träden”.
Barry Schwartz sätter ljuset på ett flertal antaganden och konstaterar att för individen kan MORE vara LESS; More is Less.

 

Less is More

Arkitekten Ludwig Mies van der Rohe var en av pionjärerna inom den moderna arkitekturen. Han var inspirerad av dikten om Andrea del Sarto, ”The Faultless Painter”, av Robert Browning från 1855, där frasen ”less is more” utgör en nyckelfras. Mies strävade efter att skapa en arkitektur med minimal struktur för att ge plats för öppna ytor med mycket rymd och ljus. Han reducerade antalet detaljer för att förhöja helhetsintrycket och skapa en enkel och direkt upplevelse utan att en massa plottriga detaljer. Han ansåg att ”God is in the details”, vilket innebar att han propagerade för att välja detaljerna med omsorg, och att endast välja ut de som bäst representerade själva tanken med helheten.

Less is More_diagram_Ludwig_Mies_van_der_Rohe_800x600

 

Less is Less

”Less is Less” kan i min världsbild av arbete med krav i projekt och organisationer, associeras med en förbannad intressent som inte fått det han ville ha, eller det som han trodde att han ville ha.

Less is Less_diagram_the_angry_customer_800x600

Känslan av ”less is less” är obehaglig; som att bli lurad på konfekten, som att sitta och lyssna på en ”rolig historia” som inte har en rolig poäng. Vi kan uppleva det när projekt omprioriterats och kapats i ändarna så till den grad att ingen nytta blev kvar. Eller när bombastiska prototyper lovat fantastiska features i lyxförpackning, och leveransen sedan har mindre innehåll, är fulare och inte alls ger någon känsla av förbättring.

 

GEIGE!

I mitten av båda axlarnas Less och More, har vi en skärningspunkt! Alla uttrycken ovan kan i sitt sammanhang och med förståelse av respektive situation och kontext, ha sitt berättigande och kännas naturliga. Men vad vi egentligen bör stäva efter är givetvis en kombination av alla fyra!
Yngwies passion och glädjefulla virtuositet, Barry Schwartz insikter om paradoxala följdeffekter,  Mies tydliga och förädlade renhet samt behovet av ett riktigt innehåll som ger nytta, kan alla sammanfattas till: Good Enough is Good Enough! (GEIGE!)
Genom att tänka på alla riktningarna samtidigt kan vi hitta ett lagom, som inte lämnar någon riktning besviken.

GEIGE_800x600

 

Stefan_BLOGG_bild_text_EEKENULV_3

 

Visual thinking & understanding in BA / RE / ARCH practices used in industry product development

 

tacit knowledge calibration

Tacit knowledge calibration

The concept of visual management  and visual feedback is one of the pillars in Lean Product development for communication of status, progress, prognosis, and planning, e.g. tracking of work identified, ongoing and done in the development teams via kanban-like boards as well as the progress according to existing plan, expectations and what is actually delivered.

The leaders of the development teams are more interested in the use of resources and the amount of work to be done, so future work can be planned accordingly.
The downstream stakeholders like sales, manufacturing, marketing etc.. also need to SEE how the projects are doing so they can plan and be ready at the right time.

The knowledge needed and the representations used, are pragmatic and efficient for management and planning, and the focus is NOT on the visual thinking and understanding of what shall be done.
Only the management and control aspects of the development are considered.

In the BA/RE practice you often get advice to use X or Y or Z but no direction on WHICH representation to use and no focus on reasoning regarding the effect on this choice for downstream development.
The often individual decisions are suspiciously sub-optimal with no supporting knowledge of consequence of the specific Knowledge Representational choice as it will most likely affect the way we see things, think and are able to invent …but most importantly the ignorance of what we do NOT see and what has been lost in the knowledge transformation along the way —“the Software Engineering  “Chinese whispers game”(” Telephone-, Gossip game”,  “viskleken”) aka “the agile guessing game”…

Chinese whispers game
“Chinese whispers game”

The essence of the game is that “Whispered messages” are passed around the room and the version which comes back to the starting point bare no relation to the original message. This phenomenon of “whispering” can also be extended to “not really understanding” in a more general sense to describe every day “mis-telling” of stories and misunderstanding of knowledge in any setting or form, when only using talk and sloppy writing are used as for knowledge communication. In fact, the sheer existence of this “whispering effect” is one of the reasons why LEAN and AGILE will never really work in Software Engineering without a sincere and focused knowledge representation for thinking and understanding!

We are lacking a focus on HOW we make the decision between different Visual Knowledge representations and the effect of our choices both at the same level regarding knowledge, understanding, innovation, and creativity, but also the downstream understanding of WHAT is communicated and what is NOT represented at all.

Most models are not explicitly showing the Visual Knowledge Representation, but can easily be enhanced by a VKR component. For example the VKR decision point in the MSDDRE model

MSDDRE model with VKR
The MSDDRE model developed by Krzysztof Wnuk – Blekinge Tekniska Högskola (modified by the author)

And by the way, this is my research domain. Do you want a draft title? OK here we go:

“Formal & informal Visual Knowledge Representation used for knowledge transfer in Requirements Engineering, Business Analysis and Software Architecture
– evaluation of real usage in industry, choice of representation and diagram narratives to identify difficulties and errors in thinking and how to find
the Best Possible, Good-enough and Visual Knowledge Representation with focus on the properties required for formal modeling in practice”

Stefan_BLOGG_bild_text_EEKENULV_3

Hur namnger du ditt konferensrum?

Jag minns en händelse som utspelade sig när jag jobbade på Ericsson runt 2002.
Vi hade bokat en grupp med Subject Matter Experts från Stockholm för en intensiv krav- och modelleringsworkshop i Göteborg.

Jag var väl förberedd som den som skulle driva modelleringen med fokus på begrepp och informationsstrukturer.
Det som ofta är grunden till många problem inom företag är just en förenklad eller felaktig informations- och begreppsmodell. Man tror att man pratar om samma sak, tills man inser att man inte gör det. Och den insikten gör ont. Och har ofta kostat mycket tandagnisslan, energi och pengar!

Men våra inbjudna gäster verkade vara försenade!

Vi som hade varit så noggranna med inbjudan till workshopen med både “reading viewpoints”, roller, effektmål etc.
Och jag hade redan dubbelkollat att både tid och datum stämde!

Jag började känna en viss oro. Tills jag fick ett samtal från en av dem.

– “Vi är på Ericsson i Borås, och det verkar inte vara någon här som vet något om en workshop!”

Begrepp! Inbjudan var till workshop i konferenslokalen vid namnet “Borås” i Göteborg, inte till Ericsson i staden Borås.

Men vad ska man då ge konferensrummen för namn?

Jag har tänkt på det i omgångar tills jag såg konferensrummen på CASTRA:s kontor i Göteborg.
Castra har namngett rummen med existerande kärnvärden och de ord som är viktiga drivkrafter för företaget.
Det innebär att varje gång du bokar ett rum blir du indirekt påmind om kärnvärdena som ska styra verksamheten.

Genialt!

Det är så ett seniort konsultbolag tänker och realiserar effekt in i minsta detalj!
Det är ju så att vi bör ta varje tillfälle för att skapa kommunikation om något viktigt och drivande för en verksamhet.

“the power of words is that if you change the words, you change the world!”

Castra mervärde

 

Stefan_BLOGG_bild_text_EEKENULV_3

Sju frågor som du bör ställa för att Representera Kunskap

– Ett sätt att tänka för att representera kunskap pragmatiskt, på ett sätt som fungerar och ger effekt!

Ibland känns det som att både begreppet “krav” och “modell” har blivit “fula ord” i en ofta struktur- och kunskapsfientlig låtsas-agil projektmiljö. Men för mig är kunskapsrepresentation, som dessutom är pragmatisk (dvs. funkar på riktigt i verkligheten) det mest agila som finns.

7 viktiga frågor att ställa

Mina huvudfrågor är alltid följande:

  1. “Kneeded

    Vilken kunskap behövs och vad är det vi behöver förstå (i den givna situationen och kontexten, med ett prioriterat antal intressenter, vyer och problemdefinitioner)?

  2. “Rbest possible

    Vilken skulle vara den bästa möjlig representationen av kunskapen om vi hade oändligt med resurser och hade tillgång till “the best of the best” inom erfarenhet och kunskap?

  3. are we doing it?

    Är det den representationen vi använder idag?

  4. “Rnow

    Hur representeras denna nödvändiga kunskap idag? I huvudet på folk eller i textdokument eller rentav enbart i koden? Är det ett gap eller skillnad mellan Rnow och Rbest-possible ?

  5. “Impactwith no R

    Vad skulle hända om vi inte representerade kunskapen alls, utan lät den bara vara kvar i huvudet på de inblandade och enbart förmedlades genom prat eller icke strukturerade sketcher på en White board?

  6. “Rgood-enough

    Vilken är den bästa representationen vi kan göra idag med de tillgängliga resurser vi har med de begränsningar vi utsätts för)? Ska verkligen representationen bara “finnas i huvudet på folk” (tacit knowledge) eller ska den fångas enligt konstens alla regler med både syntax, semantik och Well-Formed Formulas? Är det ett gap eller skillnad mellan Rgood-enough och Rnow ?

  7. Rpragmatic

    Hur gör vi representationen så tillgänglig och effektfull (pragmatisk!) som möjligt för att nå de givna projektmålen inom de givna ramarna och spelreglerna? Behöver vi undervisa och lyfta folk i tanken, eller måste vi förenkla representationen ytterligare eller baka ihop den med existerande ramverk och integrera i existerande verktyg och mallar?

7 questions for PKR_transparent
Om du är intresserad av mitt senaste projekt kring “Post-it Thinking”
kolla in https://post-it-thinking.blogspot.se/

KRARIRR_mnemonic image__EEKENULVMnemonik för att minnas de 7 viktiga frågorna!

En pragmatisk metafor

Att arbeta som verksamhetsanalytiker (Business Analyst – BA) eller kravingenjör (Requirements Engineer – RE) innebär att man är som Christofer Columbus. På sju sjösjuka sjömäns hav i stormens vildsinta krängningar av den plattform/båt vi befinner oss på och där allt yr omkring och det blåser olika vindar, där försöker vi rita kartor! Vi ritar sällan en ny karta, men verifierar och validerar den som finns och lägger till viktiga saker som är värda att “kartifiera” så att alla kan få nytta av det vi upptäckt. Vi utforskar och vågar segla de mest stormfyllda vatten eftersom vi litar på våra kartor och vår förmåga att navigera. Ju bättre karta, desto lättare är det att navigera och ju smartare väg kan vi ta för att nå snabbare fram till hamn.

Smart och agil segling innebär inte mindre information, utan rätt information
för den givna (väder)situationen och de hinder som identifierats.

Som BA/RE skapar vi rätt karta som är tillräckligt bra för att ge nytta och den eftersökta positiva effekten!

En karta förbättras kontinuerligt och ger upphov till nya tankar och ger förmågan till helhetssyn!
Segla inte rakt ut i havet utan att veta vart du ska och utan förmåga att fånga det du ser och upplever.

skattkarta__EEKENULV

Det är viktigt att sätta fokus på VAD vi måste ha koll på och veta, HUR vi ska representera det så att alla förstår, så att vi slipper göra en massa omtag och rita om kartan varje gång.
Dessutom så måste vi använda vår erfarenhet för att få det att funka i praktiken på ett så smart sätt som möjligt med vår enorma verktygslåda och de tankar och resurser som redan finns på plats!

En korrekt modell som inte används är en dålig modell!

 

Stefan_BLOGG_bild_text_EEKENULV_3