Archive for the ‘Project Management’ Category
On the meaning and interpretation of project documents
Introduction
Most projects generate reams of paperwork ranging from business cases to lessons learned documents. These are usually written with a specific audience in mind: business cases are intended for executive management whereas lessons learned docs are addressed to future project staff (or the portfolio police…). In view of this, such documents are intended to convey a specific message: a business case aims to convince management that a project has strategic value while a lessons learnt document offers future project teams experience-based advice.
Since the writer of a project document has a clear objective in mind, it is natural to expect that the result would be largely unambiguous. In this post, I look at the potential gap between the meaning of a project document (as intended by the author) and its interpretation (by a reader). As we will see, it is far from clear that the two are the same – in fact, most often, they are not. Note that the points I make apply to any kind of written or spoken communication, not just project documents. However, in keeping with the general theme of this blog, my discussion will focus on the latter.
Meaning and truth
Let’s begin with an example. Consider the following statement taken from this sample business case:
“ABC Company has an opportunity to save 260 hours of office labor annually by automating time-consuming and error-prone manual tasks.”
Let’s ask ourselves: what is the meaning of this sentence?
On the face of it, the meaning of a sentence such as the one above is equivalent to knowing the condition(s) under which the claim it makes is true. For example, the statement above implies that if the company undertakes the project (condition) then it will save the stated hours of labour (claim). This interpretation of meaning is called the truth-conditional model. Among other things, it assumes that the truth of a sentence has an objective meaning.
Most people have something like the truth-conditional model in mind when they are writing documents: they (try to) write in a way that makes the truth of their claims plausible or, better yet, evident.
Buehler’s model of language
At this point, it is helpful to look at a model of language proposed by the German linguist Karl Buehler in the 1930s. According to Buehler, language has three functions, not just one as in the truth-conditional model. The three functions are:
- Cognitive: representing an (objective) truth about the world. This is the same “truth” as in the truth-conditional model.
- Expressive: expressing a point of view of the writer (or speaker).
- Appeal: making a request of the reader – or “appealing to” the reader.
A graphical representation of the model –sometimes called the organon model – is shown in Figure 1 below.
Figure 1: Buehler's organon model
The basic point Buehler makes is that focusing on the cognitive function alone cannot lead to a complete picture of meaning. One has to factor in the desires and intent of the writer (or speaker) and the predispositions of those who make up the audience. Ultimately, the meaning resides not in some idealized objective truth, but in how readers interpret the document.
Meaning and interpretation
Let’s look at the statement made in the previous section in the light of Buehler’s model.
First, the statement (and indeed the document) makes some claims regarding the external, objective world. This is essentially the same as the truth-conditional view mentioned in the previous section.
Second, from the viewpoint of the expressive function, the statement (and the entire business case, for that matter) selects facts that the writer believes will convince the reader. So, among other things, the writer claims that the company will save 260 hours of manual labour by automating time-consuming and error-prone tasks. The adjectives used imply that some tasks are not carried out efficiently. The author chose to make this point; he or she could have made it another way or even not made it all.
Finally, executives who read the business case might interpret claim made in many different ways depending on:
- Their knowledge of the office environment (things such as the workload of office staff, scope for automation etc.) and the environment. This corresponds to the cognitive function in Buehler’s model.
- Their own predispositions, intentions and desires and those that they impute to the author. This corresponds to the appeal and expressive functions.
For instance, the statement might be viewed as irrelevant by an executive who believes that the existing office staff are perfectly capable of dealing with the workload (“They need to work smarter”, he might say). On the other hand, if he knows that the business case has been written up by the IT department (who are currently looking to justify their budgets), he might well question the validity of the statement and ask for details of how the figure of 260 hours was arrived at. The point is: even a simple and seemingly unambiguous statement (from the point of view of the writer) might be interpreted in a host of unexpected ways.
More than just “sending and receiving”
The standard sender-receiver model of communication is simplistic. Among other things it assumes that interpretation is “just” a matter of interpreting a message correctly. The general assumption is that:
…If the requisite information has been properly packed in a message, only someone who is deficient could fail to get it out. This partitioning of responsibility between the sender and the recipient often results in reciprocal blaming for communication. (Quoted from Questions and Information: contrasting metaphors by Thomas Lauer)
Buehler’s model reminds us that any communication – as clear as it may seem to the sender – is open to being interpreted in a variety of different ways by the receiver. Moreover, the two parties need to understand each others intent and motives, which are generally not open to view.
Wrapping up
The meaning of project documents isn’t as clear-cut as is usually assumed. This is so even for documents that are thought of as being unambiguous (such as contracts or status reports). Writers write from their point of view, which may differ considerably from that of their readers. Further, phrases and sentences which seem clear to a writer can be interpreted in a variety of ways by readers, depending on their situation and motivations. The bottom line is that the writer must not only strive for clarity of expression, but must also try to anticipate ways in which readers might interpret what’s written.
Planning and improvisation – complementary facets of organizational work
Introduction
Cause-effect relationships in the business world are never clear cut. Yet, those who run business organisations hanker after predictability. Consequently, a great deal of effort is expended on planning – thinking out and organizing actions aimed at directing the course of the future. In this “planning view”, time is seen as a commodity that can be divided, allocated and used to achieve organizational aims. In this scheme of things, the future is seen as unfolding linearly, traversing the axis of time according to plan. Although (good) plans factor in uncertainties and unforeseen events, the emphasis is on predictability and it is generally assumed that things will go as foreseen.
In reality things rarely go according to plan. Stuff happens, things that aren’t foreseen – and what’s not foreseen cannot be planned for. People deal with this by improvising, taking extemporaneous actions that feel right at the time. In retrospect such actions often turn out to be right. However, such actions are essentially unplanned; one cannot predict or allocate a particular time at which they will occur. In this sense they lie outside of normal (or planned) organizational time.
In a paper entitled Notes on improvisation and time in organisation (abstract only), Claudio Ciborra considered the nature of improvisation in organisations. Although the paper was written a while ago, primarily as a critique of Business Process Reengineering (BPR) and its negative side effects, many of the points he made are of wider relevance. This post, inspired by Ciborra’s paper, is the first of a two-part series of posts in which I discuss the nature of improvisation and planning in organisations. In the present post I discuss the differences between the two and how they complement each other in practice. In a subsequent post I will talk about how the two lead to different notions of time in organisations.
Contrasting planning and improvisation
The table below summarises some of the key contrasting characteristics between planning and improvisation:
|
Planning |
Improvisation |
| Follows procedures and processes; operates within clearly defined boundaries | Idiosyncratic; boundaries are not well defined, or sometimes not defined at all. |
| Operates within organizational rules and decrees | Often operates outside of organizational rules and norms. |
| Method of solution is assumed to be known. | Method emerges via sensemaking and exploration. |
| Slow, deliberate decision-making | Quick – almost instantaneous decision making |
| Planning attempts to predict and control (how events unfold in) time. | Improvisation is extemporaneous – operates “outside of time” |
In essence improvisation cannot be planned; it is always surprising, even to improvisers.
Planning and improvisation coexist
Following Alfred Schutz, Ciborra notes that in planned work (such as projects) every action is carried out according to a view of a future in which it is already accomplished. In other words, in projects we do things according to a plan because we expect those actions to lead to certain consequences – that is we expect our actions to achieve certain goals. Schutz referred to such motives as in-order-to motives. These motives are embedded in the project and its rationale, and are often documented for all to see. However, in-order-to motives are only part of the story, and a small one at that. More important are the reasons for which the goals are thought to be worthwhile. Among other things, these involve factors relating history, environment and past experiences of the people who make up the organisation or project. Schutz referred to such motivations as because-of motives. These motives are usually tacit and remain so unless a conscious effort is made to surface them.
As Ciborra puts it:
The in-order-to project deals with the actor’s explicit and conscious meaning in solving a problematic situation while the because-of motives can explain why and how a situation has been perceived as problematic in the first place.
The because-of motives are tacit and lie in the background of the explicit project at hand. They fall outside the glance of rational, awake attention during the performance of the action. They could be inferred by an outsider, or made explicit by the actor, but only as a result of reflection after the fact.
(Note that although Ciborra uses the word project as referring to any future-directed action, it could just as well be applied to the kinds of projects you and I work on.)
Ciborra uses the metaphor of an iceberg to illustrate the coexistence of the two types of motives. The in-order-to motives are the tip of the iceberg, there for all to see. On the other hand, because-of motives, though more numerous, are hidden below the surface and can’t be seen unless one makes the effort to see them. Improvisation generally draws upon these tacit, because-of motives that are not visible. Moreover, the very interpretation of formalized procedures and best practices involves these motives. Actions performed as a consequence of such interpretations are what bring procedures and practices to life in specific situations. As Ciborra puts it:
A formalized procedure embeds a set of explicit in-order-to’s, but the way these are actually interpreted and put to work strictly depends upon the actor’s in-order-to and because-of motives, his/her way of being in the world “next” to the procedure, the rule or the plan. In more radical terms what is at stake here is not “objects” or “artifacts” but human existence and experience. Procedure and method are just “dead objects”: they get situated in the flow of organizational life only thanks to a mélange of human motives and actions. One cannot cleanse human existence and experience from the ways of operating and use of artifacts.
In short, planning and improvisation are both necessary for a proper functioning of organizations.
Opposite, but complementary
Planning and improvisation are very different activities – the former is aimed at influencing the future through activities that are pre-organized whereas the latter involves actions that occur just-in-time. Moreover, planning is a result of conscious thought and deliberation whereas improvisation is a result of tacit knowledge being brought to bear, in an instant, on specific situations encountered in project (or other organizational) work. Nevertheless, despite their differences, both activities are important in organizations. Efforts aimed at planning the future down to the last detail are misguided and bound to fail. Contraria sunt complementa: planning and improvisation are opposites, but they are complementary.1
1 The phrase contraria sunt complementa means opposites are complementary. It appears on the physicist Niels Bohr’s coat of arms (he was knighted after he won the Nobel Prize for physics in 1922). Bohr formulated the complementarity principle, the best known manifestation of which is wave-particle duality – i.e. that in the atomic world, particles can display either wave or particle like characteristics, depending on the experimental set up.
The resource allocation syndrome in multi-project environments
Introduction
In many organisations, employee workloads consist of a mix of project and operational assignments. Due to endemic shortfalls in staffing, such folks – particularly those who have key skills and knowledge – generally have little or no spare capacity to take on more work. However, soon comes along another “important” project in urgent need of staffing and the rest, as they say, is tragedy: folks who are up to their necks in work are assigned to work on the new project. This phenomenon is a manifestation of the resource allocation syndrome, discussed at length in a paper by Mats Engwall and Anna Jerbrant entitled, The resource allocation syndrome: the prime challenge of multi-project management?. The present post is a summary of the paper.
Background
Scheduling and resource allocation is a critical part of project planning in multi-project environments. Those who work in such settings know (often from bitter experience) that, despite the best laid plans, it is easy to be over-allocated to multiple projects. Engwall and Jerbrant’s work delves into the factors behind resource over-allocation via a comparative case study involving two very different environments: the contracts department of a railway signalling equipment firm and an R&D division of a telecoms company.
Specifically, the work addresses the following questions:
- Are there any (resource allocation) issues that are common to multi-project / portfolio environments?
- What are the mechanisms behind these issues?
As they point out, there are several articles and papers that deal with the issue of resource allocation on concurrent projects. However, there are relatively few that tackle the question of why problems arise. Their aim is to shed light on this question.
Methodology and the case studies
As mentioned above, the authors’ aim was surface factors that are common to multi-project environments. To this end, they gathered qualitative data from a variety of sources at both sites. This included interviews, studies of project and technical documentation, company procedures and direct observation of work practices.
The first study was carried out at the contract division of a mid-sized railway signalling equipment firm. The division was well-established and had a long history of successful projects in this domain. As might be expected given the history of the organisation, there was a mature project management methodology in place. The organisation had a matrix management structure with 200 employees who were involved in executing various projects around the world. The work was managed by 20 project managers. Most of the projects were executed for external clients. Further, most projects involved little innovation: they were based on proven technologies that project teams were familiar with. However, although the projects were based on known technologies, they were complex and of a relatively long duration (1 to 5 years).
The second study was done in the R&D division of a telecom operator. The division, which had just been established, had 50 employees who worked within a matrix structure that was organised into five specialist departments. Since the division was new, the project management procedures used were quite unsophisticated. Projects were run by 7 project managers, and often involved employees from multiple departments. Most of the projects run by the division were for internal customers – other divisions of the company. Also in contrast to the first study, most projects involved a high degree of innovation as they were aimed at developing cutting-edge technologies that would attract new subscribers. However, even though the projects involved new technologies, they were of relatively short duration (0.5 to 2 years).
Important, from the point of view of the study, was the fact that most employees in both organisations were engaged in more than one project at any given time.
For those interested, the paper contains more detail on the methodology and case studies.
Results
As might be expected from a study of this nature, there were differences and similarities between the two organisations that were studied. The differences were mainly in the client base (external for the contract division, internal for the other), project complexity (complex vs. simple) and organisational maturity (older and mature vs. newly instituted and immature).
Despite the differences, however, both organisations suffered from similar problems. Firstly, both organisations had portfolios with extensive project interdependencies. As a consequence, priority setting and resource (re)allocation was a major management issue. Another issue was that of internal competition between projects – for financial and human resources. In fact, the latter was one of the most significant challenges faced by both organisations. Finally, in both organisations, problems were dealt with in an ad-hoc way, often resulting in solutions that caused more issues down the line.
From the common problems identified, it was clear that:
In both organizations, the primary management issue revolved around resources. The portfolio management was overwhelmed issues concerning prioritization of projects and, distribution of personnel from one project to another, and the search for slack resources. However, there were no resources available. Furthermore, when resources were redistributed it often produced negative effects on other projects of the portfolio. This forced the management to continuous fire fighting, resulting in reactive behavior and short-term problem solving. However, the primary lever for portfolio management to affect an ongoing project in trouble was resource re-allocation.
There are a couple of points to note here. Firstly, resource re-allocation did not work. Secondly, despite major differences in between the two organisations, both suffered from similar resource allocation issues. This suggests that this resource allocation syndrome is a common problem in multi-project environments.
Understanding the syndrome
Based on data gathered, the authors identify a number of factors that affect resource allocation. These are:
- Failure in scheduling: this attributes the resource allocation syndrome to improper scheduling rather than problems of coordination and transition. The fact of the matter is that it is impossible for people to shift seamlessly from one project to another. There is – at the very least – the overhead of context switching. Further, projects rarely run on schedule, and delays caused by this are difficult to take into account before they occur.
- Over commitment of resources: This is another common problem in multi-project environments: there are always more projects than can be handled by available personnel. This problem arises because there is always pressure to win new business or respond to unexpected changes in the business environment.
- Effect of accounting methods: project organisations often bill based on hours spent by personnel on projects. In contrast, time spent on internal activities such as meetings are viewed as costs. In such situations there is an in-built incentive for management to keep as many people as possible working on projects. A side-effect of this is the lack of availability of resources for new projects.
- Opportunistic management behaviour: In many matrix organisations, the allocation of resources is based on project priority. In such cases there is an incentive for project sponsors and senior managers to get a high priority assigned by any means possible. On the other hand, those who already have resources assigned to their projects would want to protect them from being poached to work on other projects.
The above factors were identified based on observations and from comments made by interviewees in both organisations.
Resource allocation (as taught in project management courses) focuses on the first two points noted above: scheduling and over-commitment. The problem is thus seen as a pure project management issue – one that deals with assigning of available resources to meet demand in the most efficient (i.e. optimal) way. In reality, however, the latter two points (which have little to do with project management per se) play a bigger role. As the author’s state:
Instead of more scheduling, progress reports, or more time spent on review meetings, the whole system of managerial procedures has to be reconceptualized from its roots. As current findings indicate: the resource allocation syndrome of multi-project management is not an issue in itself; it is rather an expression of many other, more profound, organizational problems of the multi-project setting.
The syndrome is thus a symptom of flawed organisational procedures. Consequently, dealing with it is beyond the scope of project management.
Conclusion
The key takeaway from the paper is that the resource allocation issues are a consequence of flawed organisational procedures rather than poor project management practices. Project and portfolio managers responsible for resource allocation are only too aware of this. However, they are powerless to do anything about it because, as Engwall and Jerbrant suggest, addressing the root cause of this syndrome is a task for executive management.
Eight to Late 