Tag Archive: art

Why Many Projects Go so Terribly Wrong

“Management is essentially an art and, as a manager, you need to learn continuously about your situation. You can do this by studying yourself and the way in which you carry out your work. This is termed ‘reflective practice’.”
[Lawless and Stapleton, 2004]

The software development success rate published in the Standish Group’s Chaos Report is among the most commonly cited research in the IT industry. Since 1995, the Standish Group has reported rather abysmal statistics — from a rate of roughly one-in-six projects succeeding in 1995 to roughly one-in-three projects today. Other surveys like the ones from TechRepublic Inc. (a subsidiary of Gartner Group) are of the same tenor. Although these surveys list project success/failure factors (like realistic schedules, budgeting, leadership of the project manager, etc.) and other interesting data, they do not question the underlying problems responsible for the failures.

Experience with contemporary project management courses and presentations in my country leave me with the impression that management problems can be wrapped into neat technical working packages (Raelin, 1995). If students are left with this impression, they may be unable to transform knowledge gained in one context to another (Reilly, 1982), as this form of learning is done individually and in private (Pleasants, 1966; Polanyi, 1966; Reber, 1993). Hence, if this is the kind of project management knowledge these courses produce, there is no surprise in high project failure rates.

In a wider context, the situation reflects an ongoing discussion about the use of management education in management practice (Hayes and Abernathy, 1980; Cheit, 1985), highlighted by Mintzberg’s scepticism (1996 and 2004) who “was finding too much of a disconnect between the practice of managing […] and what went on in classrooms” (2004, p. ix) and even claims that formal management education is hampering good management practice and therefore the economy. The objections are manyfold:

  • Formal management education separates learning from practice

Education programmes may leave students with the impression that management problems can be packed into neat technical entities (Raelin 1994, p. 303), whereas only later they detect the realities of power and politics at their workplace. Raelin and Coghlan (2006) take the view that formal educational programs often miss opportunities to use the rich experiences of working managers to produce both learning and knowledge.

  • Formal management education is inappropriate to real world settings and therefore to management practice

Reilly (1982) questions whether graduates can think independently, function without sufficient data, change their approach in the course of action, negotiate, and continually reflect and inquire. Cheit (1985) summarises that management programmes have failed to meet society’s needs.

  • (Project) managers cannot be developed in classrooms

It is commonly accepted that experience forms the basis for knowledge (Raelin and Coghlan, 2006). Mintzberg (1973) argues that managers learn in their day-to-day enactment of their managerial roles. Where courses have reportedly made an impact, they have given insight through direct application to real-life issues (McCall et al., 1988).

There are always values at stake in management practice: time, money, people with their hidden agendas and salience, clients, etc. – whereas management techniques infiltrated in sterile classroom settings are free from these pressures. There is nothing wrong about learning certain topics, like corporate finance, in a traditional classroom setting. However, Mintzberg’s (1996) critique goes beyond the teaching of technical subjects in formal management education. If the tacit or implicit knowledge in management practice is not converted into explicit knowledge (Nonaka and Takeuchi, 1995) underpinned by theory, managers are unable to develop a cohesive explanation of their skills (Viljoen et al., 1990). For example, there is no single approach to project management that is best in all circumstances; managers need to adapt their approach to the requirements of different situations. This is called the contingency approach to management (Lawless and Stapleton, 2004).

This likely supports the notion that tacit knowledge distinguishes successful from unsuccessful managers (Argyris 1999), and that tacit knowledge is a product from experience in the real world (Nonaka and Takeuchi 1995), not in the protected realm of theory in classrooms. It is a tangible experience for most managers that management learning does not exclusively happen in classrooms, but on the job (Dawes et al. 1996). Additionally, management learning happens through working with others while all engage in real-life problems (Revans 1971). As Raelin et al. (2006) put it aptly:

“Experiencing itself is not knowledge but is a constitutive element of knowledge. Experiencing needs to be accompanied by some sort of inquiry into experience, an inquiry that seeks to frame meaning and judgments and that leads to thoughtful action.”

This may boil down to the notion that project management is not a profession, but an occupation. Professionalism is supported by education, and real expertise is built through formal reflective practice, also referred to as triple-loop learning (Raelin and Coghlan, 2006).

Understanding Technology

There are various meanings that help to analyse technology. In modern common usage, the word ‘technology’ essentially means ‘kit’, which is to say technology as artefact (product). This refers to made objects, and also to what they do (examples in table below). This usage of the word is quite recent. Dictionaries – which tend to lag behind common usage – almost all define technology as a body of knowledge and practice, for example “a particular practical or industrial art” (Oxford English Dictionary). Past definitions have distinguished other categories, namely technology as knowledge and technology as mode of enquiry and action. These meanings are different ways of understanding technology. They can be conceptualised as a dependent series: There can be no artefact without action, no technological action without knowledge, and no knowledge without enquiry. This implies that two sets can create meaningful combinations, such as “application knowledge”, or “product mode of enquiry” (Fowles, 2005).

Artefact Knowledge Mode of enquiry and action
Application Formulation, symptom relief Diagnostic indications Clinic trials
Writing electronically Observing office work Prototyping, software development
Product Bio-active ingredients, systemic effects Molecular structure Systematic search for and analysis of medical plants
Word processor Convert keyboard keys to strings Developing software modules for communication
Production Fermentation and fermenters Drug testing and approval system Process improvement
Compilers, assemblers Software engineering Understanding software development and quality standards

Table 1: Meanings of technology and examples for medicine and IT

Knowledge is not easy to picture: Although knowledge is sometimes written down, very often it resides only in people (Nonaka and Takeuchi, 1995). Let’s consider the assembly line in a car fabric: It implies product knowledge of the design of car bodies – such as the arrangement of parts, the suitability of materials etc. It also implies production knowledge of the organisation of an assembly line and the manner and sequence in which parts are fitted. Some of these were important subjects at certain points in the technology’s life cycle. We can imagine business conditions, such as a high rate of change and degree of complexity, where production knowledge creation, using a “continuous improvement” method such as ‘Kaizen’ (Imai, 1986), would be an essential part of an organisation’s technology strategy as product performance.

The mode of enquiry and action refers to technological method. It is what develops a technology as time passes. R&D is a prime example. More generally, it is a way of doing things that is concerned with observation, problem solving, inventing, improving, management of change, etc. Here are some guidelines on categorisation (Fowles, 2005):

  • Application mode of enquiry and action might be trial and error to see how a technology is best used, sited, etc.
  • Application knowledge would include knowledge of use, siting, maintenance…
  • Application artefacts comprise the framework within which a technology is ultimately used. The framework might include ancillary mechanisms to improve performance, such as guidance for users.
  • Product mode of enquiry and action might be a particular approach to R&D.
  • Product knowledge is about architecture and design, e.g. the arrangement of components in a successful working entity.
  • Product artefacts include the product as delivered and component technologies within it, and the effects they have.
  • The production mode of inquiry and action might be a particular approach to process improvement.
  • Production knowledge is about the systems of operation and control, craft practices etc.
  • Production artefacts are the organisations, structures and tools that enact these systems and practices, and the effects they have.