Eight to Late

Introduction

Over the last two decades or so, it has been recognized that creativity and innovation tend to thrive in organisations  where employees have a say in decisions that affect their work.  This has lead to the notion of a post-bureaucratic organisation –  an organisation in which decisions are made collectively through dialogue and consensus, and where  the hierarchy is flat.  Although a number of workgroups within large organizations function this way (and with some success too),  a post-bureaucratic organisation is generally seen as a utopian and academic ideal; one that is  unlikely to work in the real world. Those who manage  organizations, departments or workgroups  are generally uncomfortable with employees working autonomously,  even though this might lead to the generation of novel ideas and products.  This is understandable: it is ultimately the responsibility of managers to ensure that  organisational or departmental goals are achieved. How else to do this but through the time-tested command and control approach to management?

In response to the question posed above, project management is often touted as a means to manage creative and innovative efforts in organisations (see some of the articles in this issue of PM Network, for example).  The claim seems a reasonable one: project management (by definition) provides a means to manage  collective, goal oriented endeavours. Further, many projects – especially those involving  new product or software development – have a creative/innovative component. In practice, though, project management tends to be a bureaucratic affair;  involving plans that must be followed, schedules that must be adhered to and regular progress reports that must be made. Even so (or perhaps, because this is so) many organizations see project management as a means to manage all creative work in a post-bureaucratic setting.  Implicit in this view is the assumption that the implementation of project management processes will  enable managers to control and direct creative work without any adverse side-effects.  An article by Damian Hodgson entitled Project Work: The Legacy of Bureaucratic Control in the Post-Bureaucratic Organisation, explores the tensions and contradictions presented by this notion. Although the article was written a while ago (in 2003), I believe the ideas explored in it are ever more relevant today, particularly in view of the increasing projectisation of organisations and the work carried out within them.  Hence my motivation to  summarise and review  the paper.

Background – setting the stage

To be fair, many organizations recognise that a “light hand on the rudder” is needed in order to encourage creativity and innovation.  In these organisations, project management is often seen as a means to achieve this.  But  how well does it work in practice? Hodgson’s paper aims to provide some insight into this question via a case study of an organization in which a project-based form of management was implemented as a means to balance the  requirements of creativity and control. In his words:

In response to the challenges of the post-bureaucratic form, project management has  been put forward by many as a ‘tried-and-tested’ package of techniques able to cope with discontinuous work, expert labour and continuous and unpredictable change while delivering the levels of reliability and control of the traditional bureaucracy. In this article I explore some of the contradictions and tensions within a department where such a ‘hybrid’ mode of control is implemented, embodying both bureaucratic and post-bureaucratic logics. In particular, I focus upon the discursive tactics employed to sell ‘rebureaucratization’ as ‘debureaucratization’, and the complex employee responses to this initiative. I argue that the tensions evident here cast significant doubt on the feasibility of a seamless integration of bureaucracy and the post-bureaucratic [organization].

The “discursive tactics” that Hodgson mentions to are (seemingly reasonable and rational) arguments that an organization might use to “sell” the idea that the methods and approaches of project management are consistent with the ideals of a post-bureaucratic organization. An example of such an argument goes as follows: project management is routinely used to manage new product development projects, so it is eminently suited to managing creative work (Incidentally,  this isn’t quite right – see this paper review for more on why)

Post bureaucracy vs. bureaucracy

Before moving on, it is worth comparing the characteristics of bureaucratic and post-bureaucratic organizations. Hodgson provides the following comparison, drawn from Hekscher’s work:

Bureacracy	Post-bureaucracy
Consensus through Acquiescence to Authority	Consensus through Institutionalized Dialogue
Influence based on Formal Position	Influence through Persuasion/PersonalQualities
Internal Trust Immaterial	High Need for Internal Trust
Emphasis on Rules and Regulations	Emphasis on Organizational Mission
Information Monopolised at Top of Hierarchy	Strategic Information shared in Organization
Focus on Rules for Conduct	Focus on Principles Guiding Action
Fixed (and Clear) Decision Making Processes	Fluid/Flexible Decision Making Processes
Network of Specialized FunctionalRelationships	Communal Spirit/Friendship Groupings
Hierarchical Appraisal	Open and Visible Peer Review Processes
Definite and Impermeable Boundaries	Open and Permeable Boundaries
Objective Rules to ensure Equity of Treatment	Broad Public Standards of Performance
Expectation of Constancy	Expectation of Change

The aim of the case study is to highlight some of the inconsistencies and contradictions that result from applying a bureaucratic mechanism (project management) to manage the work of a group that was very good at doing creative work, but was used to a more free-wheeling, hands-off management style (i.e. a group which approximates the idealised post-bureaucratic environment described above).

Why project management?

Project management has its roots in classical management (ala Taylor and Fayol), so it is perhaps  surprising that it is considered as a means to manage work in a post-bureaucratic setting. In Hodgson’s words:

I would argue that what distinguishes project management as of particular relevance to 21stcentury organizations is its rediscovery of a very 19th-century preoccupation with comprehensive planning, linked to a belief in the necessity of tight managerial discipline.

Project management tools and techniques support managerial discipline by providing means to decompose the project into manageable bits – by using a WBS say – and then assigning these bits to individuals (or small teams). The work assigned can then be tracked and controlled tightly – which is a good thing.  If the matter rested there it wouldn’t be too bad, but very often management also prescibes how the work should be done. This level of control results in a loss of autonomy (and motivation)  for team members whose job it is to do the work. The loss of motivation can have negative effects, especially in projects with a large creative component.  To counter this criticism, in recent years project management has started to focus on the creative aspects of projects – what’s needed to motivate teams, how to foster creativity (in new product development work, say) etc. As Hodgson puts it,

The linking of project management and change management has increased project management’s influence across industries, such that now the largest professional organization in project management includes special interest groups in areas as diverse as healthcare, retail, media, marketing, and hospitality. As a consequence the last decade has been a time of particularly rapid expansion for project management, as issues of change, knowledge management, and constant innovation emerged as central themes in popular management discourse.

So, project management offers two (seemingly contradictory) benefits: the ability to maintain tight control of work and the ability to foster innovation and creativity:

…project management can be seen as an essentially bureaucratic system of control, based on the principles of visibility, predictability and accountability, and operationalized through the adherence to formalized procedure and constant written reporting mechanisms. At the same time, however, project management draws upon the rhetoric of empowerment, autonomy and self-reliance central… In principle, then, project management offers a system which attempts to integrate bureaucratic control and a form of responsible autonomy more in keeping with the interdisciplinary, knowledge-intensive nature of much project work in teams.

Seen in this light, it is perhaps not so surprising that project management is viewed as a means to manage creative work.

The case study

With the above background done, I now move on to a discussion of the case study.  In Hodgson’s words, the study:

…focused upon  a telephone bank in northern England which I have referred to under the pseudonym Buzzbank. In the late 1980s, Buzzbank had been set up by a major UK bank, which I will call TN Banking, and represented one of several success stories in the retail banking sector over this period. Through reduced overheads and the extensive use of new technology in the form of sophisticated marketing techniques and call-centre technology, Buzzbank had expanded rapidly in terms of market share and turnover, developing into a key component of TN Banking’s global operations. My interest in particular centred on Buzzbank senior management’s identification of project management as the prime ‘critical success factor’ for the organization; the development of project management expertise throughout the organization was seen as a key priority to maintain performance into the next decade. To an extent, the project teams researched could scarcely be more ‘cutting edge’, representing highly-trained ‘knowledge workers’ developing innovative high technology applications and solutions in a new sector of an enormously profitable industry

Hodgson conducted interviews and observed operations within the IT department of Buzzbank over a period of two years. During this period, the organization was implementing a “strategic plan” aimed at formalizing innovation and creative work using project management processes. The idea, in the words of a couple of senior IT managers was to “bring a level of discipline” and “bring an idea of professional structuring” to the work of the highly successful unit. The structuring and discipline was to be achieved by implementing project management processes.

The main rationale used to sell project management to the Buzzbank IT team is a familiar one: the need to ensure predictability and repeatability of work done whilst ensuring that innovation and creativity would not be impeded. Another justification offered by management was that the size of the organization (which had grown considerably in the years prior to the implementation of the strategic plan) meant that  the existing “ad-hoc” work culture would no longer be successful. That is,  the size of the organization necessitated a degree of formalization,  ergo bureaucratic procedures had to be put in place. This was rationalised  (by senior management) as a natural and inevitable consequence of growth:

…The organization was therefore portrayed by senior management in IT as approaching its ‘next stage of evolution’. The immediate benefit of such a metaphor for those members of senior management charged with rebureaucratizing the organization is that it carries a very strong sense of inevitability. As such, it casts opposition to such changes as irrational and futile, standing in the way of natural ‘evolution’.

Further, managers in the organization dubbed any employee resistance as “natural growing pains” – like those of an adolescent, say. Cast in this light, dissenting viewpoints were portrayed as natural and unavoidable – and possibly even necessary – but ultimately without any validity.

Another interesting aspect that Hodgson highlights is the way in which old practices (the successful but “bad” ones) were subsumed in the new (formal) framework. For example, in the old world, employees were given the freedom to experiment, and many considered this as a strength not a weakness. In the new world, however, such a practice was seen as a threat; it was considered more important to capture how to do things correctly so that things became repeatable (ala best practice) and experimentation would not be necessary. As one manager put it:

If we capture how we do things right, at least it makes things repeatable, and we can record the improvement required when things don’t go right, which doesn’t happen in a rapidly-expanding, gung-ho environment.

Hodgson notes that the terms rapidly-expanding and gung-ho, which are used in a negative sense, could just as well be cast in positive terms such as  flexible, proactive etc. The point being that management framed the existing situation in terms that made the implementation of the new procedures seem like a logical and reasonable next step. The processes were touted as a means to achieve change (i.e. be flexible), but in a controlled way. So, management went to great lengths to avoid use of terms that would be perceived as being negative – for example, the term “structure” was used instead of “bureaucracy” or “formalization.” In this way, management attempted to assimilate the existing values of Buzzbank into the strategic plan.

So, how well did it work? Here’s what Hodgson says about the end result:

The impression given [by senior management] was that of an organizational change which was inevitable, which gave rise to some understandable but irrational resistance, and which had now been effectively completed, for the good of the organization as a whole.

On the other hand, the impression Hodgson got from speaking to lower level employees was very different:

However, in the time spent by myself in the organization, the tone and target of much of the humour, as well as much stronger reactions, appeared to throw doubt on the extent to which this discourse had permeated among the general employees, particularly within the IT department. Humour was commonplace in the everyday banter both within teams and between teams in the IT division at Buzzbank, and the increasing levels of bureaucratization was the butt of most of the humour, particularly at the lower levels of the hierarchy. The main experience of project management as reported by many  Buzzbank employees was one of intensified bureaucratic surveillance…

A key example is the reaction of employees to managerial jargon that was used in company circulars and literature intended to promote the strategic plan.

Typically, comments were provoked by the circulation of literature on the strategic plan, and again, excerpts of the document were read out by members of staff, adding ironic comments to underline the gap between the document and their experience of life and work in the department.

Hodgson notes that employees often appeared to comply with the new regulations, but not in the way intended by management:

At other times, the employees appeared to comply with the formal requirements of the new system, in terms of filling in the necessary forms, reporting in at given times, completing the necessary work-logs and so on. Even here, despite the relative sophistication of senior management’s re-articulation of key discourses, compliance on the part of Buzzbank employees in many cases bore all the hallmarks of instrumental behaviour, accompanied by insubordinate statements and humour ranging from the cynical to the confrontational. At other times, assurances were given to senior management and immediately contravened, fictionalized accounts of project activities were submitted late, or else procedures were observed meticulously to the detriment of deadlines and other constraints. The emergent organizational order was a precarious negotiation between alienated compliance and an autonomous disregard for bureaucratic demands…

In short: there was a clear gap between the perceptions of management and employees as to the success of the newly implemented processes.

It is clear that Buzzbank managers saw  project management as  a means to control and direct creative / innovative work in a way that would have no negative effect on employee morale and motivation.   The challenge, of course, lay in achieving employee buy-in.  Management used many creative (!) tactics to “sell” project management to staff. These included:

1. References to a “natural process of evolution” and the consequent “growing pains” that the organization would experience. This made the pain of the change natural and inevitable, but necessary in the interest of future gain.
2. Manipulation of terminology to make the changes seem more palatable – e.g. using the word “structure” instead of “formalization” or “bureaucracy”.
3. Co-opting terminology of post-bureaucratic organizations into literature designed to promote the new structure. For example, claiming that project management processes would enable the organization to be even more responsive to change (i.e. flexible), through change management processes.

From employees’ perspective, such techniques were plainly seen for what they were: methods to “sell the unsellable”. The negative reactions of employees were manifested through sarcastic humour and (often minor) acts of insubordination. The case study thus highlights the difficulties in using project management as a means to control work in a post-bureaucratic work environment.

Wrapping-up: reflections and summary

Hodgson sees the case study as exemplifying the problem of control vs. autonomy in emerging post-bureaucratic organizations:  managers view project management as a means to address the risks inherent in post-bureaucratic work, whereas employees view it as a unnecessary and unjustified imposition. Management was looking for the “best of both worlds”, a hybrid model that incorporated the best elements of a post bureaucratic model and a traditional command and control approach. The case study casts doubt on whether such a hybrid is possible solely through the implementation standard project management techniques and processes. It does so by exposing some of the tensions and differences in perceptions that can occur when such a model is implemented.

So where does this leave managers? Is there a way to manage creative work without destroying employee morale and motivation?

Looking over the complaints of the Buzzbank employees, it is clear that most of the problems arose from the loss of autonomy that they had enjoyed prior to the implementation of the new processes. This being the case, any measure to increase autonomy should improve the situation. A couple of possibilities come to mind – both of which I have discussed in earlier pieces. These are:

1. Empower employees to make decisions that affect their work. This means allowing them the freedom to decide the best approach to solving problems (within limits specified by organisational and resource constraints).
2. In situations where (1) isn’t possible, one could use collaborative techniques such as dialogue mapping to achieve employee buy-in. Of course, management has to be prepared to engage in true dialogue, and be willing to act upon (reasonable) suggestions made by employees.

The key message is simple and obvious: the more of say employees have in making work-related decisions, the more engaged and motivated they’ll be. This is not just a warm and fuzzy notion, but one that is backed up by research on motivation (see this paper review, for example). Yes, this does mean letting go of the “reins of control” to an extent but it is clear, as highlighted by Hodgson’s work, that holding the reins tightly might cause more problems that it solves. What’s called for, above all, is a degree of flexibility:  use project management processes by all means, but be open to employee input as to what’s working well and what’s not.

To sum up:  Hodgson’s case study suggests that inflexible project management based approaches to managing creative work  may not work as well as advertised by purveyors of frameworks and methodologies. As an alternative,  it might be worth taking a step towards the utopian ideal of a post-bureaucratic organisation  by using techniques that encourage employee input in organisational decision making.

Introduction 

Conventional approaches to knowledge management on projects focus on  the cognitive (or thought-related) and mechanical  aspects of knowledge creation and capture. There is alternate view, one which considers knowledge as being created through interactions between people who –  through their interactions -  develop mutually acceptable interpretations of theories and facts in ways that suit their particular needs. That is, project knowledge is socially constructed. If this is true, then project managers need to pay attention to the environmental and social factors that influence knowledge construction.  This is the position taken by Paul Jackson and Jane Klobas in their paper entitled, Building knowledge in projects: A practical application of social constructivism to information systems development, which presents a  knowledge creation / sharing process model based social constructivist theory. This article is a summary and review of the paper.

 A social constructivist view of knowledge

Jackson and Klobas begin with the observation that engineering disciplines are founded on the belief that knowledge can be expressed in propositions that correspond to a reality which  is independent of human perception.  However, there is an alternate view that knowledge is not absolute, but relative – i.e.  it depends on the mental models and beliefs used to interpret facts, objects and events. A  relevant example is how a software product is viewed by business users and software developers. The former group may see an application in terms of its utility whereas the latter may see it as an instance of a particular technology. Such perception gaps can also occur within seemingly homogenous groups – such as teams comprised of software developers, for example. This can happen for a variety of reasons such as the differences in the experience and cultural backgrounds of those who make up the group. Social constructivism looks at how such gaps can be bridged.

The authors’ discussion relies on the work of Berger and Luckmann, who described how the gap between perceptions of different individuals can be overcome to create a socially constructed, shared reality. The phrase “socially constructed” implies that reality (as it pertains to a project, for example) is created via a common understanding of issues, followed by mutual agreement between all the players as to what comprises that reality. For me this view strikes a particular chord because of it is akin to the stated aims of dialogue mapping, a technique that I have described in several earlier posts (see this article for an example relevant to projects).

 Knowledge in information systems development as a social construct

 First up, the authors make the point that information systems development (ISD) projects are:

 …intensive exercises in constructing social reality through process and data modeling. These models are informed with the particular world-view of systems designers and their use of particular formal representations. In ISD projects, this operational reality is new and explicitly constructed and becomes understood and accepted through negotiated agreement between participants from the two cultures of business and IT

 Essentially, knowledge emerges  through interaction and discussion   as the project proceeds.  However, the methodologies used in design are typically founded on an engineering approach, which takes a positivist view rather than a social one. As the authors suggest,

Perhaps the social constructivist paradigm offers an insight into continuing failure, namely that what is happening in an ISD project is far more complex than the simple translation of a description of an external reality into instructions for a computer. It is the emergence and articulation of multiple, indeterminate, sometimes unconscious, sometimes ineffable realities and the negotiated achievement of a consensus of a new, agreed reality in an explicit form, such as a business or data model, which is amenable to computerization.

With this in mind, the authors aim to develop a model that addresses the shortcomings of the traditional, positivist view of knowledge in ISD projects. They do this by representing Berger and Luckmann’s theory of social constructivism in terms of a knowledge process model. They then identify management principles that map on to these processes. These principles form the basis of a survey which is used as an operational version of the process model. The operational model is then assessed by experts and tested by a project manager in a real-life project.

The knowledge creation/sharing process model

The process model that Jackson and Klobas describe is based on Berger and Luckmann’s work.

The model  describes how personal knowledge is created – personal knowledge being what an individual knows. Personal knowledge is built up using mental models of the world – these models are frameworks that individuals use to make sense of the world.

According to the Jackson-Klobas process model, personal knowledge is built up through a number of process including:

 Internalisation: The absorption of knowledge by an individual

 Knowledge creation: The construction of new knowledge through repetitive performance of tasks (learning skills) or becoming aware of new ideas, ways of thinking or frameworks. The latter corresponds to learning concepts and theories, or even new ways of perceiving the world. These correspond to a change in subjective reality for the individual.

 Externalisation: The representation and description of knowledge using speech or symbols so that it can be perceived and internalized by others. Think of this as explaining ideas or procedures to other individuals.

 Objectivation: The creation of a shared constructs that represent a group’s understanding of the world. At this point, knowledge is objectified – and is perceived as having an existence independent of individuals.

 Legitimation: The authorization of objectified knowledge as being “correct” or “standard.”

 Reification: The process by which objective knowledge assumes a status that makes it difficult to change or challenge. A familiar example of reified knowledge is any procedure or process that is “hardened” into a system – “That’s just the way things are done around here,” is a common response when such processes are challenged.

  The links depicted in the figure show the relationships between these processes.

 Jackson and Klobas suggest that knowledge creation in ISD projects is a social process, which occurs through continual communication between the business and IT. Sure, there are other elements of knowledge creation – design, prototyping, development, learning new skills etc. – but these amount to nought unless they are discussed, argued, agreed on and communicated through social interactions. These interactions occur in the wider context of the organization, so it is reasonable to claim that the resulting knowledge takes on a form that mirrors the social environment of the organization.

 Clearly, this model of knowledge creation is very different from the usual interpretation of knowledge having an independent reality, regardless of whether it is known to the group or not.

 An operational model

 The above is good theory, which makes for interesting, but academic, discussions. What about practice? Can the model be operationalised?  Jackson and Klobas describe an approach to creating to testing the utility (rather than the validity) of the model.  I discuss this in the following sections.

 Knowledge sharing heuristics

 To begin with, they surveyed the literature on knowledge management to identify knowledge sharing heuristics (i.e. experience-based techniques to enable knowledge sharing).  As an example, some of the heuristics associated with the externalization process were:

• We have standard documentation and modelling tools which make business requirements easy to understand
• Stakeholders and IS staff communicate regularly through direct face-to-face contact
• We use prototypes

 The authors identified more than 130 heuristics. Each of these was matched with a process in the model. According to the authors, this matching process was simple: in most cases there was no doubt as to which process a heuristic should be attached to. This suggests that the model provides a natural way to organize the voluminous and complex body of research in knowledge creation and sharing. Why is this important? Well, because it suggests that the conceptual model (as illustrated in Fig. 1) can form the basis for a simple means to assess knowledge creation / sharing capabilities in their work environments, with the assurance that they have all relevant variables covered.

 Validating the mapping

 The validity of the matching was checked using twenty historical case studies of ISD projects. This worked as follows: explanations for what worked well and what didn’t were mapped against the model process areas (using the heuristics identified in the prior step). The aim was to answer the question:   “is there a relationship between project failure and problems in the respective knowledge processes or, conversely, between project success and the presence of positive indicators?” 

 One of the case studies the authors use is the well-known (and possibly over-analysed) failure of the automated dispatch system for the London Ambulance Service.  The paper has a succinct summary of the case study, which I reproduce below: 

The London Ambulance Service (LAS) is the largest ambulance service in the world and provides accident and emergency and patient transport services to a resident population of nearly seven million people. Their ISD project was intended to produce an automated system for the dispatch of ambulances to emergencies. The existing manual system was poor, cumbersome, inefficient and relatively unreliable. The goal of the new system was to provide an efficient command and control process to overcome these deficiencies. Furthermore, the system was seen by management as an opportunity to resolve perceived issues in poor industrial relations, outmoded work practices and low resource utilization. A tender was let for development of system components including computer aided dispatch, automatic vehicle location, radio interfacing and mobile data terminals to update the status of any call-out. The tender was let to a company inexperienced in large systems delivery. Whilst the project had profound implications for work practices, personnel were hardly involved in the design of the system. Upon implementation, there were many errors in the software and infrastructure, which led to critical operational shortcomings such as the failure of calls to reach ambulances. The system lasted only a week before it was necessary to revert to the manual system.

 Jackson and Klobas show how their conceptual model maps to knowledge-related factors that may have played a role in the failure project. For example, under the heading of personal knowledge, one can identify at least two potential factors: lack of involvement of end-users in design and selection of an inexperienced vendor. Further, the disconnect between management and employees suggests a couple of factors relating to reification: mutual negative perceptions and outmoded (but unchallenged) work practices.

 From their validation, the authors suggest that the model provides a comprehensive framework that explains why these projects failed. That may be overstating the case – what’s cause and what’s effect is hard to tell, especially after the fact. Nonetheless, the model does seem to be able to capture many, if not all, knowledge-related gaps that could have played a role in these failures. Further, by looking at the heuristics mapped to each process, one might be able to suggest ways in which these deficiencies could have been addressed. For example, if externalization is a problem area one might suggest the use of prototypes or encourage face to face communication between IS and business personnel.

 Survey-based tool

 Encouraged by the above, the authors created a survey tool which was intended to evaluate knowledge creation/sharing effectiveness in project environments. In the tool, academic terms used in the model were translated into everyday language (for example, the term externalization was translated to knowledge sharing – see Fig 1 for translated terms). The tool asked project managers to evaluate their project environments against each knowledge creation process (or capability) on a scale of 1 to 10.   Based on inputs, it could recommend specific improvement strategies for capabilities that were scored low. The tool was evaluated by four project managers, who used it in their work environment over a period of 4-6 weeks. At the end of the period, they were interviewed and their responses were analysed using content analysis to match their experiences and requirements against the designed intent of the tool.  Unfortunately, the paper does not provide any details about the tool, so it’s difficult to say much more than paraphrase the authors comments.

 Based on their evaluation, the authors conclude that the tool provides:

1. A common framework for project managers to discuss issues pertaining to knowledge creation and sharing.
2. A means to identify potential problems and what might be done to address them.

 Field testing 

One of the evaluators of the model tested the tool in the field. The tester was a project manager who wanted to identify knowledge creation/sharing deficiencies in his work environment, and ways in which these could be addressed.  He answered questions based on his own evaluation of knowledge sharing capabilities in his environment and then developed an improvement plan based on strategies suggested by the tool along with some of his own ideas.  The completed survey and plan were returned to the researchers.

 Use of the tool revealed the following knowledge creation/sharing deficiencies in the project manager’s environment:

1. Inadequate personal knowledge.
2. Ineffective externalization
3. Inadequate standardization (objectivation)

Strategies suggested by the tool include:

1. An internet portal to promote knowledge capture and sharing. This included discussion forums, areas to capture and discuss best practices etc.
2. Role playing workshops to reveal how processes worked in practice (i.e. surface tacit knowledge).

Based on the above, the authors suggest that:

1. Technology can be used to promote support knowledge sharing and standardization, not just storage.
2. Interventions that make tacit knowledge explicit can be helpful.
3. As a side benefit, they note that the survey has raised consciousness about knowledge creation/sharing within the team.

Reflections and Conclusions

In my opinion, the value of the paper lies not in the model or the survey tool, but the conceptual framework that underpins them – namely, the idea knowledge depends on, and is shaped by, the social environment in which it evolves. Perhaps an example might help clarify what this means. Consider an organisation that decides to implement project management “best practices” as described by <fill in any of the popular methodologies here>. The wrong way to do this would be to implement practices wholesale, without regard to organizational culture, norms and pre-existing practices. Such an approach is unlikely to lead to the imposed practices taking root in the organisation. On the other hand, an approach that picks the practices that are useful and tailors these to organizational needs, constraints and culture is likely to meet with more success. The second approach works because it attempts to bridge gap between the “ideal best practice” and social reality in the organisation. It encourages employees to adapt practices in ways that make sense in the context of the organization. This invariably involves modifying practices, sometimes substantially, creating new (socially constructed!) knowledge in the bargain. 

Another interesting point the authors make is that several knowledge sharing heuristics (130, I think the number was) could be classified unambiguously under one of the processes in the model. This suggests that the model is a reasonable view of the knowledge creation/sharing process. If one accepts this conclusion, then the model does indeed provide a common framework for discussing issues relating knowledge creation in project environments. Further, the associated heuristics can help identify processes that don’t work well.

  I’m unable to judge the usefulness of the survey-based tool developed by the authors because they do not provide much detail about it in the paper. However, that isn’t really an issue;  the field of project management has too many “tools and techniques” anyway.  The key message of the paper, in my opinion, is the that every project has a unique context, and that the techniques used by others have to be interpreted and applied in ways that are meaningful in the context of the particular project. The paper is an excellent counterpoint to the methodology-oriented practice of knowledge management in projects; it should be required reading for methodologists and  project managers who believe that things need to be done by The Book, regardless of social or organizational context.

Introduction

In earlier posts  I’ve described a notation called IBIS (Issue-based information system), and demonstrated its utility in visualising reasoning and resolving complex issues through dialogue mapping.  The IBIS notation consists of just three elements (issues, ideas and arguments) that can be connected in a small number of ways. Yet, despite these limitations, IBIS has been found to enhance creativity when used in collaborative design discussions.  Given the simplicity of the notation and grammar, this claim is surprising,  even paradoxical.  The present post  resolves this paradox by viewing  collaborative knowledge creation as an art, and considers the aesthetic competencies required to facilitate this art.  

Knowledge art

In a position paper entitled, The paradox of the “practice level” in collaborative design rationale, Al Selvin draws an analogy between design  discussions using Compendium (an open source IBIS-based argument mapping tool)  and art.  He uses the example of the artist Piet Mondrian, highlighting the difference in  style between Mondrian’s earlier and later work. To quote from the paper,

Whenever I think of surfacing design rationale as an intentional activity — something that people engaged in some effort decide to do (or have to do), I think of Piet Mondrian’s approach to painting in his later years. During this time, he departed from the naturalistic and impressionist (and more derivative, less original) work of his youth (view an image here) and produced the highly abstract geometric paintings (view an image here) most associated with his name…

Selvin points out that the difference between the first and the second paintings is essentially one of abstraction: the first one is almost instantly recognisable as a depiction of dunes on a beach whereas the second one, from Mondrian’s minimalist period, needs some effort to understand and appreciate, as it uses a very small number of elements to create a specific ambience. To quote from the paper again,

“One might think (as many in his day did) that he was betraying beauty, nature, and emotion by going in such an abstract direction. But for Mondrian it was the opposite. Each of his paintings in this vein was a fresh attempt to go as far as he could in the depiction of cosmic tensions and balances. Each mattered to him in a deeply personal way. Each was a unique foray into a depth of expression where nothing was given and everything had to be struggled for to bring into being without collapsing into imbalance and irrelevance. The depictions and the act of depicting were inseparable. We get to look at the seemingly effortless result, but there are storms behind the polished surfaces. Bringing about these perfected abstractions required emotion, expression, struggle, inspiration, failure and recovery — in short, creativity…”

In analogy, Selvin contends that a group of people who work through design issues using a minimalist notation such as IBIS can generate creative new ideas. In other words:  IBIS, when used in a group setting such as dialogue mapping,  can become a vehicle for collaborative creativity. The effectiveness of the tool, though, depends on those who wield it:

“…To my mind using tools and methods with groups is a matter of how effective, artistic, creative, etc. whoever is applying and organizing the approach can be with the situation, constraints, and people. Done effectively, even the force-fitting of rationale surfacing into a “free-flowing” design discussion can unleash creativity and imagination in the people engaged in the effort, getting people to “think different” and look at their situation through a different set of lenses. Done ineffectively, it can impede or smother creativity as so many normal methods, interventions, and attitudes do…”

Although Selvin’s discussion is framed in the context of design discussions using Compendium,  this is but dialogue mapping by another name.  So,  in essence, he  makes a case for viewing the collaborative generation of knowledge (through dialogue mapping or any other means) as an art.  In fact, in another article, Selvin uses the term knowledge art to describe both the process and the product of creating knowledge as discussed above.   Knowledge Art as he sees it, is a marriage of the two forms of discourse that make up the term. On the one hand, we have knowledge which, “… in an organizational setting, can be thought of as what is needed to perform work; the tacit and explicit concepts, relationships, and rules that allow us to know how to do what we do.” On the other, we have art which “… is concerned with heightened expression, metaphor, crafting, emotion, nuance, creativity, meaning, purpose, beauty, rhythm, timbre, tone, immediacy, and connection.”     

Facilitating collaborative knowledge creation

In the business world, there’s never enough time to deliberate or think through ideas (either individually or collectively): everything is done in a hurry and the result is never as good as it should or could be; the picture never quite complete.  However, as Selvin says,

“…each moment (spent discussing or thinking through ideas or designs) can yield a bit of the picture, if there is a way to capture the bits and relate them, piece them together over time. That capturing and piecing is the domain of Knowledge Art. Knowledge Art requires a spectrum of skills, regardless of how it’ practiced or what form it takes. It means listening and paying attention, determining the style and level of intervention, authenticity, engagement, providing conceptual frameworks and structures, improvisation, representational skill and fluidity, and skill in working with electronic information…”

So,  knowledge art requires a wide range of technical and non-technical skills.  In previous posts  I’ve discussed some of  technical skills required – fluency with IBIS, for example.  Let’s now look at  some of the non-technical competencies.

What are the competencies needed for collaborative knowledge creation?  Palus and Horth offer some suggestions in their paper entitled, Leading Complexity; The Art of Making Sense.  They define the concept of  creative leadership as making shared sense out of complexity and chaos and the crafting of meaningful action.  Creative leadership is akin to dialogue mapping, which Jeff Conklin describes as  a means to achieve a shared understanding of wicked problems  and a shared commitment to solving them.  The connection between creative leadership and dialogue mapping is apparent once one notices the similarity between their definitions.  So the  competencies  of creative leadership should apply to dialogue mapping (or collaborative knowledge creation)  as well. 

Palus  and Horth describe  six basic competencies of creative leadership. I outline these below, mentioning  their relevance to dialogue mapping:

Paying Attention:  This refers to the ability to slow down discourse  with the aim of  achieving a deep understanding of the issues at hand. A skilled dialogue mapper has to be able to listen; to pay attention to what’s being said.

Personalizing:  This refers to the ability to draw upon personal experiences, interests and passions whilst engaged in work. Although the connection to dialogue mapping isn’t immediately evident, the point Palus and Horth make is that the ability to make connections between work and one’s interests and passions helps increase involvement, enthusiasm and motivation in tackling work challenges.

Imaging:  This refers to the ability to visualise problems so as  to understand them better,  using metaphors, pictures stories etc to stimulate imagination, intuition and understanding. The connection to dialogue mapping is clear and needs no elaboration.

Serious play: This refers to the ability to experiment with new ideas; to learn by trying and doing in a non-threatening environment. This is something that software developers do when learning new technologies. A group engaged in a dialogue mapping must have a sense of play; of trying out new ideas, even if they seem somewhat unusual.

Collaborative enquiry: This refers to the ability to  sustain productive dialogue in a diverse group of stakeholders. Again, the connection to dialogue mapping is evident.

Crafting: This refers to the ability to synthesise issues, ideas, arguments and actions into coherent, meaningful wholes. Yet again, the connection to dialogue mapping is clear – the end product is ideally a shared understanding of the problem and a shared commitment to a meaningful solution.

Palus and Horth suggest that these competencies have been ignored in the business world because:

1. They are seen as threatening the status quo (creativity is to feared because it invariably leads to changes).
2. These competencies are aesthetic, and the current emphasis on scientific management devalues competencies that are not rational or analytical.

The irony is that creative scientists have these aesthetic competencies (or qualities) in spades. At the most fundamental level science is an art – it is about constructing theories or designing experiments that make sense of the world. Where do the ideas for these new theories or experiments come from? Well, they certainly aren’t out there in the objective world; they come from the imagination of the scientist. Science, in the real sense of the word, is knowledge art. If these competencies are useful in science, they should be more than good enough for the business world.

Summing up

To sum up:  knowledge creation in an organisational context is best viewed as an art – a collaborative art.  Visual representations such as IBIS provide a medium to capture snippets of knowledge and relate them, or  piece them together over time. They provide the canvas, brush and paint to express knowledge as art  through the process of dialogue mapping.

Introduction

The day-to-day practice of project management involves the use of several artefacts: from the ubiquitous Gantt chart to the less commonly used trend chart. It is of interest to understand the practical utility of these artefacts; consequently there is a fair bit of published work devoted to answering questions such as “What percentage of project managers use this artefact?”, “How and why do they use it?” etc. (see this paper review, for example).  Such questions address the cognitive aspects of these artefacts – the logic, reasoning and thought processes behind their use.  There is a less well understood side to the use of the artefacts: the affective or emotional one; the yin to the yang of the cognitive or logical side. A paper by Jon Whitty entitled, Project management artefacts and the affective emotions they evoke,  (to appear in the International Journal of Managing Projects in Business in 2010) looks into the emotional affects (on practitioners) caused by (the use of) project management artefacts (see the note in the following paragraph for more on the term affect). This post presents an annotated summary of the paper.

[Note on the difference between affect and emotion. As I understand it, the term affect refers to automatic emotional responses which may amount to no more than a quick feeling of something being good or bad. This is in contrast to a full-blown emotion in which feelings are more intense. Unlike emotions, affective responses occur within a fraction of a second and may dissipate just as quickly. Furthermore,  affect lacks the range and variety of conscious emotions. For more on affect and emotions, see this paper by Baumeister et. al. ]

Like some of Whitty’s previous work, the paper presents an unusual – dare I say, challenging – perspective on the reasons why project managers use artefacts. I use the word “challenging” here in the sense of “questioning the rationale behind their use”, not in the sense of “difficulty.” To put the work in a wider context, it builds on the evolutionary view of project management advanced by Whitty and Schulz in an earlier paper.  The evolutionary view holds that project management practices and principles give organisations (and hence individual project managers) certain survival advantages. The current paper studies how project management artefacts – through the emotions they evoke in project managers – “create” behaviours that “cause” project managers to sustain and propagate the practice of project management within their organisations.

Study Objectives

Whitty begins by framing two hypotheses which serve to outline the objectives of his study. They are: 

1. Project managers obtain an emotional affect from aspects of the project management experiences. 
2. Project managers use the emotional affects of project management artefacts to increase their competitive advantage.

The first examines whether project managers’  behaviours are driven by the experience of managing projects; the second examines whether project managers – through their use of artefacts – manipulate their environment to their advantage.  The paper “tests” these hypotheses empirically (the reason for the enclosing quotes will become clearer later), and  also examines some implications of the results.

Background

The paper contains an extensive review of the literature on the evolutionary view of project management and emotions / affect. I found the review very useful; not only did it help me appreciate the context of the research, it also gave me some new insights into professional practice. I summarise the review below, so you can judge for yourself.

In their paper entitled, The PM_BOK Code, Whitty and Schulz argue that, in order to survive in an organisational environment, project managers are driven to put on a performance – much like stage actors – of managing projects. They recite lines (use project management terminology, deliver status reports) and use props (project management artefacts) before an audience of stakeholders ranging from senior sponsors to team members.

Subscribing to, and practising the ideals of, project management enables practitioners to gain a competitive advantage in the organisational jungle.  One aim of the paper is to clarify the role of artefacts in the evolutionary framework: specifically, how does the use of artefacts confer survival benefits, and what affects evoked in practitioners (who are using artefacts) cause the artefacts themselves to be passed on (i.e. survive).

As far as emotion or affect is concerned, Whitty mentions that much of the work done to date focuses on the management of positive and negative emotions (felt by both the project manager and the team) so as to achieve a successful project outcome. And although there is a significant body of work on the effectiveness of project management artefacts, there is virtually nothing on the emotional affect of artefacts as they are being used. Nevertheless, research in other areas suggests a strong connection between the creation/ use of artefacts, emotions evoked and the consequences thereof. An example is the affective response evoked by building architecture in a person and the consequent effect on the person’s mood. Changes in mood in turn might predispose the person to certain ideals and values. Although the emotional response caused by artefacts has been studied in other organisational contexts, it has not been done heretofore in project management. For this reason alone, this paper merits attention from project management practitioners.

Methodology

Unlike research into the utility of artefacts – where an objective definition of utility is possible – any questions relating to the emotions evoked by artefacts can only be answered subjectively: I can tell you how I feel when I do something,  you may even be able to tell how I feel by observing me,  but you can never feel what I feel.  Hence the only possible approach to answering such questions is a phenomenological one – i.e. attempting to understand reality as seen by others through their perceptions and subjective experience.  Whitty uses an approach based on empirical phenomenology -  a research methodology that aims to produce accurate descriptions of human experience through observation of behaviour.

[Note on phenomenological approaches to management research: There are two phenomenological research methods in management: hermeneutic and empirical. The empirical approach follows fairly strict data collection and analytical methods whereas the hermeneutic approach is less prescriptive about techniques used .  Another difference between the two is that the hermeneutic approach uses a range of sources including literary texts (since these are considered to reflect human experience) whereas empirical phenomenology is based on the analysis of factual data only. In essence the latter is closer to being a scientific/analytical approach to studying human experience than the former. See the very interesting paper - Revisiting Phenomenology: its potential for management research - by Lisa Ehrich for more.]

For his study, Whitty selected a group of about 50 project managers drawn from the ranks of professional bodies. The participants were asked to answer questions regarding what project management tools they enjoyed using, the emotions elicited by these tools and how they would feel if they weren’t allowed to use them.  Additionally, they were also asked to imagine their ideal project management tool / process.  Based on the answers provided, Whitty selected a small number of subjects for detailed, face-to-face interviews. The interviews probed for details on the responses provided in the survey. Audio and videotapes of the interviews were analysed to understand what the use of each artefact meant to the user, what emotions were evoked during its use and common gestures used while working with these tools – with the aim of understanding the essence of the experience of using a particular tool or process.

Whitty acknowledges some limitations of his approach, most of which are common to organisational studies.  Some of these include: problems with self-reported data, limited (and potentially non-representative) sample size. I have discussed some of these limitations in my posts on the role of social desirability bias  and the abuse of statistics in project management research. 

Results

From his analysis, Whitty found that eleven artefacts came up more often than others. These could be divided into conceptual and tangible artefacts.  The former includes the following:

• Project
• Deadline
• Team
• Professional persona of a project manager

The latter includes:

• Gantt Chart
•  WBS
• Iron Triangle
•  S-Curve
• Project management post-nominals (certifications, degrees, titles)
• PMBOK Guide  & Project management methodologies
• Professional bodies

The paper contains detailed descriptions of the results, including interesting comments by the participants.  I can do no better than refer the reader to the original paper for these. Here, in the interests of space, I’ll present only a selection of the artefacts analysed, relying heavily on quotations from the paper. My choice is based entirely on the items and interpretations that I found particularly striking.

Project

 From the responses received, Whitty concludes that:

Projects appear to be emotionally perceived as though they are composed of two opposing forces or elements which were not as dichotomistic as good and bad. Rather, these forces are more complementary or completing aspects of the one phenomenon such as in the concept of Yin – Yang, though this term was only mentioned by one participants. All of the participants described the most difficult parts of their roles as “challenges”, and felt they gained a sense of achievement and learning from their projects.

Participants described the experience of managing a project in terms of a duality between thrill and excitement, even fear and personal satisfaction…Furthermore, many believed in some sort of karmic effect where the benefits of a good work ethic today would be paid back in future project success.

Team

When asked about the concept of a team, most of the respondents felt that there was a sense of mutual commitment between the project manager and team, but not necessarily one of mutual responsibility. One project manager said, “If they (the team) shine I shine, but if it all goes wrong I take the heat.”

On the other hand, most respondents seemed to be appreciative of their teams. Many used the gesture of a circle (tracing out a circle with a finger, for example) when talking about their teams. Whitty writes,

…As an expression of emotion the circle gesture has a limitless or boundless aspect with no beginning, no end, and no division. It symbolises wholeness and completeness, and it is possibly used by project managers to express their feelings of mutual commitment and fidelity to the team and the project.

Despite the general feeling that the project manager takes the blame if things go wrong, most respondents thought that there was a strong mutual committment between the team and project manager.

Project Manager Persona

This one is very interesting. When asked to describe what a successful project manager would look like, some responses were, “mid 20s to mid 40s”, “businesslike”, “must wear a business suit”, “confident and assertive”. Some commented on how they personally and actively used the persona. On the other hand, Whitty states,

There appears to be a tension or anxiety when creating and maintaining the façade of control…

He also suggests a metaphor for the persona:

…that beneath the external impression of the graceful swan are furiously paddling legs… 

I think  that’s an absolutely marvellous characterisation of  a project manager under stress. 

Gantt Chart

The Gantt Chart is perhaps the most well-known (and over-exposed) tangible project management artefact. For this reason alone, it is interesting to look into the emotional responses evoked by it. To quote from the paper,

It seems that project managers cannot talk about PM without mentioning the Gantt chart. Project managers appear to be compelled to make them to create and maintain their professional persona.

On the other hand,

Though the Gantt chart is closely associated with PM, many participants regarded this association as a burden…Even though project managers feel frustration that they are expected, even forced to use Gantt charts, they also manipulate this situation to their advantage and use Gantt charts to placate senior management and clients.

Stress and hopefulness appear to be two emotions linked with Gantt Charts (duality again!). One participant said “the Gantt charts you’re showing me don’t mean anything to me I feel pretty neutral about them. But my Gantt charts can really stress me out.” And another, “When I look at it (the Gantt chart) all finished, (heavy sigh) I suppose I’m hoping that’s how it will all turn out…”

As I see it, the Gantt chart – much like the PERT chart – is used more to manage management than to manage projects, and hence the mixed emotions evoked by its use.

Work Breakdown Structure

Whitty mentions that over two-thirds of the participants said they used WBS in one form or another. He states,

All participants view work in packets or as bounded objects. As one put it, “I like to break the work down into nice crisp chunks, and then connect them all up together again.” This behaviour support Gestalt theories that in order to interpret what we receive through our senses we attempt to organize information into certain groups which include: similarity, proximity, continuity, and closure….

Through his  reference to Gestalt theories, Whitty suggests that breaking the project up  into chunks of work and then putting it  back together again helps the project manager grok the project  – i.e. understand the interconnections between project elements and the totality of the project in a  deep way. A little later he states,

Many experience satisfaction, contentment, even a sense of control from the WBS process.

I can’t help but wonder - does the popularity of the tool stem, at least in part,  from its ability to evoke positive affect?

PMBOK Guide and Methodologies

Based on the responses received, Whitty mentions,

It is apparent that some PM methodologies are PM artefacts in themselves and are used as currency to gain a competitive advantage.”

Yet the profession appears to be divided about the utility of methodologies,

All the participants were aware of the PMBOK® Guide, and all of them utilised a PM methodology of some sort, whether it were an off-the-shelf brand or a company-grown product. Participants appeared to be either for or against PM methodologies, some even crossed over the dividing line mid-sentence (!)

Another theme that arose is that methodologies are “something to hide behind” should things go wrong: “Don’t blame me, I did things by the Book.” Methodologies thus offer two side benefits (apart from the man one of improving chances of project success!): they help “certify” to a project manager’s competence and act as a buffer if things go wrong.

Discussion

Whitty concludes that the data supports his hypothesis that project managers obtain an emotional affect from aspects of project management experience. In his words:

This study has shown that project managers are drawn to project work. The participants in this study forage for projects because they can obtain or experience an emotional affect or more informally stated a favourable emotional fix from the challenge they present…. they are stimulated by the challenges the construct of a project has to offer. Furthermore, they appear to be fairly sure they can handle these challenges with their existing skill and abilities…

The data also suggests that despite the dominant deterministic approach to project management, project managers also,

…operate under the cognitive logic of yin-yang. They conceptualise the emotional experience of managing a project in terms of two possible states or statuses of events that ebb and flow; one state gradually transforming into the other state along a time dimension. What is also interesting is that these project managers find it necessary to conceal this behaviour for survival reasons.

The data also supports the second hypothesis: that project managers use the emotional affects of the project management experience to increase their competitive advantage. This is clear, for example, from the discussions of the Project Manager Persona, Gantt Chart and methodologies.

Concluding remarks 

 This is an important study because it has implications for how project management is taught, practised and researched. For example, most project management courses teach tools and techniques – such as Gantt Charts – with the implicit assumption that using them will improve chances of project success.  However, from this research it is clear, and I quote 

…some practitioners create Gantt charts because they enjoy the Gantt charting process, and some create them to placate others and/or to be viewed favourably by others. It is simply not clear how Gantt charts or the scheduling process in general contributes to the overall performance of a project…

Using this as an example, Whitty makes a plea for an objective justification of project management practices. It’s just not good enough to say we must use something because so-and-so methodology says so (see my piece entitled, A PERT myth, for another example of a tool that, though well entrenched, has questionable utility). The research also indicates that a project manager’s behaviours are influenced by the physical and cultural environment in which he or she operates: some practices are followed because they give the project manager a sense of control; others because they help gain a competitive advantage. Whitty suggests that senior managers would get more out of their project managers if they understood how project managers are affected by their environment. Further, he recommends that project managers should be encouraged to adopt only those techniques, practices and norms that are demonstrably useful. Those that aren’t should be abandoned.

So what are the implications for profession? In a nutshell: it is to think critically about the way we manage projects. Practices recommended by a particular methodology or authority are sometimes followed without critical analysis or introspection. So the next time you invoke a tool, technique or practice – stop for a minute and reflect on what you’re doing and why. An honest answer may hold some surprises.

Organisational culture is defined by the values and norms that are shared by people and groups in an organisation. These values and norms, in turn, influence how  people interact with each other and with outsiders. That’s well and good, but how does one determine an an organisation’s culture? How does one find out if the culture good (i.e. would one like to work there) or bad (would one not)? In my opinion, this is best evaluated by looking at how people react in certain work situations.  What follows is a quick quiz to test an organisation’s culture based on this principle.  Note that it can also be applied to projects – as projects are temporary organisations. Typically project and team cultures simply reflect those of the organisations in which they exist. However, there can be differences: a good project or team leader can (to an extent) shield his or her team from the effects of a toxic organisational culture. But that’s fodder for another post.  For now, let’s get on with the quiz.

A tip before starting: don’t over-think your answers; your initial response is probably the most accurate one.

Ready? Right, here we go…the sixty-second quiz on your workplace culture:

a)  You make a mistake that no one notices. What do you do:

1. Keep quiet about it and hopes it remains unnoticed.
2. Own up because it is OK to make mistakes around here.
3. Dream up a scheme to pin it someone else, preferably a rival for a promotion.

b)  You have an idea that might lead to a new product. You

1. Use workmates and manager as a sounding board for whether it is any good.
2. Start to work it through yourself to see if it is any good. 
3. Forget about it

c) You have an idea which involves collaborating with someone from another department. You

1. Approach the person directly.
2. Go through the proper channels – approach your manager who approaches their manager and so on.
3. Forget about it: inter-departmental politics would get in the way.

d) People at an organisation-wide event (company day or a project team day out, for example):

1. Stick with folks from their departments. 
2. Mingle, and look like they’re enjoying it. 
3. Look like they want to be elsewhere. In fact many of them are – they’ve called in sick.

e) A project has gone horribly wrong. Do people

1. Look for a scapegoat. 
2.  Say, “I had nothing to do with it.” 
3. Work together to fix it.

f)  Someone from another department approaches you for assistance relating to your area of expertise. Do you

1. Help them right away, or as soon as you can. 
2. Ask them to speak to your manager first. 
3. Fob them off – you’re way too overworked and don’t really feel like doing a whit of work more than you absolutely have to.

g)  What do people in your organisation do when they are annoyed by some aspect of their job? (Note: see this post for more on this question)

1. They complain about it. 
2. They ignore it.
3. They fix it.

h) The atmosphere in cross-departmental meetings in your organisation is generally:

1.  Cordial.
2. Tense 
3. Neutral

i) An impossible deadline looms. In order to meet it you

1. Work overtime because you have to. 
2. Work overtime because you want to. 
3. This question is inapplicable – you never have impossible deadlines.

j)  You’ve done something brilliant that saves the organisation a packet. Your manager:

1. Acknowledges your efforts publicly. 
2. Acknowledges your efforts privately. 
3. Grabs the glory.

k) You’ve worked overtime on a project and its all come good. You get 

1. A pat on the back. 
2. A pat on the back and something tangible (a bonus, a meal or at least a movie voucher) 
3.  Nothing (We pay you a salary, don’t we?)

l)  You’re feeling under the weather, but are not really sick (Put it this way: no doctor would give you a certificate). However, you honestly don’t think you can make it through the work day.  What do you do?

1. Thank God and take the day off.
2. Go to work because you want to. 
3. Go to work because you have to.

Score:

The score for each response is the number  in brackets against the choice you made.

a. 1 (5)  2(10)  3(0)
b. 1(10) 2(5) 3(0)
c. 1(10) 2(5) 3(0)
d. 1(5) 2(10) 3(0)
e. 1(0) 2(5) 3(10)
f.  1(10) 2(5) 3(0)
g. 1(0) 2(5) 3(10)
h. 1(10) 2(0) 3(5)
i.  1(0) 2(5) 3(10)
j.  1(10) 2(5) 3(0)
k. 1(5) 2(10) 3(0)
l.  1(0) 2(10) 3(5)

What does your score mean?

> 100 :  Does your organisation have any vacancies for a PM/dev manager? 

80-95 :  I bet you enjoy working here.

60-75: Still on the right side of the divide, but things do get unpleasant occasionally

40 -55: Things could be a lot worse – but, they could also be better.

20-35: Things are a lot worse

< 20: Workplace hell?

A good organisational culture is one which encourages and enables people to do the right thing  without coercion or fear of consequences.  What’s right?  Most people just know what is right and what’s not, without having to be told.   I can think of no better way to end this post than by quoting from the start of Robert Pirsig’s classic,  Zen and The Art of Motorcycle Maintenance:

And what is good, Phædrus,
And what is not good…
Need we ask anyone to tell us these things?