![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rThe true consulting is boring and honest.
It has little in common with sparking motivating blessing when a guru introduces The Right Solution for all known and unknown problems (and afterwards explains why everything did go wrong).
The true consulting consists of boring processes: scrupulous information gathering, thoughtful information analysis and careful comparison of alternative strategies. All three processes are interconnected and usually produce a lot of errors and mistakes that must be detected and corrected. (A Great Guru is always right.)
The main problem of the true consulting is that it must be honest. In most cases unfiltered information is bitter. And it rarely reaches upper levels of management. Most companies fear honesty.
Indeed, I rarely had seen the true consulting during the quarter of a century I work in IT and related fields.
As mentioned in the previous part below is a draft description of an interesting tool for information analysis:
Analysis of a complex problem is a complex task. There is no way to avoid the complexity.
It is possible to use intuition but it mistakes.
It is possible to use simplified models but they could miss important details.
It is possible to try to solve small parts separately but internal connections may make the patchwork solution unusable.
The modern way is to feed information to some software and to hope that output is relevant. At least such method hides uncomfortable questions and contradictions somewhere in the depths of a computer. This cures the uncomfortable feeling of powerlessness.
The Changes Acceptance Matrix belongs to the other type of tools. It's goal is to make visible the whole picture. I call such things "playgrounds". I like to use them despite of the sharp feeling of incompetence and dumbness they produce in you on the early stages of work.
Usually this is a table printed on a sheet of paper. Such table rarely passes on a A3 format. However I did not use something bigger than A0 because too much details produce not the clarity but noise.
I usually apply colors to make structures and problems visible. Sometimes this means I colorize table fields with markers, color pencils and even watercolor.
Below is a draft sample of a Changes Acceptance Matrix for introduction of modeling. This is a reduced abstract case for a sketchy demonstration.
I can honestly say that this is an attempt to create a new version on base of my draft exercises. It was changed several times during the writing of this post.
Rows represent different stakeholder types. This are roles of people who are affected by changes.
I suppose sometimes it would be necessary to name specific persons however this turns an abstract analysis tool into a political weapon and I would avoid such situations. There are enough politic plays already by attempts to access undistorted information.
Roles are gathered in two main groups: input and output.
Input means the performing of actual work. This are effects that changes cause in processes of creating new work products (documents, reports, source code, etc.).
Output means the use of the results for performing external tasks. This means the performing of processes that create work products that do not belong to the changed domain.
For instance, when a developer inserts data into endless forms of an new automatic reporting tool instead of making something useful this is the upper group of roles "Input'. When a manager uses statistics generated by this tool instead of speaking with developers this belongs to "Output" roles.
Effects are divided in subgroups and the wording is chosen in the way to make it positive for the person who performs a role in the particular row.
Sometimes this is tricky. For instance, the visibility of own errors is good for a person performing the tasks but the effect of the same visibility is negative after this person reports that the task is complete and delivers incorrect work product.
"+" means that the changes create this positive effect.
"-" means that the changes work against this positive effect for this person
"?" means that the influence of changes is undefined
"/" means that the effect is not applicable. For instance an users of a software are affected by the quality of end product but the development processes do not influence them.
The table shows only the trends. It makes no sense to try to present them in numbers. Most of effects describe some subjective estimations of a person. Additionally one negative effect for the upper management may influence the success of the changes more than all positive effects for people who do the actual work.
For instance the domain expert who is forced to use modelling tools loses time and joy but in the the responsibility for errors and delays of the end result is moved on the department which implements models. This creates the urge to compromise the quality on the modelling level.
Note, this is only a draft for an imaginary case. The current full version of CHAM template contains 59 effects. If the time to analyze on effect for one field takes 1 minute, it would be necessary to spend 1 hour pro row. In a real project such field may take several minutes or even hours to discuss the effects and to find correct information for analysis.
On the other hand this is knowledge necessary to manage changes. It could predict problems and failures that could be discovered otherwise after many months.
It also helps to start management actions that turn negative effects into positive what could eliminate risks.
This means each field is not a simple sign but it represents information gathering, analysis, discussions, and decisions hidden behind it.
Below are some drafts that I have made for myself to estimate the sources of problems.
CHAM Modeling
CHAM Functional Programming
CHAM Agile (Level 1)
It has little in common with sparking motivating blessing when a guru introduces The Right Solution for all known and unknown problems (and afterwards explains why everything did go wrong).
The true consulting consists of boring processes: scrupulous information gathering, thoughtful information analysis and careful comparison of alternative strategies. All three processes are interconnected and usually produce a lot of errors and mistakes that must be detected and corrected. (A Great Guru is always right.)
The main problem of the true consulting is that it must be honest. In most cases unfiltered information is bitter. And it rarely reaches upper levels of management. Most companies fear honesty.
Indeed, I rarely had seen the true consulting during the quarter of a century I work in IT and related fields.
As mentioned in the previous part below is a draft description of an interesting tool for information analysis:
The Changes Acceptance Matrix
Analysis of a complex problem is a complex task. There is no way to avoid the complexity.
It is possible to use intuition but it mistakes.
It is possible to use simplified models but they could miss important details.
It is possible to try to solve small parts separately but internal connections may make the patchwork solution unusable.
The modern way is to feed information to some software and to hope that output is relevant. At least such method hides uncomfortable questions and contradictions somewhere in the depths of a computer. This cures the uncomfortable feeling of powerlessness.
The Changes Acceptance Matrix belongs to the other type of tools. It's goal is to make visible the whole picture. I call such things "playgrounds". I like to use them despite of the sharp feeling of incompetence and dumbness they produce in you on the early stages of work.
Usually this is a table printed on a sheet of paper. Such table rarely passes on a A3 format. However I did not use something bigger than A0 because too much details produce not the clarity but noise.
I usually apply colors to make structures and problems visible. Sometimes this means I colorize table fields with markers, color pencils and even watercolor.
Below is a draft sample of a Changes Acceptance Matrix for introduction of modeling. This is a reduced abstract case for a sketchy demonstration.
I can honestly say that this is an attempt to create a new version on base of my draft exercises. It was changed several times during the writing of this post.
Rows represent different stakeholder types. This are roles of people who are affected by changes.
I suppose sometimes it would be necessary to name specific persons however this turns an abstract analysis tool into a political weapon and I would avoid such situations. There are enough politic plays already by attempts to access undistorted information.
Roles are gathered in two main groups: input and output.
Input means the performing of actual work. This are effects that changes cause in processes of creating new work products (documents, reports, source code, etc.).
Output means the use of the results for performing external tasks. This means the performing of processes that create work products that do not belong to the changed domain.
For instance, when a developer inserts data into endless forms of an new automatic reporting tool instead of making something useful this is the upper group of roles "Input'. When a manager uses statistics generated by this tool instead of speaking with developers this belongs to "Output" roles.
Effects are divided in subgroups and the wording is chosen in the way to make it positive for the person who performs a role in the particular row.
Sometimes this is tricky. For instance, the visibility of own errors is good for a person performing the tasks but the effect of the same visibility is negative after this person reports that the task is complete and delivers incorrect work product.
"+" means that the changes create this positive effect.
"-" means that the changes work against this positive effect for this person
"?" means that the influence of changes is undefined
"/" means that the effect is not applicable. For instance an users of a software are affected by the quality of end product but the development processes do not influence them.
The table shows only the trends. It makes no sense to try to present them in numbers. Most of effects describe some subjective estimations of a person. Additionally one negative effect for the upper management may influence the success of the changes more than all positive effects for people who do the actual work.
For instance the domain expert who is forced to use modelling tools loses time and joy but in the the responsibility for errors and delays of the end result is moved on the department which implements models. This creates the urge to compromise the quality on the modelling level.
Note, this is only a draft for an imaginary case. The current full version of CHAM template contains 59 effects. If the time to analyze on effect for one field takes 1 minute, it would be necessary to spend 1 hour pro row. In a real project such field may take several minutes or even hours to discuss the effects and to find correct information for analysis.
On the other hand this is knowledge necessary to manage changes. It could predict problems and failures that could be discovered otherwise after many months.
It also helps to start management actions that turn negative effects into positive what could eliminate risks.
This means each field is not a simple sign but it represents information gathering, analysis, discussions, and decisions hidden behind it.
Below are some drafts that I have made for myself to estimate the sources of problems.
CHAM Modeling
CHAM Functional Programming
CHAM Agile (Level 1)
Tags:
- agile,
- en,
- it,
- management,
- motivation,
- psychology,
- qa,
- quality,
- se,
- visualisation
