2.1 The Lost Art of Project Management

2.1 The Lost Art of Project Management

The topic of medieval masonry relates to corporate bureaucracies and, more specifically, to project management, because it illustrates a type of practice of project management which was extremely efficient but has been lost for centuries, only now being recovered by what the industry calls ‘empowered teams’. Let us analyse how medieval construction technique relates to modern project management.

Throughout Europe and Britain, castles stand as a silent testament to the transitional state of knowledge and how the transference of knowledge must be nurtured and not assumed. Many people wonder at the scale, size and mass of medieval castles, often contemplating how the builders were able to engineer such structures with seemingly limited technology. One question is why the builders of castles, cathedrals, town walls and other medieval structures which were constructed during that period used stone and not concrete, as was previously used by Roman engineers in structures such as the Pantheon. A little investigative work reveals that in the fifth century the knowledge for constructing buildings using concrete was lost, as the social structure of the Roman Empire collapsed and Europe was plunged into what later became known as ‘the Dark Ages’. The technology of concrete was rediscovered in 1824 by Joseph Aspdin, a bricklayer from Leeds in England.^[56] The knowledge about concrete and its applied use was lost from the collective intelligence of builders for almost thirteen centuries.

No longer possessing the knowledge for concrete construction, medieval master builders developed a new set of skills based on the accumulation of empirical knowledge of the available construction technologies. Master builders and masons developed a comprehensive body of knowledge using centuries of trial and error to push the technology of the day to its design limits, making castles complex weapons and constructing cathedrals with ever-widening expanses of glass. Today, it is easy to look back and believe that the construction of these structures was simply a matter of gathering a large labour force and working for many years. In reality, medieval builders and their command of design, logistics and project management contain secrets that have been lost in the post-industrialized society. Contrary to common belief, many castles were built rather quickly; spurred on by invading armies making frequent visits. The master builder designed the structure without paper or computers, organized and managed labour (from several guilds, including masons, carpenters and so on), located the raw materials (supply chain, including feeding the workers) and acted as the intermediary between the building’s sponsor, in most cases the feudal lord, a high clergy member or sovereign (top management) and the physical components of the structure. The intermediary role required interpreting the desires of the sponsor and assessing the feasibility of the design changes based on empirical knowledge of structural limitations. It is difficult to imagine how an individual performing all these complex and interconnected activities could direct several building projects simultaneously without the use of Microsoft Project or other contemporary tools. The secret is in the master builders’ approach to building itself, simplification, innovation and high quality skills.

Firstly, builders reduced the complexity of design and construction by simplifying the way in which the structure was built. For example, calculating the thickness of a wall was not a complex mathematical exercise; masons and builders simply used a method that represented years of knowledge based on trial and error with regard to the relationship between the thickness of the wall and its ability to remain upright. Using a piece of string, they would stake out on the ground the overall dimensions of the structure, as shown in Figure 2.2.

Figure 2.2: Calculating the thickness of a wall

The second step was to fold the string in half and mark the centre points on each wall, and then stretch the string between these centre points, forming a diamond inside the original square. The third step was to rotate the diamond inside the original square until the corners of the diamond were aligned with the corners of the square. The distance between the inner and outer squares is the desired thickness. Master builders and masons established simple rules that could be communicated and performed by any number of craftsmen who were engaged in the construction. Remembering that very few people were able to read or write in medieval times, their designs were converted into principles which did not require continual ammendments to specifications. Master builders resembled our contemporary ideal of a leader working with empowered teams. They did not micromanage the activities of individuals, as they did not have the time. The master builder defined the objective and provided a guiding hand in the specification of key details but delegated the execution of many aspects of the construction to the heads of the various guilds.

The second factor employed in the medieval builder’s approach to project management was the incorporation of new ideas into the construction of a building as the structure was rising. The problem of continually changing design specifications sends chills down the spines of any modern project manager, considering the implications to cost and schedule. Countless technology project teams have witnessed the rate of introduction of new technological capabilities passing the rate at which they can implement technological change. This seemingly contemporary problem was also faced by our medieval counterparts; the desire to incorporate new capabilities into ongoing development projects. The ingenuity of the medieval builders is revealed in their approach which incorporates new technology with the acquisition of new skills. In medieval construction, master builders, masons and even journeymen often travelled and lived at each construction site. They simply followed the demand in construction, often moving from county to county, learning new designs as they went. It is easy to see evidence of this in the influence of Arab construction methods that were brought to England and France as a result of the Crusades to the Holy Land. Medieval builders were concerned with the quality of their work, not satisfied simply with mass producing or copying an old design. They readily incorporated the innovations into the building because, in case of a castle, it gave the structure a greater military advantage; they also taught all the masons, journeymen and apprentices the new technique. The continual methodological approach to innovation is recorded in the buildings which remain, allowing modern scholars to trace the technological improvements and map their migration from era to era across Europe.

The third factor in the masons’ approach to project management was a higher degree of skills based on holistic knowledge, which was a product of the guild-apprentice method of learning, to be discussed in detail in section 2.4. This process, often taking seven years or more, provided a mason not just with the skill to lay stones, but also the knowledge of the entire process of masonry. Having a commanding knowledge of quarrying, shaping, carving and assembling, masons were interchangeable and needed lesser amounts of actual management, as noted by Andrews:

the idea of design was already existent when the mason took up his tools, and he knew it and worked to it, carrying forward unconsciously the course of evolution. What was wanted and what was supplied was the man who would work earnestly and honourably and leave, so to speak, the designing to take care of itself.^[57]

Because of this broad knowledge of the process of building, master builders could lay out a structure previously described and know with confidence that it could be done.

These three factors of simplification of method, continuous innovation and a highly developed set of skills reduced the amount of communication and intervention required to manage the project. This work environment is analogous to our contemporary empowered teams, in that if an organization adopts a process orientation to business, worker education is integral to achieving the desired levels of output. Considering the complex nature of managing a medieval building project, which included locating raw materials, coordinating logistical activities, managing large workforces consisting of professional guilds and common labourers and in many cases providing foodstuffs, the medieval master builder was faced with a daunting task. In the case of building a castle in unfamiliar land, his responsibilities were often expanded to include developing living quarters and sometimes building an entire town with infrastructure to ensure continuous progress on the structure. This ability to manage people, process and materials, often at breakneck speeds (castles were needed for immediate protection whereas cathedrals were longer term building projects), brings to mind one central question: What did medieval builders know about project management that we do not know today? Since medieval builders were unaided by a computer or calculator and rarely used paper, did they possess a knowledge of project management and logistical coordination that may have been lost when society shifted to the assembly-line compartmentalization approach to projects? One could argue that like the disappearance of the knowledge of concrete for thirteen centuries, master masons operating in the later medieval periods may have developed and possessed an in-depth knowledge of process-based project management that is no longer present in today’s society.

Jeff Morgan, of the UK division of Computer Sciences Corporation (CSC), argued in the mid-1990s that project management needed to make a radical shift from a traditional, hierarchical model-tracking project activity towards a model focused on interpreting events and processes.^[58] The simplicity of his argument is the genius of its design, stating that the management of a project is a set of processes connected by events in which each event characterizes a decision point in which the project manager must choose a course of action with regard to what is to be done to manage the consequence of the event. Similar to medieval building construction, Morgan describes projects as five processes running at the same time: preparation, production, improvement, acceptance and closure. Each of these is driven by events internal and external to the business and is directly part of an elementary process within the business. Projects are initiated to improve, alter or eliminate existing business processes or process components. These activities in and of themselves spawn the five processes typically called a project.

The Morgan event-process view of project management brings into focus the fact that organizations continuously spawn projects within themselves as a mechanism for improvement. These projects are often considered as one-time events and are not typically reviewed holistically as a process within a process of business. Morgan’s argument is further reinforced by the fact that all organizations regardless of size have some form of project or projects occurring continuously. Few companies – if any – simply establish business processes and execute them without forming some type of project that brings together resources across the firm. Therefore, it can be demonstrated that a project concerning organizational improvement is an elementary business process in its own right, and it can be surmised that the process of project management is misnamed, because projects themselves viewed holistically represent the transformation of the business in direct response to changes in the competitive environment. The major criticism of technology projects today is that the majority of them never reach completion. This could be because business is not a static process but a continuous one. One could argue that the reason technology projects are never completed is because unless the business stops they cannot reach completion.

Morgan’s point is that the traditional command and control structure of project management – which views scheduled activities as interdependent segments of discrete work – fails to incorporate the dynamic nature of organizational interruption and the root causes of the interruption event. The causality of events is often unrelated to the project until it interrupts the resources that have been allocated to it. Morgan’s event-process view anticipates these events, and their execution is guided by the objectives of the underlying business processes, thereby giving the project a dynamic ability to adapt as internal and external events alter the balance of resources.

The dynamic nature of Morgan’s event-process approach to project management requires a shift in thinking in the fundamentals of the dynamics in managing a project. Akin to the crux of Galileo’s applied method of compounded motion, which as a means to express a compound phenomenon (such as a moving cannonball using a coordinate grid system) enlightens us to the fact that each plotted point does not represent any particular object itself, but a body’s position at a given time. Morgan’s point is simple; progress on a project is relative to the progression of the company towards reaching its objectives. Individual technology projects are in a state of motion that should be assessed along two dimensions: the progress towards the initial objective of the project and the value of the relative motion of the initial objective as it alters due to changes in the business environment. Hobart and Schiffman describe Galileo’s cannonball motion as:

Unpacking the relational information contained in a point or equation will require, henceforth, devising the formula that captures the relations actually existing between phenomena.^[59]

Therefore, the event-process view of project management assesses, monitors, measures and takes corrective action on the relative movement of the project, not the consumption of resources by individual tasks. This method anticipates the dynamic nature of change and reduces or eliminates the validity of traditional project-management methodologies such as percent complete. What Morgan has revealed is that corporate objectives change as market conditions influence customers, suppliers and other stakeholders within the company. Technology projects fall victim to changes in objectives that are not incorporated into projects once they commence. The changes in corporate objectives coupled with the continuous changes in technology create a condition of a ‘project drifting off course’, which in many cases is undetectable until it has already gained momentum. The traditional methods of project management measure these movements in a formalized structure that responds in a reactive sense, hampering a project manager’s ability to take corrective action in a timely manner. The contemporary techniques of project monitoring and feedback are analogous to driving a car by looking in the rear view mirror and do not incorporate the dynamic nature of the motion between market-influenced corporate objectives and technological advancement. Taking an event-process approach to a project places the project manager at the heart of a problem which is the events that shape and reshape the project as it occurs dynamically. Therefore, the event-process method provides the project manager with a mechanism to control the project’s relative rate using proactive and reactive actions. Clearly, the success of this method lies in the organization’s design and the education of people on projects using this kind of thinking.

The event-process method may be the way in which cross-cultural, geographically dispersed projects can be effectively managed, since its notion of time as a relative event allows projects to be executed simultaneously and, by leveraging technology, across time zones. This method can be adapted to manage projects with a wide variety of talent pools such as found in new global partnerships because it focuses on the objective and not the organization. Cleland describes the environment in which the event-process method may eventually find its value proposition:

The formation of a joint borderless project team involves bringing people together who represent the different disciplines of the partners cooperating in the venture. A true intercompany and international project team is formed and organized. The intent of the project team, in accomplishing the objectives of the joint effort, tends to rise above the parochial interest of any of the members.^[60]

New techniques such as event-process project management require organizations to unlearn the concepts and ideas that are considered fundamental building blocks of our corporate knowledge. Technology is changing our organizations, influencing our jobs and reshaping our business processes. Contemporary firms have traditionally compartmentalized job functions, effectively confining individuals into narrowly defined responsibilities requiring little knowledge beyond their own operating group. Concepts such as Hammer’s process orientation and Morgan’s event-process methodology demand that individuals develop a knowledge base that encompasses the entire process, similar to that of a medieval mason, who knew every facet of stonework. The goal is for people to develop an understanding of how their individual efforts contribute to the process as a whole. What is different today is the fact that ‘No corporate father figure will take care of you’ says Hammer. ‘The feudal corporation – managers and workers in a lord-liege relationship – is gone forever. The person that the process-centred organization ultimately cares about is the customer.’^[61] The transition that firms must make is to develop customer-centric processes, the trademark of early dot-com firms.

Hammer makes a key observation that in part explains the rapid rise of the entrepreneurial dot-com start-ups: ‘Small companies can’t afford the compartmentalization and specialization that cripple our holistic cognitive capabilities.’^[62] The opportunity for large organizations with traditionally designed process is to rethink the application of technology as they redefine the process. Complicating the transition toward a process focus is the typical approach that organizations use to applying technology, which in many cases has the effect of ‘dumbing down’ the organization to the lowest common denominator in the firm. To summarize one of Hammer’s lectures, an organization is typically composed of two kinds of people, in many cases a single founder or group of founders with an intensly specialized knowledge such as engineering, manufacturing or biotechnology, who then hire a group of administrative people with general skills. Wary of the quality of the second group, software designers (both in-house and professional software package designers) develop applications to ensure that the actions of controlling the process of the business are comprehensive enough so that no individual can accidentally create a transaction that will damage the entire production cycle. They basically strive to make the software system ‘idiot-proof’, designing the applications for the least capable individual in the firm, in essence lowering the capabilities of the entire organization to the lowest common denominator. Hammer argues, and rightly so, that computer software should be designed as if the founders were performing these tasks, thereby raising the effective knowledge of the firm to a higher level.

Unfortunately, when applying technology to communicate or educate large groups of people, the tendency is to continue this process of technological dumbing down as can be reconfirmed by watching television. This continual process, which could be called the misapplication of technology, and its effects on the corporate consciousness is at the centre of the conflict between the reinvention of bureaucratic structures and developing a process orientation.

In this chapter I do not intend to develop a definitive guide to fixing, eliminating or restructuring corporate bureaucracies; I will, however, discuss the many facets of bureaucratic thinking and the pitfalls of traditional organizational structure as it relates to the incorporation of technology into a firm’s value proposition. In short, technology provides organizations with capabilities; the people in the organization make things possible. When applied to business processes such as customer services, technology gives way to new opportunities in process performance. When applied to bureaucracies, technology can make a small company appear large, ‘teach an old dog new tricks’ and, in many cases, upset the proverbial apple cart of corporate tranquillity.

^[56]See F. M. Lea, The Chemistry of Cement and Concrete (New York: St. Martin’s Press, 1956), Chapter 1.

^[57]F. Andrews, The Medieval Builder and His Methods (New York: Dover, 1999) p. 8.

^[58]See J. Morgan. ‘Event-Process View of Project Management’ Computer Sciences Corporation, UK Division (1995).

^[59]M. Hobart and Z. Schiffman, Information Ages: Literacy, Numeracy and the Computer Revolution (Baltimore: Johns Hopkins University Press, 1998) p. 134.

^[60]D. Cleland, ‘Borderless Project Management’. In D. Cleland and R. Gareis (eds) Global Project Management Handbook (New York: McGraw-Hill, 1996) p. 10.

^[61]M. Hammer, Beyond Reengineering: How the Process-Centered Organization is Changing Our Work and Our Lives (London: HarperCollins, 1998) pp. 238–9.

^[62]M. Hammer, Beyond Reengineering: How the Process-Centred Organization is Changing Our Work and Our Lives (London: HarperCollins, 1998) p. 234.