Hologramming is a philosophy for the coordination and harmonization of multiple projects. Hologramming stands for „Holistic Programming“ and belongs into the category of the „Program Management“, which is the art to deal with the interaction of many projects executed at the same time. It is a governance strategy that transports the great ideas of Extreme Programming (XP) and Agile Development (AGILE) into the project management circles. Hologramming makes practical use of ideas found in the „Theory of Chaos“ and is a template free approach to create feedback control cycles between projects.
Hologramming is based on those core principles:
Every decision you make in one branch of your SOE needs to be reviewed for safety and side-effects for the remaining components in the biosphere.
This is a clear rebuff to any variant of silo thinking. While traditional project management is based on strict abidance to guide-lines, holistic thinking demands that you always question the validity of the rule in context of the outcome. The same rule applies when you drive your car over a cross-road at green light and some other driver crashes into you. While you acted formally correct, you might still be caught guilty if it turns out that you could have avoided the accident because you saw that the other car could not stop.
This principle is well proven in real-life and known as social responsibility. Some societies like the USA set up even tremendous fines and punishments for individuals who negligently disobey the rule to invest any effort to avoid damage to a third party. When a merchant did not check the safety of an electrical appliance he sold although he could have done so, he will be held responsible for any damage caused by a malfunction, no matter if he is responsible for the fault or not.
It is interesting to observe, how few of every days education and trained behaviour is reflected in project and programme management. Well led projects train the good manners of the staff in first place. This starts with formally introducing new team members the very first minute she or he appears. It is already a good indicator for the health of the project if the people are comfortable in saying „please“, „thank you and „welcome“ where it is appropriate and ask the question not as criticism but with the purpose to receive information that they did not now before.
Based on „Gravity“
Own solutions need to defended
Assistance needs to be „traded“
Hologramming is non-invasive
Hologramming orchestrates projects and processes
Hologramming encourages change according best-practice
Hologramming is agile.
Hologramming does not require change in the atoms
Top 10 reasons that your project is in bad shape
New people arrive in the project and the PM does not bother to introduce them personally
The PM asks first for the costs and then for the benefits.
If you ask a question in order to understand and you receive a pile of paper or a link to a document without further comment.
This is the killer of any project. If the people who are supposed to work together communicate via paper or email only and do not bother to stand back and answer questions. If you hand over documents for perusal your partner can expect as a minimum, that you give him an short introduction and overview of the content and hand over some of the meta-knowledge that you have.
Sizing of SOA Management
Chaos Theory as Basis
One of the lessons from chaos theory is the acknowledgement that things that work in the small may turn out as a disaster if the get a critical mass. Speaking of critical mass it immediately rings a bell: nuclear chain reactions are based on this recognition. You first have to amass a reasonable amount of uranium or plutonium to trigger the chain reaction.
Masses need often completely different means to move them than it is required for individuals. In a practical picture: it is sometimes easier to walk out a crowd of hundreds of visitors of a museum at closing time then to convince the remaining three individuals. The same example in terms of costs: to watch over a museum you need a certain number of guards, no matter if you have 10 or 10000 visitors every day. There is always an optimum number to achieve the best effect. If there were too many guard it is not simply that you have to pay more salaries, but you would then need a guard for the guards and a guard for the guards of guards, making the security system inherently unstable.
Another observation that I find very intriguing is the public road traffic. Other than air traffic control, where every movement is centrally controlled and commanded from a central tower, the road traffic is based on self-organisation. Few very basic rules are set up and need to be respected by every driver, like driving on the right or left side resp, and stopping at red light. The interesting observation is now, that if increase the number of rules and street signs, the whole traffic becomes less secure.
This observation can be translated into Hologramming as well. If you bring too many controllers and managers into a project you castrate the teams from their power to safely and efficiently organize their work totally on their own. A project with too many managers will lack of efficiency and create frustration.
The example of the rower and the eight commanders does not fully mirror the problematic. It is not only that the rower has to do the work of eight ones, but with eight commanders the messages are likely to be so contradictive that the boat is more than like doomed to capsize after the first ten beats.
When you imagine to build a motor you have the option to make every screw and ever lever just according the need. You will end up in some thousands of different screws and levers, each individually manufactured. The problem („the critical path“) occurs when one of the screws or levers is not ready. It ultimately means that your motor cannot be finished. The whole assembly of the motor is a single critical path. In order to reduce the risk of stopping the assembly due to a missing part, you find your refuge in modularization and standardization. Modularization in this example would mean to reduce the number of different screw types and standardization means using standard components as recommended by the standards bodies.
For our analysis let us break down the problem o an easier manufacturing process, the good old example of discrete manufacturing: „a bicycle“. This bicycle is made from two wheels, very wheel with a inner and an outer tube and a valve. Every wheel is fixed with two screws to the bicycle frame. Typically the front and the rear wheel are designed differently. While the front wheel has a simple axis, the rear wheel has a cog wheel attached. When the supplier for the wheel does not deliver any one of the two wheel types, no bicycles are built. You can now reduce the risk of stalling the whole assembly process by redesigning the bicycle, so that front and rear wheel are identical. The necessary cog wheel to drive the rear wheel will be simple plugged and fixed to the rear axis as an extra component. Assuming that cog wheels supply exists in abundance – we cleverly decided to use standards cog wheels – we now reduce the risk of halting the assembly process, because rear and front wheels are exchangeable. We might still end up in producing less bicycles than expected, because we have not enough wheels, but yet we produce them at all.
If your planning has finished your project stopped! (è Agility)
Hologramming is no new management philosophy but an attempt to bring in the successful concept of Agile and eXtreme Programming into Programme Management.
- There is clear and simple target
- Benefits and consequences of reaching the target must be obvious to all members
- Every decision must be explicitly verified against the target
- Teams decide freely over their work
- An ombudsman decides in case of contention
- Written documents are no replacement for verbal communication
- Target-oriented planning and acting
- Event-driven project management
- Networked-Thinking (Holistic)
- Steady perusal of the effects of a decision or action in one project object for other components