Archive for the ‘Project Management’ Category
On the role of processes in project management
The word process has several different connotations – an online dictionary lists more than twenty meanings of the word. Amongst these, the following is the sense in which the word is used when we speak of a project management process:
Process (noun): a systematic series of actions directed to some end.
The key word here is systematic – which (again from the same online dictionary) means according to a method. The word process thus has a very precise meaning – a series of methodical actions which are directed to some (definite) end. The word, as used in normal parlance, evokes a world in which a sequence of well-defined actions lead to certain desired results. This may be an excellent approximation to reality on the manufacturing shop-floor, but is little more than an illusion in the messy world of projects. Having made a potentially controversial statement, I’d better clarify what I mean. I do so below.
The objective in manufacturing is to mass-produce items in a controlled and repeatable manner. In constrast, in projects the aim is to create unique products (or services). In the former case, it makes perfect sense to formalise actions required to create the product into well-defined and detailed processes. Such processes tend to be very prescriptive: e.g. immerse the widget in the solution for 3 minutes, then air dry at 200 C for 2 minutes. Such prescriptiveness is required for ensuring repeatability (of processes) and reproducibility (of results). It also confers an advantage in quality improvement efforts: such processes can be tweaked in a controlled fashion whilst maintaining a sensible baseline for comparison. In the case of projects, though, the notion of a process isn’t quite the same. Given that every project aims to create a one-off, unique product, how does the idea of “systematic actions directed to an end” apply? I take a brief look at some half-answers below.
Wikipedia defines a project management process as a management process of planning and controlling the performance or execution of a project. The definition isn’t much help, so let us start with a commonly accepted example of a project management process instead: schedule development or scheduling (as per PMI or PRINCE2). Now, although schedule development has a bunch of inputs, tools and techniques, and outputs, these leave much open to interpretation. That is, they aren’t as prescriptive as processes in manufacturing. They don’t even come close to being “a systematic series of actions directed to some end.” Yet, they are often considered by project managers as being so. That, in my opinion, is the problem. Let me hasten to add that frameworks and methodologies aren’t at fault here – most do emphasise that they provide guidelines not recipes. As I have mentioned in an earlier post, this is largely a problem of our own making. To paraphrase the Bard: The fault, dear Brutus, is not in our processes, But in ourselves, that we are obsessed with them.
The history of project management yields a clue as to why the notion of process – despite its shortcomings – is so ingrained in project management theory and practice. As Patrick Weaver points out, the roots of modern project management lie in concepts of scientific management, or Taylorism as it is called after its founder, Fredrick Taylor. To quote Weaver, “…Project management has evolved in its specialist area along very similar lines to general management theory. In early days, project management closely mirrored the classical school of management with a focus on scientific processes…” Why this early focus on scientific processes? Well, Weaver mentions that, “…it is entirely reasonable to argue that the evolution of modern project management is a direct consequence of the need for professional schedulers for a forum to discuss and develop their new discipline….” Since scheduling is arguably the most mathematical (or statistical) process in the project management process pantheon, the focus on scientific management is really no surprise.
In recent years things have moved on. In their paper on future challenges and opportunities in project management (which I have reviewed in an earlier post), Shenhar and Dvir point out that there are three central paradigms of project management: operational/process, team/leadership and business/strategic. The process-based approach, rooted in scientific management, corresponds to the first. The team/leadership view puts people at the centre of focus, and as we all (should!) know, people aren’t as simple as processes. The last perspective is the big-picture: project management as a strategic tool. As is the case with people, this too cannot be reduced to formulaic processes. The fact that the latter two perspectives have been getting more attention in recent years indicates that things are changing. So, perhaps it is only a matter of time before the practice of project management is cured of its process obsession.
Related posts:
Blinded by the light: when project management methodology matters more than project success.
Increasing your team’s bus factor
Wikipedia defines the bus factor as the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed. Although most discussions about the bus factor revolve around software projects, the considerations apply to any situation where important, specialised knowledge is held by a small number of people. For example, an IT department where there is little or no cross-training or cross-over in roles would have a low bus factor.
Increasing the bus factor amounts to spreading the knowledge around so that there is a degree of redundancy in skills and knowledge within a team. This ensures that work will go on even if a key person has an unfortunate encounter with a public transport vehicle. It is clear that every manager should aim to increase the bus factor for all processes that come under his or her purview. Below I outline a few suggestions on how one might do so.
- Keep things simple: Keep processes as simple as possible (but no simpler!). This ensures that the processes are easy to maintain and hence easy to teach to others. Simplicity usually boils down to two things: a) using the right tool for the right job, and b)using the most straightforward way to achieve what’s needed. I have seen several processes that are needlessly complicated by inappropriate technologies or use of technologies. To elaborate on the latter, processes are overengineered often for no other reason than to demonstrate the cleverness of the process creator. Avoid creating such Rube Goldberg processes at all costs!
An important, simplicity related factor (from the bus point of view) is to use technologies that are familiar to more than one person on the team. This builds in a high bus factor from the start. - Document, document, document: This is a no-brainer, but people still think they can get away with “doing it first and documenting it later.” Documentation done after the fact is often less than useful because the author forgets to include some (many?) small detail(s) which, of course, turn out to be critical ones in times of trouble. What should a process document contain? Enough to help someone figure out what, how, where, when – what it does; how it’s run; where it sits (servers etc.); and when and how often it’s run. The documentation should also include some basic troubleshooting information and references to relevant sections of manuals.
Another important point is to keep the documentation in synch with the process – i.e. to update all relevant documents whenever the process is modified. This is essential because process documentation is your only guide when the owner of a process with bus factor 1 goes under the bus instead of getting on it.
A small word about style is perhaps in order – process documentation should adhere to the 3Cs of clarity, conciseness and comprehensibility. Yes, it is possible to write in a way that achieves all three, although this isn’t evident in my writing. - Encourage people to pick up secondary skills: The first two points dealt with process and documentation. However, in the end, it is people who make things happen. Despite well-engineered and documented processes, one can still have a low bus factor if the team doesn’t have skill redundancy. Who’ll look after the databases the when the DBA goes under (or is run over by) a bus? This question wouldn’t have to be asked if someone had been cross-trained in basic DBA tasks. As far as possible, every one on the team should have at least one secondary skill that will enable them to cover for someone else.
All this stuff is obvious. Yet I’ve seen more than a few outfits with very low bus factors (sometimes as low as zero. Yes, really!), so perhaps it isn’t taken as seriously as it should be. I therefore close with this exercise: take stock of the activities and processes that your department or team supports. Do you see any danger zones with low bus factors? If the answer’s affirmative, get moving before a bus comes around.
Motivation in project management
Introduction
In recent years, the focus in project management has shifted from technical aspects of the profession (scheduling, planning etc.) to people-oriented factors such as motivation. This is reflected both in professional practice and academia. On the one hand there is a growing interest in courses on soft skills and leadership; on the other, an increasing number of research papers on these issues. In fact, I have come across two papers on motivation published in the Project Management Journal (PMJ) within last six months. I reviewed one some time ago, in my post entitled Motivation Rehashed. Here, I review the other: a paper entitled, Motivation in Project Management: The Project Manager’s Perspective, published in the June 2008 issue of the PMJ.
First a brief look at what the paper is about. In the introduction the authors emphasise that, “the interpersonal skills needed to motivate a project team are a project managers most important asset.” Despite this, there is no clear definition of motivation in the literature. For example, some researchers have explained motivation as, “the level of energy people bring to their work,” whereas some others have viewed it as being centred on “expectations and reinforcements.” As a consequence, the authors claim there’s still a good deal of confusion about what motivates people. To address this, the paper begins with a literature review and an overview of the theoretical basis of motivation research. The emphasis is on research relating to motivation in the context of project teams. The review is followed by original research on project managers’ perceptions of how they are able to influence motivation. The work is based on data collected from practising project managers.
Background and Literature Review
Recent research indicates that asking the question, “How do I motivate my team members?” might actually be counterproductive because most people begin new initiatives with enthusiasm and a desire to contribute to, and consequently feel proud of their work and organisations. This suggests that project managers may be better served by focusing on how one can help people maintain their motivation levels through their work tasks and roles. The PMBOK definition of motivation which is, “energising people to achieve high levels of performance and to overcome barriers to change”, suggests that there is more to motivation than “maintenance of enthusiasm” by doing the “right things.” The authors delve into this in some detail, as I discuss next.
Motivation is inextricably linked with leadership and power. Research has shown that use of autocratic, coercive or laissez-faire leadership styles can have a detrimental effect on motivation. This is obvious to those who have worked with such managers! More effective leadership styles emphasise the leader as an initiator, negotiator, coach and participant. The last one is interesting – if a leader is viewed as a participant – being “one of the group” – loyalty and motivation emerge more unconditionally. Such leaders employ a participatory approach that includes all team members in a meaningful way.
After discussing motivation and its connection to leadership, the authors move on to reviewing research on the sources of motivation – i.e. where motivation comes from. Motivation can be viewed as intrinsic or extrinsic. In a nutshell, the former is a desire to do something because one finds it interesting, whereas the latter is a desire to do something because of some anticipated rewards not related to the activity. Research indicates that an inclusive leadership or management style is conducive to intrinsic motivation whereas an exclusive approach (coercive or authoritarian) relies on extrinsic motivation. In their book entitled, In Search of Excellence, Tom Peters and Robert Waterman state that the best companies focus on fostering intrinsic motivation in employees.
The difference between extrinsically and intrinsically motivated employees was explored by Gagne and Deci in their paper on the relationship between work motivation and self determination theory (SDT). In SDT, states of motivation are viewed as a continuum ranging from amotivation (no motivation) to intrinsic motivation. SDT uses the terms autonomous and controlled motivation: the former corresponding to intrinsic and the latter to extrinsic motivation. The Gagne and Deci model, identifies four stages of extrinsic motivation, starting from external regulation wherein the person works only to obtain a non-work related reward (no self determination) , to integrated regulation wherein there is some self-determination because the person has internalised some of the reasons for doing the work. Integrated regulation is thus just a small step away from intrinsic (or autonomous) motivation. Another interesting research finding is that intrinsic motivation is fragile in that the presence of a person with lower motivation on a team can reduce motivation levels of other team members.
Next, the authors highlight some practical motivation-controlling factors, linking these to research regarding the efficacy and limitations of each:
- Optimising energy: This refers to the innate capacity for work, which differs from person to person. Research by Welbourne and coworkers shows that there is an optimum zone of employee energy, and that this limit should generally not be exceeded. This zone varies from person to person. Furthermore, it turns out that managers can assist employees to stay in the zone, or even raise it by timely interventions and enhanced one-to-one communication.
- Autonomy: In an earlier post, I have written about the importance of empowering people to make decisions relating to their work. Research indicates that autonomy results in better job satisfaction and, hence, increased intrinsic motivation. One practical way to do this on projects is to specify the deliverable (the “what”), leaving decisions regarding the method of creation (the “how”) to the responsible team member(s).
- Feedback: Research shows that positive, constructive feedback enhances motivation. Negative feedback, on the other hand, reduces both intrinsic and extrinsic motivation. Perception of feedback is important too: feedback perceived as being controlling will have a negative effect on motivation, whereas feedback seen as being competence related can have a positive effect if properly delivered.
- Rewards and recognition: Rewards are related to extrinsic and recognition to intrinsic motivation. In their book, Peters and Waterman point out that successful companies make it an organisational goal to repeatedly recognise employee contributions. Research by Deci and associates indicates that rewards undermine intrinsic motivation, especially if those rewards are linked to specific tasks. This is particularly interesting because many organisations tend to use reward systems based on task or project performance. Also relevant to project work, is the finding that teams should be rewarded as a whole. This is controversial because rewarding all team members equally can create conflicts if certain individuals are perceived as being “freeloaders.” On the other hand, though, both Deming and Drucker point out that individual rewards will eventually lower (team) productivity and morale. This because they lead to a perception of inequity amongst team members. Deming also pointed out that merit systems based on management by objectives are a major source of inequity (see point 11b of his well-known 14 points).
Following the discussion of motivational factors, the authors provide a brief organisational perspective on motivation vis-a-vis project team motivation. As far as organisations are concerned, research by Sirota and coworkers indicates that equity, achievement and camaraderie are factors that are strongly correlated to employee satisfaction within organisations. Equity relates to the perception of fairness; achievement to pride in one’s work and associated recognition; camaraderie to cooperation and a feeling of community. It is vey interesting that these factors were found to be significant regardless of gender, ethnicity or level within the organisation! Clearly, there are differences between organisations and project teams. The most obvious differences are: a) teams work within larger organisations, and b) projects, unlike organisations, have distinct stages. This brings up questions about how these differences are perceived and handled by project managers – questions that are addressed in the next section.
I found the authors’ literature review and associated discussion very interesting, particularly because they highlight some non-intuitive aspects of motivation. Further, the review provides practitioners some excellent suggestions for further reading on the topic.
Having painted the background with a comprehensive literature review, the authors move on to a discussion of their research on project managers’ perceptions of team motivation.
Project Managers’ perceptions of motivation
The authors pose the following research questions:
- What are the factors that most commonly cause low levels of motivation on project teams?
- What are the most successful (intrinsic) motivation techniques in project environments?
- Can a project manager influence team motivation levels despite (negative) organisational influences?
- Should different motivation techniques be applied at different stages of a project?
The authors conducted an online survey of practising project managers using a questionnaire that was based on the above questions. They received 115 completed questionnaires which, on analysis, revealed the following results.
Factors lowering team motivation:
The authors found that the following factors were the greatest team demotivators (in order of importance):
- Missing top management support.
- Personal conflicts between team members.
- Inequity in reward system.
- Schedule conflicts.
- Time overruns.
Having suffered the ill-effects of each of these at one time or another, I think there should be no surprises here for most practitioners (excepting perhaps the order). Interestingly, content analysis of the results showed that each of the above factors are closely related to the project manager’s ability to communicate effectively. A project manager who can communicate well – be it with top management or team members – will be able to lessen the impact of the above factors.
The research also probed the de-motivational effects of changing each of the classical constraints of scope, time, quality and cost. It was found that scope had the largest demotivating effect followed by time, quality and cost. This highlights the importance of clear scope definition and management throughout the project.
Successful motivation techniques
Most of the responses regarding successful motivation techniques centred on the importance of communication. For example, over 90% of respondents agreed that providing positive, constructive feedback is an effective motivator. Many also agreed that personal conversations (e.g. Management by Walking Around) is also a useful technique. Respondents also agreed that it was important to develop an understanding of individual team members. This would be important, for example, in ensuring a good match of skills (and desires!) to tasks assigned.
Participation was also found to be a good motivator. For instance, a large number of respondents indicated that involving the team in creating the work breakdown structure is a good motivational technique as it offers the team involvement in a key aspect of the project at an early stage. What struck me was that “warm and fuzzy” factors such as involvement, communication, responsibility and trust are found to be very important to creating and fostering motivation. The hard-headed project manager with little or no time for niceties would do well to take note – and, yes, there are a few of those around!
Project team motivation vs. organisational motivation
Although organisational factors such as culture, strategy etc. have a clear influence on project teams, over 60% of respondents felt that project managers can influence team motivation positively, despite negative organisational factors. Content analysis of the data further revealed that setting of team goals that are within the project manager’s control can help motivate the team. On the other hand, scope change was found to have a demoralising effect.
Regardless of the mechanics of how project managers motivate teams in the face negative organisational influences, it is interesting that many feel that they can do so. Even those who struggled to motivate their teams on their last project indicated that it was possible to create a positive subculture within a larger, negative organisational culture. Is this just wishful thinking, or is it based on something more solid. Unfortunately the authors can’t (or don’t) tell, so neither can I!
Motivation at different stages of a project
The results indicate that team motivation generally declines as the project progresses. Over 80% of the respondents agreed that motivation is high at the start whereas less than 50% thought that it was high towards the closing stages. On the other hand, respondents indicated that the project managers role in team motivation is greatest at the start of a project, and becomes a shared responsibility (between the manager and team) as the project progresses. This, to me, seems a bit strange : if motivation is known to decline as the project progresses, shouldn’t the project manager take even more responsibility for maintaining it in later stages of the project??
According to me, the authors do not answer the question they pose – i.e. they don’t tell us whether or not different motivation techniques should be used at different stages of the project.
In closing
I found the literature review presented in the paper very informative. The authors have done a great job of presenting interesting and relevant work on motivation from the project manager’s perspective. The research, however, has an incomplete feel to it. The authors admit so themselves. In their own words, “The results of this study merely highlight trends in current opinions and should not be interpreted in other ways.” And in the final line, ” The trends expressed in this research should be followed up with case studies or ethnographic analyses to create a more thorough picture of the project manager’s perspective.”
In summary: the authors’ research is far from a comprehensive investigation of project managers’ perception of motivation, but it does point to certain trends that make intuitive sense. The results may also help in the design of further studies. Be that as it may, in my opinion the literature review is what makes the paper a worthwhile read for professional project managers.
References:
Schmid, Bernhard., & Adams, Jonathan., Motivation in Project Management: The Project Manager’s Perspective, Project Management Journal, 39 (2), 60-71. (2008).
Eight to Late 