A large project can have many facets: many partners, much budget, many problems, many countries in focus. However, most of the large projects have one thing in common: there are many decisions to be made, the effects of which are not always fully foreseeable.
The theoretical elephant
As many of my well-read visitors will know, elephants should not be eaten in one piece, but cut up into small morsels. The elephant is much less difficult to eat when it is cut up because a) it no longer moves and b) with enough patience, the morsels become so bite-sized that nothing stands in the way of eating them. You may already have noticed that today’s topic is nutritional philosophy. Translated from the metaphor, this means – when you are faced with a problem, try to categorize or analyze it to make it easier to handle.
However, this oft-cited solution addresses only one category of problems, and that is complicated problems. Complicated problems are those that can be eliminated by a little thought (decomposition = analysis) before starting work, especially because any information deficit that may exist is compensated for in advance.
However, there are other problem categories (decision situations = domains) that can fall on your feet during the course of the project. Depending on the system model, these are described differently. The Cynefin framework, for example, knows three more of them:
For a clearer representation, I have colored the relevant step per domain in orange.
As you can see, situations can have different properties in the respective domains, and based on these, there is a reasonable way to deal with the situations. The goal is to get as close as possible to the „obvious“ category – because that would be our bite-sized morsels. Once in the morsel category, these can be approached according to previously known rules (cooking recipe, anyone?), because decision situations here are known and addressable via proven techniques. The situations of the other three domains are more difficult to understand, which means that we have to take some preparatory steps before „consumption“.
So, according to the inserted arrows, one will try to go through each of the domains by reducing complexity and intricacy in a clockwise sense to get bite-sized decisions. But how do these hungry explanations now help the project in practice?
The practical implementation
Even if it is not immediately obvious, the problems described are already addressed in most project management methodologies. The assignment I try to make here is of course simplified, but should clarify the principle.
One can come to the conclusion that already the existence of the methodology in itself clears up with many small stumbling blocks of the described situations. I assign a concrete project activity to each handling in order to clarify the model using the example of a project environment.
For a better illustration, you will find the measures shown here as examples:
- Passive Information Gathering (Probe) … Gathering of information (e.g. customer survey)
- Active Information Gathering (Act) … Carrying out activities when there is a lack of information (e.g. pilot study)
- Problem Evaluation (Sense) … Monitoring of parameters (e.g. sales figures)
- Problem Discussion (Categorize) … Evaluation of monitoring results (e.g. comparison with forecast)
- Problem Analysis (Analyze) … Determine the triggering factors for the measured results (e.g. Intelligence Analysis)
- Problem Solution (Respond) … Designing an action strategy to influence the results (e.g. market development strategy)
The attentive reader will notice that classic deductive/inductive work is described here. Fortunately, this is the basis of the common waterfall methodologies, translated into rules and instructions for the training participants. So you are reasonably on the safe side if you go one step further after the methodology training, in addition to the polite „aha, aha“, and actually apply the described instruments in practice.
Depending on the type of project (and project manager), some may tend to reduce the tools to a listless minimum for meeting internal compliance. Others hide behind mountains of documents and rules to minimize uncertainty and the operational management need.
The measure of things
The good way is, as so often, the middle way: choose instruments appropriately after taking a friendly but honest look at the project proposal and the surrounding organization. However, the instruments then chosen should be used consistently so as not to let your project get out of hand in a laissez-faire manner or through regulatory frenzy. To this end, consult your team, your sponsor and, of course, your compliance colleagues to find a consensus regarding the need for measurement and regulation.
Fundamentally, any project organization faces high demands for results and procedures, few resources, and impatient decision-makers. If it were otherwise, one would hardly bother to appoint a project manager. Accordingly, this also implies the expectation that you select and pursue the respective (!) optimal project approach based on your skills. So if the initially defined methodology is caught in the crossfire because it is considered either a) too costly or b) not sophisticated enough, don’t be put off.
It is certainly conceivable that during the project it will be discovered that the initial course set was not optimal (a case for lessons learned). In most cases, however, the methodology still has the same justification as at the beginning of the project, but operational pressure (internal) or idealistic wishes (external) lead to sensitivities. You alone hold the reins for their management. So use them and manage your project as you see fit.
With this in mind, we wish you the most uncomplicated success possible,
