Tuesday, 16 November 2010

Project Management & Magic: Choosing the right Process

Having established that magical workings and projects are temporary endeavours undertaken to create a unique product, service or result – let’s look at different ways of achieving them. One thing to note is that a distinction needs to be drawn between magical techniques and worldviews or belief systems.

An example of two magical techniques is where one is improvised on the spot and another involves an elaborate ritual that requires months of planning. Both approaches might be used by say a druid, a Solomnic magician and a cabbalist even though their worldviews and belief systems may differ quite a bit.

So in terms of projects a good Project Manager will use a toolbox of processes as required for any particular project. Some organizations are more supportive of process being tailored for each project whilst others insist that the same project processes are used for each project even if they are not suitable such as not scaling well between tiny and huge projects.

The basics of Project Management (PM) as outlined in the PM Body Of Knowledge, (3rd edition, pp39):

3.1 Project Management Processes
…An underlying concept for interaction among project management processes is the plan-do-check-act (as defined by Shewart and modified by Demin, in ASQ Handbook, pages 13-14, American Society for Quality, 1999). This cycle is liked by results – the result from one part of the cycle becomes the input to another…

The PMBOK then goes on to elaborate on the slightly more complex process cycle of Initiation, Planning, Executing, Monitoring & Control and Closing processes.


So taking the plan-do-check-act as the simplest cycle, an example of use of this is something that I do fairly regularly when travelling on London Public transport. As most commuters will tell you that waiting for a bus during winter in London is no pleasant undertaking. Using the simple plan-do-check-act cycle I’ll "plan" to summon a bus, the “do” part is simply chanting ‘bus, bus, bus’ whilst visualizing the imminent arrival of a bus. The “check” part involves looking out for a bus and the “act” part is either choosing whether to wait a bit longer or deciding to walk to the next bus-stop if it's a better albeit slower way of keeping warm.

One word of caution is that if the ‘bus, bus, bus’ chant is used too often whilst waiting for a bus – you’re likely to get at three or more coming thundering past!


Another example of project process is the Waterfall model. This is a model that was previously popular in the software development world. It involves the requirement capture, design, implementation, testing and release being done in a serial manner. In other words, no implementation is done before design is completed and testing does not start before implementation is done. A magical equivalent is Abramelin in which there is a specific sequence of tasks that the initiate needs to do in a specific order. Whilst there are many who try to cut corners and reduce the time and effort for this working, this breaks the process. See Aaron Leitch’s blog comments on why it pays to do it right. 


The next process to become popular addressed some of the key weaknesses of the Waterfall way of working. Iterative and Incremental development aimed to shorten the design-implement-test cycle and instead of it being done once – to have it repeated a number of times over the project lifecycle.
In magical terms what this may relate to is a repetition of a ritual in order to achieve a particular refinement. For example, a magician who wants to create an astral temple in which to carry out magical workings may start of by planning and carrying out a series of visualization meditations on constructing this temple in ever sharper focus and detail. Keeping a record of their activities and a dream diary, the initiate would plan each part, visualize it, dream about it and then make necessary adjustments thereby following the iterative process of working.


At approximately the same time that Iterative ways of working were becoming more popular, Extreme Programming was also on the rise in some organizations:

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

This way of working not only adapts to change very quickly, but it actually embraces change and incorporates it well. However, maintaining a level of discipline in this way of working is challenging and without regular feedback the project can quickly go off track.

So from a magical perspective this way of working is being constantly mindful of one’s environment and reacting accordingly with whatever magical practices are required. Rather than spending a lot of time researching (design) or doing complex rituals (implementation and testing), the initiate takes input from their environment (people and places) and responds as needed. No long term planning is done and development of techniques is done in the moment. It grows organically out of each situation the initiate finds themselves in.


The final project process to be discussed and the one that is rising in popularity in the software development world is Agile. This way of working incorporates the adaptability to changing requirements, frequent releases, simplicity, self-organizing teams and a sustainable way of working.

Rather than say implementing each level of a software stack one above the other until the full stack allows for phone calls to be made on a mobile, Agile takes use cases and scenarios that the customer wants and implements thin slices of vertical functionality. So the difference to the layer by layer approach is that in Agile a use case might be to make emergency calls and after the first few iterations that may be all that the software can do, no normal voice or data calls may be possible. However in future releases additional use cases and scenarios are implemented. In the layer by layer (cake) model each part of the software provides full support for voice, data, emergency calls, handovers, etc. But this complete solution would not be working until the very end of the project when it all gets integrated together.

An example of Agile working is a self-organizing group of initiates (is such a thing possible?) that have a vague high level plan for achieving a particular goal and meet on a weekly or bi-weekly basis to plan and put in to practice the details of the upcoming rituals and magical workings. As noted in a previous post completing the meditations in Sefer Yetzirah to achieve the level where an initiate can create a golem or turn lead in to gold takes three years. Agile would be a suitable way of managing the joint development of initiates to progress their meditations, demonstrate their abilities at letter combinations / permutations and understanding of the workings of creation, as well as review & adapt to changes in the initiates and their environments.

Having taken a whistle stop tour through several different software development processes and their potential applications in the field of magic, I hope that you have seen how different approaches have their advantages and limitations. From what I’ve read online and having spoken to folks at occult bookshops - some use processes that mirror Extreme programming, to those that work in a way very similar to the Waterfall process. For some workings more structure is better and for others not. Let experience and common sense be your faithful guides.