Logosworld is a German "Bureau of Engineers" helping as strategy advisors for future technology.
After a life time leading tech projects , experienced experts have joined forces for handholding the next generation.
Agile, no-nonsense S4/Hana implementations, rollouts, carve-outs with EDI and Industry 4.0.
Cloud computing brings a completely new challenge to project management - at least for all the IT organizations that have been gotten used to managing their ERP projects like a department store.
Other than in traditional department computing programs now exchange information inside and outside an organization at own liberty; employees and guests want to bring their own equipment; customers want to see a website on a high resolution screen and on a smartphone, substantial algorithms are run as services by a foreign vendor and data is stored in holographic storage around the world; Processes are subject to change every day and business expects IT to mirror the change in business immediately. There are now many simultaneous players that have influence to a project and are not truly under control of the stake holders. Getting them all in line is the new true challenge. What is needed is a holistic view on projects and strategies that mitigate complexity rather than pinning pre-emptive road-maps. Hologramming is an initiative to bring the century experience of project management of multiple sciences into IT.
If you are an IT manager or architect, you want to ask yourself: how do you guarantee reliable access to your data? How do you meet quality expectations? How do you define and supervise service contracts and service level agreements? How do you protect data and intellectual property against theft and loss? How do avoid vendor-lock-in and similar dependencies? How do you make services easily accessible? And most important: how do you react quickly on change requests when business changes their processes? Momentarily there is a lot of talk about “BYOD” – “Bring your own device” and Multi-Channel access as a result of the Smart-Phone and i-Pad revolution. BYOD means that your employees or even your guests want to access your network with their own computers – be it a laptop or a smartphone. This brings a complete new challenge to the security departments since they no longer can control what software the client computer is running and what it is doing with your data. Protection of the servers must hence happen on server side and the strategies involved must be completely different from what has been good practice in previous years. Multi-channel refers to the trend that your internal servers can be accessed from a large variety of different clients: from a classical GUI client, via an internal intranet website, via an external website, from a wide-screen PC, a tablet, smartphone and also from “robots”, other programs that retrieve information from your system. Such multi-channel access can easily cause problems that have never been considered before. Just let us see the simple example of a web-shop that uses your SAP system as a backend. The web-shop may be designed according the current sales expectations, getting some hundred hits per hour. Now your marketing department launches a nice commercial in TV where they offer a free Teddy bear or the mascot of the next football championship to each registration within the next 24 hours. All of a sudden the same web site that got several 100 hits per hour will now be flooded with several million web site requests in the same period. If the SAP system backend is tightly coupled to these requests without any load throttling the marketing campaign will shoot your SAP to death. This phenomenon is called “Denial of Service” (DNS) when done intentionally as a malign attack by hackers. The most important challenge of any IT project of the future lies in the unpredictability of what changes will come next. Any department in the IT sector must be prepared for immediate changes and be trained to react quickly. No longer they can sit down and make a plan for next year to solve this year’s problem. The management of projects is a management of change. The duty is no longer drawing road-maps but rather acting as fire-brigade and risk arbitration between independently acting groups in order to cope with complexity. After working 25 years in the IT business it must have appeared to me that IT was the genuine inventor of project management; never before a proper project management existed. And the second lesson I learned was from the big accidental consultancies that every project must be planned in most detail from the beginning, including the un-predictable uncertainties and the sequence of non-sequential activities. Reality shows that both strategies do not hold true. There may have been projects that succeed despite such strategies but seldom one project had a benefit from it. Why does this simple waterfall model not help in IT projects?
Classical project management methods in IT are mainly designed to administer linear projects that follow a repeatable master plan. Waterfall style methods mainly depend on a master plan that has been created with thorough experience on repeatedly doing the same task over and over again. The pre-condition is that the wide majority of the steps listed in the master plan can be executed as pre-emptively sketched and that the given sequence can be obeyed at any time.
Complex projects, however, have multiple tasks running ion parallel that may influence each other and build a feedback cycle where a later step might change the conditions under which a previous step is build. Complex projects cope with situations where many steps cannot be defined in detail since the grounds on which they will execute are not sufficiently known at design time. Therefore a methodology for complex projects needs to be primarily reactive. Rather than defining a path to go it needs to mark the forbidden areas. We have seen that this was not even successful in classical ERP projects, since most ERP implementation projects were pioneer projects rather than pure template implementation.
The right strategy for project management depends very much on the nature of the project itself. The primary classifying factor is the degree of uncertainty involved during the progress of the project. The two extremes there are
These are projects where all components, implementation steps and especially the design, function and quality of the final product are well known from the moment the project starts The other extreme are
The character of such a project is the complete absence of details about the components to be used, the sequence and manner of implementation; in true discovery projects even the nature, look and quality of the end product cannot be described deterministically at the beginning.
A typical example for an assembly project is the rollout of a new version of an operating system throughout a company. If a company possesses 10000 laptops or desktops for their employees the primary intention of the administration teams is to have widely identical configurations, therefore they will define a small number of templates from which employees can choose from. Hence, the look and quality of the target product is well known before the rollout starts. The rollout steps can also be very well defined from the beginning onwards:
A discovery project is any project that is not an assembly project, meaning that for at least one essential step in the whole compound not sufficient implementation experience exists. To define it in a more abstract way: A discovery project is a project where no stochastically significant number of successfully implemented and productively used templates exists a- and a stochastically significant number is definitely larger than 10. If you have not implemented a very similar template at least 10 times before, you are in a discovery project. In practice, any ERP project and e-Business project falls in this category. Even if several models for such an implementation exists, there is hardly a team found that has done the realization often enough. Every project in ERP is usually a pioneer project for the team and often even a research tasks for the specialists involved, as it counts to find a compromise between using standardized functionality of the ERP package and the individual business and manufacturing processes of the real company. Waterfall methods are absolute useless in such projects. They often fail from the first day onwards as they may not even be able to deterministically tell the duration and cost of making the base installation. If we want to compare the principles with games we can see it like the difference between rubber twist and chess. To play rubber twist you practice the same jumps and movements over and over again. The less you deviate from the practiced movements the better you get. Chess can only practice patterns but it is impossible for the human brain of today to predict the constellation only several moves ahead. Complex projects are best managed by two principles:
Points of confluence are moments of time or certain events that have been agreed by all players in the project where they try to match their results and solve discrepancies before continuing the next step. The essential element in confluence strategies is that the next project phase will only be planned in detail when the confluence has been successfully completed.
| [b]Project Type[/b] | [b]Methodology[/b] | [b]Style[/b] | [b]Game analogy[/b] |
| [b]Assembly[/b] | Waterfall (Top Down) | Linear | Rubber Twist |
| [b]Discovery[/b] | Confluence (Agile, iterative) | Complex | Chess |
When we look for a project management for cloud based projects we need to understand the nature of such projects. Cloud stands as substitute for distributed computer architecture and therefore for any kind of computer software project where several independent entities are involved. Due to the distribution of duties and responsibilities it is the main characteristic of cloud based projects that there is no clear hierarchy in the project team. In fact you will have several cooperating partners that insist in their independency rather than one hybrid rigid team structure. Such projects are generally denoted as “complex” as they are compounds out of independent entities. Hologramming is a compilation of project management strategies that come out of several scientific disciplines that have in common that they deal primarily with complexity and uncertainty. We are not that pretentious to call it a new methodology; Hologramming simply pins down and adopts age old practices in large projects for the use in complex IT change management. The base idea is very much related to democratic political structures which are also the common base of any scientific discourse. Instead of central planning every substantial project component is discussed and challenged between the parties and then written down as a contract. Hence, clear and jointly agreed rules and guidelines enforce mutual understanding, reveal deficiencies at an early state and build a solid and resilient ground for the project execution. In parallel this approach guarantees agility and fast reaction time on needed changes and uncertainties. Hologramming is remotely related with the core ideas of the Six Sigma production management standards and certainly a brother in arms with SCRUM Agile methodology, which is nowadays common practice in the modern development circles. Other than most standardized project management concepts both Six Sigma and SCRUM put a substantial weight on the psychological factor in a project. Hologramming assumes that the general disparate project cannot be planned in detail. Although a typical ERP project and its extension into the cloud appear simple as the number of players and the rules that are set are limited it is only possible to look ahead two or three substantial steps following a decision; we know this seeming paradox to not being able to predict the constellation from the game of chess. Traditional project management in IT assumes that the majority of actions and the sequence of action can be widely defined at the beginning. Deviation from the rough over all time line is usually not permitted. Although this assumption is apparently false for nearly every implementation project the common school of the big consulting companies notoriously follows this strategy. The solution path of Hologramming is developed practically proven Standard Operation Procedures that cope with the special behaviour and events that occur in a distributed, highly decentralized environment. This methodology was originally developed to have guidelines for rollout teams in multi-cultural environments where communication between the actors is limited for various reasons. Hologramming is based on the Checks & Balances and peer review principle. It bases on the insight that “less control, is more control” and builds up a highly competitive work factory that implements permanent quality probes to control the maturity of the project and to plug in orientation pillars for the teams.
Hologramming shifts the priority of tasks in a project. In classical projects the project leaders prepare a road-map in the beginning that has to be followed by all other parties that come on board later. Hologramming puts contracts as the key element of any project. Contracts are negotiated and agreed between and only between concerned parties. E.g. project deliveries, the functionality of the featured product, is negotiated between stake holders and the project execution team, while technical details like which middleware to use is only negotiated between the technicians. The priorities are also shifted substantially. In the beginning of a Hologramming session there will be several extensive (and expensive) sessions that we call parliament. In the parliament all parties gain a common understanding of the deliverables, the allowed tolerance in achieving the goals, permissible alternative routes and assert proper proof-of-concept of all essential activities. In the end all involved parties sit down and set up their rules and guidelines for the project. These rules will not change during the project. In the beginning of the parliamentary session there will be a contract on terminology and common education. In the end there will be contracts on the deliverables, on the means to measure project success and project quality and on what measures need to take place when a certain promised goal appears to be non-achievable in the predicted sense.
To summarize, the practice of Hologramming is based on following practical principles. Time is spent mainly in the beginning of a project rather than on the end. In traditional waterfall project the unplanned time is spent in testing g and fixing bugs.
And here we speak of the full team that includes those who are responsible for realization in practice, namely the key developers and implementers. We can easily dispose of a sub.-ordinate project manager in this round but not of any of the development team leads.
The full team agrees on the criteria and key indicators to measure the achievement of a deliverable Such criteria will also include an agreement what deviation from the agreed goal is acceptable and whether there may be a substitute for failure of hitting the goal
For every resource there must be a tolerance specified and also a rescue plan that defines clear procedures how to act when the allotted resources turn out to not being sufficient To summarize: Hologramming is a compilation of proven management practices from different sciences and engineering practices that deal with complex implementations for very long time. The key concept is Standard Operation Procedures, a set of rule that are defined and agreed upon at the very beginning of the project, where PMI and ITIL/ISO 2000 can serve as template, but only after intensive parliamentary sessions of the full implementation team where all deliverables are discussed the project may start. All essential results of and put into a contract that also names emergency actions in case of failure and the methods to determine the quality of an implementation. Common terminology, common education and solving contending opinions at the beginning rather than during a project are the key elements of Hologramming – as they are best practice in any big project.
Main program risks are uncertainties where no compensation has been foreseen. This refers mainly to