Archive for the ‘Project Management’ Category
Rumours of a new project management paradigm
Many project managers spend a great deal of time on the technical aspects of project management, often overlooking the “softer”, people-oriented, issues that can derail a complex project. Although many books – including the gospel according to PMBOK – stress the important of soft skills, the current paradigm of project management is essentially mechanistic. In simple terms this means that the discipline is built on the assumption that future outcomes can be predicted accurately based on current information and actions. It is also implicitly assumed that human actions, interactions (and consequences thereof) can be objectively observed and then corrected or controlled.
A paper entitled Mapping the Strange Landscape of Complexity Theory and Its Relationship to Project Management, published in June 2007 of issue of the Project Management Journal challenges this paradigm of project management [Aside: The print version of the paper has an even more memorable title – see the reference at the end of this post]. According to the authors, recent advances in the study of complex systems suggest new ways of looking at the discipline. The idea of applying concepts from complexity theory to the social sciences is not new. In fact, a quick search revealed an introductory book on the topic in five seconds flat. What’s new, the authors claim, is the application of these ideas to project management.
In the paper, the authors start by briefly describing some well-established concepts from complexity theory which form the basis of their proposed paradigm. It would take me too far afield to discuss these in detail, so I refer my readers to Wikipedia for details and further references:
It is broadly accepted that many of the above concepts played an important role in modifying, if not overthrowing, the mechanistic (or Newtonian) paradigm in the natural sciences. In particular, these concepts led to the invention and adaptation of a host of new qualitative and quantitative research methods. Based on this, the authors make the following plea, and I quote : “ …If even pure science is finding the need to become more flexible in its research methods while not relapsing into ‘anything goes’, is it perhaps too much to hope that research into projects and their management will take account of these developments…”.
The authors then proceed to outline how the discipline of project management might take account of the new developments. As a first step, they highlight connections between complexity theory and the recent development of the concept of complex responsive processes of relating (CRPR) in organizational theory. This concept (which I confess, I don’t fully understand) is apparently a means of looking at complexity in organizations in a manner that emphasises interactions or communication among people. As I understand it, CRPR is concerned with how conversation and other communication patterns in specific situations are determined by, and in turn determine or modify, power relationships in organizations. An organization is thus viewed as an emergent property of interaction between humans, who use language to converse and also to negotiate status and power. Basically- again, as I understand it – the organization is created by individuals communicating (or relating) with each other in complex ways.
The outcome of a specific instance of interaction (or relating) between individuals is unpredictable because people are different, and there is an element of spontaneity to any specific interaction, even those that occur regularly. This allows for the possibility of transformation and novelty as the organisation continually evolves via CRPR. The future is thus continually being constructed through processes of interaction. Moreover, since outcomes are not predictable to a fine level of detail, people involved in these interactions experience anxiety. This anxiety has to be acknowledged and managed. However, as all individuals in the organization are linked in a complex web of evolving relationships, managers themselves are participants in these processes of relating. A manager (however high up or powerful) cannot be an objective observer of the system, as her or she is a part of it. An organization, can thus be viewed as a complex system displaying properties analogous to those displayed by complex physical systems (unpredictability and emergence, among others)
Some implications of CRPR for project management include:
-
Any project structures (work, tools, plans) must be viewed as forming and being formed by interactions between people (in a complex feedback loop). Projects are thus social arrangements, not structures.
-
Power is located in the processes of relating, rather than individual managers. So, close attention should be paid to importance of local communication between team members.
-
Managers need a “new” set of competencies that might include: a) sensitivity to patterns of conversations, and the ability to enable conversations that enhance learning and generate knowledge and b) the ability to deal with anxieties that are an inevitable consequence of constant change (i.e. evolving relationships).
The authors conclude by discussing some implications of complexity theory (and CRPR in particular) for what happens when people work together on project teams. This ties in with the much neglected “soft side” of project management mentioned in the first line of this post.
A caveat is in order at this point: although I do know something about physics, I’m no expert in the social sciences. Therefore I may well have misinterpreted the authors’ meaning and intent in areas where they discuss CRPR. What’s presented here is my interpretation of their words. Having said that, I can now venture a few comments on the paper in the spirit of a curious layman. They are:
-
The word “complex” and “complexity” is used in two senses in the paper: first, in the context of complex projects and second in the context of complexity theory and complex systems. The former (what is a complex project?) is left undefined in the paper. However, from what the authors discuss, it appears (to me, at least) that the ideas from complexity in the second sense apply to any kind of project, not just complex ones.
-
The connections or analogies between the eight or nine concepts from physics and CRPR are not obvious from a reading of the paper. I can see some connection between CRPR and unpredictability and emergence, and have alluded to this in an earlier paragraph. But the others, I don’t see at all. This may well be due to my lack of knowledge of the social sciences and CRPR in particular.
-
The physical concepts of complex systems have very precise meanings (as readers might gather from following the Wikipedia links above). However, the social analogues of these concepts are considerably harder (for me) to understand. Again, this is likely due to my lack of knowledge than any fault of the authors.
Despite my aforementioned quibbles, I found the paper very intriguing, as it dealt with issues that are of interest to me as a project manager. I look forward to the day when the social and people aspects of projects become the prime focus of project management, but I think we’re a long way from that at present. To conclude, I refer once again to the title of the print version of the paper : Dorothy and Toto may know they’re not in Kansas anymore, but they haven’t yet figured out where they are.
Reference:
Cooke-Davies, T., Cicmil, S., Crawford, L., and Richardson, K., We’re not in Kansas anymore, Toto: Mapping the strange landscape of complexity theory, and its relationship to project management, Project Management Journal, 38 (2), 50-61 (2007).
Manage multitasking
The costs of multitasking are well known. Firstly, it takes time for the human brain to switch from one task to another. This is analogous to the overhead of context switching in computers (the term “multitasking” itself originated in computer science). Secondly, multitasking delays the delivery of all tasks simply because a given task is not finished in a single go.
The evils of multitasking have been commented on in the popular press, with CNN, Time and even the occasional newspaper article warning against it. Despite the general awareness that it is counterproductive, developers working in corporate IT departments are routinely expected to juggle several tasks in the course of their day-to-day work. Furthermore, I often find that the “ability to multitask” is stated as a requirement in job advertisements. For example, here are excerpts from a few IT development job ads that appeared recently in seek.com:
-
Software engineer in Auckland: …Must have the ability to multi task and prioritise…
-
Web designer / Applications engineer in Sydney: … Must be able to multi-task…
-
Systems implementation specialist in Sydney: …Should be able to multitask and work on multiple projects…
The expectation is that employees must be able to juggle tasks and even projects (!) as required. Given this, are there things a frontline technical / project manager can do to alleviate multitasking-stress on their teams? Yes there are, and here are a few that’ve worked for me:
-
Prioritise work: You’re never going to get everything done concurrently. Given the workload on your team, some things may never get done at all. It is, therefore, paramount that work be done in order of business priority. Obviously the prioritisation needs to be decided in consultation with the business. Under no circumstance should it be based on technology (I’ve seen this happen) or developer preference (seriously – I’ve seen this too!).
-
Get a high-level view of everyone’s workload: As a part of the weekly routine, get each team member to send you a rolling workplan for the next month or two (I go with 4 weeks). The plan should list tasks that the person anticipates doing each week, along with a time estimate per task. The estimate should be at a granularity of no less than 0.5 days or, ideally, 1 day (see next point). This gives you a high level view of each person’s workload, and alerts you to potential multitasking problems.
-
Align task switches with the end of the day or week: Encourage people to work on a single task per day, or whole multiple of a day (unless it’s a shorter duration task, of course). This way, task switches happen at the end of a work day, thereby allowing time for the mind to orient itself to working on another task.
-
Plan on a four day week for development work: Assume that programmers have only four dev days – i.e. days for development work. Keep a whole day aside for other stuff such as ad-hoc requests, support, meetings and administrative work. Depending on the situation in your shop, you may even have to reduce the number of dev days to three.
-
Insist on decent work hours: It is OK to work overtime once in a way – when a project deadline approaches, for instance. However, it is definitely not OK to expect the team to sustain unreasonable work hours over an indefinite period.
-
Minimise Distractors : Don’t clutter developer work weeks with distractors like unnecessary (or unnecessarily long!) meetings. Your job is to remove distractors, not add to them.
-
Provide Support :As Joel Spolsky mentions in an interview – “I always think of it” (i.e. management) as more of a support role – like moving furniture out of the way so they can get things done – than an actual leadership role.” Specifics on how one might do this will vary from situation to situation. In some cases you may need to act as a gatekeeper – filtering requests from the business. In others, you may need to answer high-level questions and provide guidance. In a nutshell – do whatever it takes to help your team do their job.
-
…But don’t interfere: I don’t think I need to elaborate on this. You don’t want to give people the impression that you aren’t confident in their ability to handle their work. Such behaviour is tantamount to micromanagement which, as I’ve mentioned in an earlier post, is a definite no-no.
-
Know when to push back on your managers: Take a stand when your management makes unreasonable demands. Explain why it won’t work, and suggest alternatives. This is a an opportunity to earn your stripes as a manager (and your team’s respect).
Given the increasing workload and resource constraints that corporate IT works under, there’s often no option but to multitask. This can have negative consequences on team performance and morale. Some of the techniques discussed here may help avoid and/or manage these consequences.
Project management in an Asian context
Since project management, as a discipline, originated in a Western culture, incompatibilities between project management values / beliefs and those of traditional Asian cultures are to be expected. Most readers who have worked both in Western and Asian organisations will be well aware of these differences. A recent paper entitled Cultural barriers to the use of Western project management in Chinese enterprises: Some empirical evidence from Yunnan province explores these differences in the context of Chinese organisations (see reference at the end of this post). Specifically, the authors look at four contrasting value/belief pairs, which cover the major differences between the two cultures:
- Integration management vs. doctrine of the mean: This refers to the contrast between project management practices – which generally emphasise integrating opinions, resolving conflicts and confronting risks – as opposed to traditional Chinese (and dare I say, Asian) practices in which confrontations and risks are avoided as far as possible.
- Horizontal management vs. strong hierarchy: This refers to the incompatibility between project management, which works best in a flat (or project-oriented) hierarchy, and the strong vertical hierarchies prevalent in Chinese organisations. The latter organisational structure tends to emphasise superior-subordinate relationships in which “questioning the boss” is not encouraged.
- Team consciousness vs. family consciousness Project teams are generally temporary, and tend to emphasise collaborative work across functions and merit-oriented performance evaluations. On the other hand, Chinese culture values long-term family and kinship relationships. These are not always compatible with cross-functional (or even intra-functional!) collaboration or performance-based recognition.
- Task orientation vs. boss orientation In project management getting the job done is paramount, whereas in Chinese culture the emphasis is on keeping the boss happy.
The authors developed a questionnaire to explore the relative importance of each of the above value/belief pairs. Based on the questionnaire, they conducted a survey involving respondents from a wide variety of industries in Yunnan province.
The analysis of the results revealed that the major cultural barriers to project management in Chinese organisations are the last three items: i.e. strong hierarchy, family consciousness and boss orientation. It is interesting that a majority of the respondents thought that the doctrine of the mean was consistent the integrative nature of project management.
The authors also find that the barriers tend to be larger in state owned organisations than in private or joint ventures. Further, within state-owned organisations, older ones tended to have larger barriers than younger ones.
Also interesting is the find that project management training has a critical effect on lowering cultural barriers: As more individuals in an organisation received relevant training, the organisation became more supportive of project management practices.
The authors end with the caveat that their conclusions are based on the result of a single (yet representative) survey, and must therefore be treated as a pilot study.
I found this paper worth reading because it articulates and explores some of the contrasts I have noticed in my own work with organisations in India, Australia and the US. In my experience, many of the observations made regarding cultural barriers to PM practices apply to (non-Chinese) Asian cultures as well. Those of you who work with cross-cultural project teams – particularly those across Asian and Western cultures – may find this paper a worthwhile read.
Reference:
Wang, X. and Liu, L., Cultural barriers to the use of Western project management in Chinese enterprises: Some empirical evidence from Yunnan province, Project Management Journal, 38(3), 61-73 (2007).
Eight to Late 