About my Magma consulting activities

What is interesting in Haeckel his article is the application he makes from the theory in a real (financial) world. Let's read it further: Procedures, in contrast, codify know-how. Their design necessarily entails predictions about inputs, contigencies, and the best way of doing something. Their ability to deal with the unexpected is limited by the imagination of the designer, rather than by an on-the-spot interpretation of current reality. When something unanticipated does arise, the best a procedure can do is deliver an exception report - the designer's way of saying, "I hope there is a Marshall Faulk out there to deal with this". Now, let's have a look at how Haeckel uses his definitions (or vision) in a real business life case: a merge and acquisition (M&A in the financial jargon)operation: Unless leaders are good architects - wich means they can be clear about organizational purpose an how the parts of the business relate to the purpose and to each other

The top-down design principle does more than identify poor practice. Accordingly, a system design effort should start by identifying the constituents for which the organization must produce outcomes, and that those outcomes are. It is from this work that the purpose, or design point, of the organization should be determined, not from an analysis of the company's existing capabilities. As a result, the design is "purpose down" rather than "capabilities up". (Haeckel) This assertion from Haeckel is certainly true in project management. When determining what has to be accomplished at the end of the project (like the major deliverable or project result), most of the time, a lot of stakeholders propose some additional features and some 'nice to have' points. This is where the budget gets lost and where the problem are coming from.