Archive for the ‘Paper Review’ Category
Thinking outside the BOKs
Introduction
Mainstream project management practices are codified in various “bodies of knowledge” (BOKs) that serve as definitive guides or standards for the profession. This formalization of project management knowledge serves to propagate and legitimize practices regardless of their actual utility. Moreover, it also leads to a perception that project management practices are domain-independent. In a recent paper entitled, 21st century project management = open source body of knowledge, Jon Whitty calls for an open source approach to the development and dissemination of project management knowledge, with a view to addressing the aforementioned limitations of the “BOK-centric” paradigm. This post summarises the main ideas presented in the paper.
Why step outside the BOKs?
According to Whitty, many project management tools and techniques have become standard practice for reasons other than their utility. Some of these reasons include:
- Techniques that are easy to replicate (copy and pass on to others) have a greater chance of acceptance, regardless of whether they are useful or not. This point is discussed at length in my post on the memetic view of project management.
- Techniques that give project managers (and their managers) an emotional affect have a better chance of acceptance. See my post on emotional effect of project management artefacts for more on this.
As Whitty puts it, “One might say that we have been duped or perhaps more poetically speaking romanced by some aspects of modern project management…”
The main consequence of the above is that “standard” project management knowledge as embodied in books and BOKs isn’t necessarily a reflection of how project management is (or even, should be) practiced. Yet this is the official, authorized version of knowledge, used to train and certify project managers.
Another point that Whitty makes is that despite of the discipline’s attempt to rid itself of domain specific connotation, project management (in practice) is domain specific – there is a difference, say, between a corporate reporting system project and a health care project. It is wishful thinking to expect that a project manager will be able run a project in an unfamiliar area without first learning a bit about the domain. Consequently, Whitty writes that:
…we must acknowledge that each domain of work (e.g. health, arts, sciences, education) is capable of evolving its own methods for managing projects if given the freedom to do so. I suggest there is a moral obligation on all scholars and practitioners of project management to enable these domain specific methods to emerge…
Another point that I would add in support of Whitty’s arguments is that there is a difference between project management theory and project management practice (see this paper, for example). Projects are seldom, if ever, run by the book; it is a fact that most project managers do “think outside the BOKs” when practicing their profession. A body of knowledge reflecting how projects are actually run in practice would thus be very different from the prescriptions presented in books and BOKs.
Project management as a (controlled) democracy
To address the issues mentioned in the previous section, Whitty suggests democratizing project management knowledge by:
- A bottom-up approach to project decision making, involving all stakeholders, rather than a top-down approach implicitly advocated by books and BOKs.
- The recognition that project management needs to be tailored to the needs of specific domains, rather than striving for the lowest common denominator of domain independent tools and techniques.
- An open source approach to project management knowledge whereby anyone can contribute techniques and case studies based on their own (possibly domain specific) experiences.
- A culture that enables project managers to report their specific practices (and failures) without fear of reprisals.
Whitty clarifies that open source means more than free access. Among other things, it offers a means by which
- New techniques can be shared and evaluated by practicing project managers and academics.
- Domain specific project management knowledge can be compiled, tested and disseminated. This knowledge will evolve as it is supported (or refuted) through case studies and other data contributed by practitioners.
Obviously open source does not mean that anything goes; that would be a recipe for chaos and confusion. Oversight is needed to ensure that the repository is coherent and meaningful, and that contributed material meets certain quality standards. This is nothing new – most open source efforts operate this way already – Wikipedia being the closest in spirit to the one proposed by Whitty.
The role of professional organisations in an OS-BOK world
What role would professional organisations have in such an open source BOK world? Here’s what Whitty thinks,
The implications for an open source body of knowledge for project management will be significant for the current project management professional associations who control existing BOKs, particularly the PMI who hold the intellectual property to the current Guide. The PMI and others will need to abandon their ideals for creating a professional class of project managers. They could take a leadership role in the development and on‐going coordination of the human and technological mechanisms that develop and maintain the OS‐PMBOK and validate the source evidence of the various knowledge libraries. Their role might also be more like that of a vocational skills awarding body. As the various domain specific bodies of knowledge for project management emerge, the project management associations could have a place in developing and administering specific project management certification in conjunction with key industry bodies that represent the various domains. The project management associations will also need to establish new alliances with the academic community and lend support, cooperation, and channel industry funding towards evidence-based practice research.
Many of the activities listed by Whitty are already carried out by most professional project management organisations. As I see it, these organisations would continue to play an important role in developing the profession. However, they would no longer be the arbiters of what is legitimate and what isn’t.
Conclusion
Existing project management knowledge tells us how projects should be managed, not how they are actually managed. Seen in this light, Whitty’s proposal for an open source approach to project management makes eminent sense. Such an approach may lead to a body of knowledge that reflects the diverse ways in which project management is practiced in various (corporate and national) cultures and domains.
On the relationship between projects and project managers
Introduction
Those who run projects often spend a large part of their waking hours working or thinking about work. It is therefore no surprise that the self images and identities of such individuals are affected (if not defined) by their work roles. In a sense, their identities are colonized (in the sense of “taken over” or “largely defined”) by the project and the larger, permanent organization which hosts the project. A paper entitled, Who is colonizing whom? Intertwined identities in product development projects, by Thomas Andersson and Mikael Wickelgren explores this issue via a longitudinal case study that was carried out within new product development teams at Volvo. This post is a summary and review of the paper.
From the title of the paper it is evident that the identity issue is more than just a simple “the project leader (or team’s) identity is defined by project work” argument . Indeed, those who lead product development projects are themselves involved in creating at least three identities: those of the product, project and organization. Further, as I have pointed out in my post on project management in post-bureaucratic organizations, there are contradictions in the way in which project management operates. On the one hand it is seen as a means to direct innovative efforts (such as product development initiatives); on the other it is an essentially top-down, bureaucratic means of control. Project teams often operate in such contradictory, tension-filled environments. Although, most project leaders believe they work on projects by choice, it could be that the not-so-subtle pressures of expectation and social/ professional norms force the choice upon them.
However, as the authors point out, identity construction isn’t enough to explain why folks are willing to work insane hours; there’s something more going on. Indeed there is research that supports the notion that employees identities are moulded by organizations to suit organizational ends – in other words, employees identities are colonized by organisations. Andersson and Wickelgren suggest that the process of colonization isn’t as straightforward as it seems because employees often actively seek demanding roles. So, who is colonizing whom? Both parties are complicit in the colonization process. The main aim of the authors is to describe identity construction processes in project work with a focus on how, via the process proving their competence in project work, project leaders form their own self identities.
My review follows the format of the paper: I’ll begin with an overview of the relevant conceptual and theoretical background and then get into the case study.
Identity construction in project management
Individual identities are defined by how people relate to (professional and social) situations. The process of identity construction is an ongoing process of making sense of situations from a personal perspective. An individual is typically subject to many different identities at an aggregate level – for example the professional identity of a project manager, the identity of a parent etc. These can be thought of as certain norms or ways in which people are expected to behave. Individuals identify with aspects of these roles and act them out, thus integrating them into their own (self) identities. The point is that one’s professional identity is a part of one’s self identity.
The process of identity construction is a discursive one: i.e. it depends on how the situations in which the individual finds himself or herself unfold. In this connection the authors mention two important concepts, identity work and identity regulation. The first is the ongoing process of identity formation (and reformation) through interaction with the situation at hand (which could be a project, say). The second refers to the norms and rules, or the ways in which people are expected to behave in situations (the explicit norms and rules of project management, for instance). It is clear that identity regulation – by laying down appropriate behaviours – can have a “colonizing effect” on people’s identities. The authors make the point that even identity work can have an implicit colonizing effect – an example would be where project leaders identify with their work to such an extent that they go above and beyond the call of duty.
The increasing projectisation of organisations means that many individuals spend a large part of their work hours in a project environment. As such it is inevitable that this will affect their self-identity. In a fascinating paper, Lindgren and Packendorff pointed out that there are certain commonly accepted ways of relating to and making sense of project situations. For example – a project is seen as demanding higher levels of professionalism and loyalty than “normal” organizational work. Such norms constrain choices of those involved in projects. Once signed up, one has to behave in certain accepted ways. The authors make the point that there are very few empirical studies that look into how people handle such a “projectified reality.”
Several researchers have recognized the paradoxical nature of project work. Project-based management is touted as a means to loosen the hold of bureaucratic management structures. However, project management in practice tends to be riddled with (pointless?) bureaucratic procedures. As another example, projects are seen as a means to accelerate organizational learning – by doing new things under controlled, time-bound conditions. Yet, the reality is that when projects are in progress, organisations are loathe to spend time on capturing knowledge. The focus is always on the immediate deliverables rather than longer term learning. Given this, it is no surprise that individuals too, would rather focus on their next project than reflect on what happened on the previous one. As the authors put it:
…project managers seem ambivalent about their ‘professional identity’; they both aspire to it and resist it. Because of the lack of opportunities for reflection and learning, project workers often seek higher positions in future projects as their reward, with the result that their careers become a series of endless projects requiring increased responsibility and commitment. Emergency situations and problems that arise owing to these time and resource constraints are resolved by heroic actions that gradually become taken-for granted solutions.
It’s a sad commentary on the profession, but I reckon that we, as practitioners, are at least partly to blame.
Project work-life balance
Projects usually operate under tight budgetary and time constraints. Even if one can find more money to throw at a project, it is often impossible to buy more time. As a result those who work on projects often end up working overtime – “doing whatever it takes” to finish the work. But as the authors point out:
‘Doing whatever it takes’ is a very abstract commitment that is hardly measurable since basically it is a social construction dependent on the project leaders’ sense of duty and the external pressures for heroic actions. The dark side of this commitment means long working hours with the inevitable risk of burnout, stress and work/life balance difficulties, all of which may lead to problems with health, general well-being, and family life. The potential damage is as real for the project workers as it is for their organizations.
But it’s even worse because this destructive type of “heroic behaviour” is generally seen as distinguishing committed workers from less committed ones. The authors claim that this goes beyond specific organisations; it is a consequence of projectisation of society in general.
The case study
The qualitative data presented in the case study was gathered by the authors over two periods: 1998-2001 and 2007. In the intervening period, the authors stayed in touch with those in the organisation (Volvo Car Company), but did not actively gather data. Such a longitudinal study (over a long period) enables researchers to study how attitudes evolve over time. The methodology of the study is best described in their own words:
We studied projects managers who were jointly running new car projects at Volvo Car Corporation (VCC). In addition to direct observations, we video-taped 100 hours of project management meetings and audio-taped individual interviews with all participating project leaders. Our combination of observations and interviews allowed us to observe the practice and everyday lives of the project leaders and to discuss the observations with the interviewees. Thus we were able to observe the project practice closely. In 2007, we interviewed some people from the initial round of interviews who still worked in new car projects. Using this wealth of empirical material, our focus here is on the multi-layered aspects of identity regulation and identity work, especially in terms of colonization, in the studied setting.
The project leaders enjoyed a high status within the company and were often seen as “company heroes, but only as long as their projects succeeded. This created a tremendous pressure to succeed thus making the heroic approach to project management almost inevitable.
Long hours come with the territory
Working long hours is often seen as a hallmark of a dedicated project manager. Further, in many organisations (such as the one studied by the authors) there was the expectation that project managers would sacrifice their own time for the good of the project. As one project leader explained to the authors:
I work all the time! Weekends, evenings…Before Christmas I picked up my husband at a Christmas party in the evening, and then I went back to work and stayed there until midnight. Still, I met a colleague on Saturday morning and was able to do some more work before we left for Christmas. That is typical in my work. I haven’t time for the simplest things in my private life.
The authors make the point that even if a project leader could finish his/her work within a normal 40 hour work week, others would still question their commitment if they did not work overtime. Further, if the project did fail, the failure would almost certainly be attributed to the lack of commitment. Project leaders are thus under pressure to work overtime, whether it is needed or not. This is reflected in another comment by a project leader, about what happens between projects:
The period between projects is tough. It takes time to come down. In the beginning it is hard to accept that working 40 hours a week is not the same as having a half-time job, but that is the feeling. […] I have accepted that there are no interesting jobs where you work 40 hours a week, but I think it might be possible to stop at 60 hours a week…
We see that although unreasonable demands are being made on project leaders, they accede to the demands – or even welcome them. So, who is colonizing whom?
Parallel identity construction
The answer to the question in the previous paragraph is complicated by the fact that the project managers who participated in the study wielded considerable influence over the product they were creating. Indeed, this was the intent of the company. That this is so is illustrated by the remarks of an HR director who was involved in the selection of a project leader:
[the candidate] was, along with his competence regarding car development, chosen because he was an almost perfect customer targeted for the V70….Putting him on the management team of the new car project gave him an opportunity to develop the perfect car that satisfied his lifestyle, and the company got the intended car developed. We also used him as an example of our projected customer in a part of our marketing campaign for the V70.
So, selection for prized positions within the company depended on the technical competence and lifestyles of the candidates. In turn, the chosen ones had an opportunity to stamp their personality (identity?) on the product they created. Identities of people, projects and products were indeed entwined.
Discussion
The authors note that, once selected, project leaders were given considerable autonomy in running their projects. This included the freedom to make choices that influenced the product. Seen in this light, project leaders could stamp their identity on the products they were involved in creating. However, there were limits to their independence. After all, project leaders depended on the organisation for their livelihoods. Furthermore, their independence was constrained by organizational rules and norms.
Taking another view, one could view the behaviour of the project leaders as being self imposed in the sense that the long hours they put in could be seen as some kind of an addiction to work. Workaholism is an apt term here, I suppose. At first, the desire to become project leaders spurred them to work hard and once the position was attained they felt the desire to work harder still, possibly to prove that they were worthy of the trust reposed in them by the organisation.
Taking yet another view, one could say that the project leaders had limited choices in both their private and professional lives. On the one hand, there are professional expectations from the company and on the other, expectations from family and friends. Once the individual chose to become a project leader, the choices on offer in both spheres were limited by the choice they made and their personal priorities. All the project leaders interviewed gave their projects priority over all other aspects of their lives. This isn’t surprising because the selection process ensured it. Nevertheless, it does imply that the project leaders accepted that the organisation formed a major part of their self-identities.
It has to be acknowledged that because of their interest in cars, the project leaders were happy to work insane hours. However, equally, the company consciously exploited this interest to the extent that the project leaders believed the project to be the most important aspect of their lives.
Conclusions
Several researchers have suggested that organisations regulate individual identities in a manner that aligns them with organizational objectives (see this paper by Alvesson and Wilmott, for example). At first sight, the foregoing discussion is a case in point. Yet, to some extent, the project leaders in the study believed they had free will – that they made the choices they did because they wanted to. But in the end, the project (and organisation) “wins”. As the authors put it:
To some extent, the project leaders knew they were subjects of control, colonization, and regulation, and yet they chose this career path with full recognition of the consequences for their work/life balance. Their choice meant accepting long workdays and potential emotional and psychological damage in exchange for professional status, job fulfilment, and high compensation. The colonization had consequently moved beyond organizational controland corporate influence. The project leaders were colonized by the projectified society,a situation which made them aspire to the core constructions of the project management..
I suspect that many project managers – particularly those working on high profile projects within their organisations – will find themselves agreeing with the authors. Most of us choose to work on ever more challenging projects to further our professional experience, “make a difference” or even “influence the product”. Regardless of our motives, we generally believe that we make the choice voluntarily. The question is: is this true?
Doing the right project is as important as doing the project right
Introduction
Many high profile projects fail because they succeed. This paradoxical statement is true because many projects are ill-conceived efforts directed at achieving goals that have little value or relevance to their host organisations. Project management focuses on ensuring that the project goals are achieved in an efficient manner. The goals themselves are often “handed down from above”, so the relevance or appropriateness of these is “out of scope” for the discipline of project management. Yet, the prevalence of projects of dubious value suggests that more attention needs to be paid to “front-end” decision making in projects – that is, decision making in the early stages, in which the initiative is just an idea. A paper by Terry Williams and Knut Samset entitled, Issues in front-end decision making on Projects looks at the problems associated with formulating the “right” project. This post is a summary and review of the paper.
What is the front-end phase of the project? According to Williams and Samset, “The front-end phase commences when the initial idea is conceived and proceeds to generate information, consolidate stakeholders’ views and positions, and arrive at the final decision as to whether or not to finance the project.”
Decisions made in the early stages of a project are usually more consequential than those made later on. Most major parameters – scope, funding, timelines etc. are more or less set in stone by the time a project is initiated. The problem is that these decisions are made at a time when the availability of relevant information is at its lowest. This highlights the role of sound judgement and estimation in decision making. Furthermore, these decisions may have long-term consequences for the organisation, so due care needs to be given to alignment of the project concept with the organisation’s strategic goals. Finally, as the cliché goes, the only constant is change: organisations exist in ever-changing environments, so projects need to have the right governance structures in place to help navigate through this turbulence. The paper is an exploration of some of these issues as they relate to front-end decision making in projects.
Defining the project concept
Williams and Samset define the terms concept as a mental construction that outlines how a problem will be solved or a need satisfied. Note that although the definition seems to imply that the term concept equates to technical approach, it is more than that. The project concept also includes considerations of the outcomes and their impact on the organisation and its environment.
The authors emphasise that organisations should to conceive several distinct concepts prior to initiating the project. To this end, they recommend having a clearly defined “concept definition phase” where the relevant stakeholders create and debate different concepts. Choosing the right concept is critical because it determines how the project will be carried out, what the end result is and how it affects the organisation. The authors emphasise that the concept should be determined on the basis of the required outcome rather than the current (undesirable) situation.
When success leads to failure
This is the point alluded to in the introduction: a project may produce the required outcomes, but still be considered a failure because the outcomes are not aligned with the organisation’s strategy. Such situations almost always arise because the project concept was not right. The authors describe an interesting example of such a project, which I’ll quote directly from the paper:
One such example is an onshore torpedo battery built inside the rocks on the northern coast of Norway in 2004 (Samset, 2008a). The facility was huge and complex, designed to accommodate as many as 150 military personnel for up to three months at a time. It was officially opened as planned and without cost overrun. It was closed down one week later by Parliamentary decision. Clearly, a potential enemy would not expose its ships to such an obvious risk: the concept had long since been overtaken by political, technological, and military development. What was quite remarkable was that this project, which can only be characterized as strategic failure, got little attention in the media, possibly because it was a success in tactical terms.
A brilliant example of a successful project that failed! The point, of course, is that although the strategic aspects of projects are considered to be outside the purview of project management, they must be given due consideration when the project is conceptualized. The result of a project must be effective for the organisation, the efficiency of project execution actually matters less.
Shooting straight – aligning the project to strategic goals
Aligning projects with strategic goals is a difficult because the organizational and social ramifications of a project are seldom clear at the start. This is because the problem may be inherently complex – for example, no one can foresee the implications of an organizational restructure (no, not even those expensive consultants who claim to be able to). Further, and perhaps more important, is the issue of social complexity: stakeholders have diverse, often irreconcilable, views on what needs to be done, let alone how it should be done. These two factors combine to make most organizational issues wicked problems.
Wicked problems have no straightforward solutions, so it is difficult if not impossible to ensure alignment to organizational strategy. There are several techniques that can be used to make sense of wicked problem. I’ve discussed one of these – dialogue mapping – in several prior posts. Paul Culmsee and I have elaborated on this and other techniques to manage wicked problems in our book, The Heretic’s Guide to Best Practices.
One has to also recognize that the process of alignment is messier still because politics and self interest play a role, particularly when the stakes are high. Further, at the individual level, decisions are never completely objective and are also subject to cognitive bias – which brings me to the next point…
Judgement and the formulation of organizational strategy
Formulating organizational strategy depends on making informed and accurate judgements about the future. Further, since strategies typically cover the mid to long term, one has to also allow some flexibility for adjustments along the way as one’s knowledge improves.
That’s all well and good, but it doesn’t take into account the fact that decision making isn’t a wholly rational process – humans who make the decisions are, at best, boundedly rational (sometimes rational, sometimes not). Bounded rationality manifests itself through cognitive biases – errors of perception that can lead us to making incorrect judgements. See my post on the role of cognitive bias in project failure for more on how these biases have affected high profile projects.
The scope for faulty decision making (via cognitive bias or any other mechanism) is magnified when one deals with wicked problems. There are a number of reasons for this including:
- Cause-effect relationships are often unclear.
- No one has complete understanding of the problem (the problem itself is often unclear).
- Social factors come into play (Is it possible make an “unbiased” decision about a proposed project that is going to affect one’s livelihood?)
- Consequent from points 1 through 3, stakeholders perceive the problem (and its solution) differently.
It is worth pointing out that project planning is generally “less wicked” than strategy formulation because the former involves more clear cut goals (even though they may be wrong-headed). There is more scope for wickedness in the latter because there are many more unknowns and “unknowables.”
Why estimates are incorrect
Cost is a major factor in deciding whether or not a project should go-ahead. Unfortunately, this is another front-end decision; one which needs to be made when there isn’t enough information available. In his book, Facts and Fallacies of Software Engineering, Robert Glass names poor estimation as one of the top causes of project failure. This is not to say that things haven’t improved. For example, Agile methods which advocate incremental/iterative development continually refine initial estimates based on actual, measurable progress.
Techniques such as reference class forecasting have been proposed to improve estimation for projects where incremental approaches are not possible (infrastructural projects, for example). However, this technique is subject to the reference class problem.
Finally, all the aforementioned techniques assume that reliable information on which estimates can be based is a) available and b) used correctly. But this is just where the problem lies: the two key factors that lead to poor estimation are a) the lack of knowledge about what exactly the work entails and b) the fact that people may misunderstand or even misrepresent the information if it is available.
Governance in an ever-changing environment
A negative consequence of the quest for organizational agility and flexibility is that organizational environments are turbulent. The main point of the paper is that traditional project management (as laid out in frameworks such as PMBOK) Is ill-suited to such environments. As they state:
The key point in this article, however, is that the environment in which most projects operate is complex and turbulent, and conventional project management is not well suited to such conditions, despite the attraction of project organization to companies in fast-moving environments seeking agility and responsiveness…
Yet, ironically, this uncertainty is the reason for the spectacular growth in adoption of project management methodologies (see this post for a discussion of a relevant case study).
For project management to be truly useful, it must be able to cope with and adapt to turbulent environments. To this end, it may be best to view project management as a set of activities that emerge from a real need rather than an arbitrary imposition dictated by methodologies that are divorced from reality. This is nothing new: iterative/incremental methods, which advocate adaptation of methods to suit the environment, are a step in this direction.
Adaptive methods are obviously easier to apply on smaller projects than larger ones. However, one could argue that the need for flexibility and adaptability is even greater on massive megaprojects than smaller ones. A major consequence of a changing environment is that people’s views on what needs to be done diverge. Recent work in applying dialogue mapping to large project environments shows that it is possible to reduce this divergence. Getting people on the “same page” is, I believe, the first step to successful governance, particular in unstable environments.
Lack of information
The most important decisions on projects have to be made upfront, when little or no reliable information is available. The authors argue that the lack of information can actually be a benefit in front-end decision for the following reasons:
- Too much information can lead to confusion and analysis paralysis.
- Information can get out of date quickly – forecasts based on outdated information can be worse than useless because they can mislead.
- It is often hard to tell between important and irrelevant information. The distinction may only become clear as the project proceeds.
Be that as it may, one cannot deny that front-end decision making is hampered by the lack of relevant information. The real problem, though, is that decisions are often made by those who cannot tell the difference between what’s important and what’s not.
Conclusion
The article is an excellent summary of the major impediments in front-end decision making on projects. Such decisions have a major impact on how the project unfolds, yet they are often made with little or no consideration of what exactly the project will do for the organisation, or what its impact will be.
In my experience, front-end decisions are invariably made in an ad-hoc manner, rooted more in hope and fantasy than reality. A first step to ensuring that organizations do the right project is to ensure that all stakeholders have a common understanding of the goals of the project – that is, what needs to be done. The next is to ensure a common understanding of how those goals will be achieved. Such stakeholder alignment is best achieved using communication-centric, collaborative techniques such as dialogue mapping. Only then, after ensuring that one is doing the right project, does it make sense to focus on doing the project right.
Eight to Late 