Archive for the ‘Project Management’ Category
Why I didn’t do some of the things I had to do…
Why do people postpone important tasks? Research by Sean McCrea and his colleagues may provide a partial answer. Theyfound that people tend to procrastinate when asked to perform tasks that are defined in abstract terms. What this means is best explained through one of their experiments: half of a group of students were asked to describe how they would carry out a mundane task such as opening a bank account, and the other half were asked to describe reasons why one might do that task – i.e. why one might want to open a bank account. The first task is straightforward, and needs little thought prior to execution. The second one is more abstract; some deliberation is required before doing it. Even though all participants were offered a small (but interesting enough) sum of money if they completed the task within three weeks, it was found that most of those who were given the concrete task completed it on time whereas more than half those assigned the abstract task failed to complete it. The researchers use the concept of psychological distance to describe this behaviour. Psychological distance in this context is a measure of the closeness (or remoteness) a person feels to a task, abstract tasks being more “distant” in this sense than concrete ones.
Reading about this reminded me of an incident that occurred many years ago, just after I’d made a career switch from academic research to business consulting. One of the partners in the firm I was working for had asked me to write a project proposal for a new client. He assumed I knew what was needed, and offered no guidance. I had a half-hearted try at it, but couldn’t make much headway. Like the stereotypical student, I then put it off for several days. The day before the deadline, fearing the consequences of inaction, I got down to it. I spoke to a few colleagues to make the task clearer, spent some thinking it through then, finally, wrote (and rewrote) the proposal well into the night.
Seen in the light of Dr. McCrea’s research, my procrastination was simply a normal human reaction to an abstract task. Once I was able to define the task better – with the help of my colleagues and some thought – my reasons for procrastination vanished, and with it my mental block.
I see this operate in my current job too. I work with a small group of developers who tackle a wide range of projects ranging from enterprisey stuff (such as the implementation of CRM systems), to the development of niche applications used by a handful of people. The small size of our group means that everyone has to do a bit of everything – design, coding, testing, maintenance, support and (unfortunately) … documentation. Now, in keeping with the stereotypical developer, most of the mob detest doing documentation. “I’d rather do maintenance coding,” said one. When asked why, he replied that it took him a lot more effort to write than it did to do design or coding work. Of course, this is not to say that cutting coding is easy, but that developers (or the ones I work with, at any rate) find it less remote psychologically – and hence easier – than writing. So, when required to do documentation, they typically put it off if as much as possible.
The relationship between task abstraction and procrastination indicates how managers can help reduce the tendency to procrastinate. The basic idea is to reduce task abstraction, and hence reduce the psychological remoteness an assignee feels in relation to a task. For example, when asking a coder to write documentation, it might help to provide a template with headings and sub-headings, or make suggestions on what should and should not be included in the documentation. Anything that makes the task less abstract will help counter procrastination.
Tasks can be made more concrete in a number of ways. Some suggestions:
- Outline steps required to perform the task.
- Providing more detail about the task.
- Narrow the task down to specifics.
- Provide examples or templates of how the task might be done.
Of course, not all procrastination can be attributed to task abstraction. Folks put off tasks for all kinds of reasons – and sometimes even for no reason at all. However, speaking from personal experience, Dr. McCrea’s work does ring true: I didn’t do some of the things I had to do simply because they weren’t clear enough to me – like that project plan I was supposed to have started on a week ago. But advice is easier given than taken. With only a gentle pang of guilt, I put it off until tomorrow.
Anchored and over-optimistic: why quick and dirty estimates are almost always incorrect
Some time ago, a sales manager barged into my office. “I’m sorry for the short notice,” she said, “but you’ll need to make some modifications to the consolidated sales report by tomorrow evening.”
I could see she was stressed and I wanted to help, but there was an obvious question that needed to be asked. “What do you need done? I’ll have to get some details before I can tell you if it can be done within the time,” I replied.
She pulled up a chair and proceeded to explain what was needed. Within a minute or two I knew there was no way I could get it finished by the next day. I told her so.
“Oh no…this is really important. How long will it take?”
I thought about it for a minute or so. “OK how about I try to get it to you by day after?”
“Tomorrow would be better, but I can wait till day after.” She didn’t look very happy about it though. “Thanks,” she said and rushed away, not giving me a chance to reconsider my off-the-cuff estimate.
—
After she left, I had a closer look at what needed to be done. Soon I realised it would take me at least twice as long if I wanted to do it right. As it was, I’d have to work late to get it done in the agreed time, and may even have to cut a corner or two ( or three) in the process.
So why was I so wide off the mark?
I had been railroaded into giving the manager an unrealistic estimate without even realising it. When the manager quoted her timeline, my subconscious latched on to it as an initial value for my estimate. Although I revised the initial estimate upwards, I was “pressured” – albeit unknowingly – into quoting an estimate that was biased towards the timeline she’d mentioned. I was a victim of what psychologists call anchoring bias – a human tendency to base judgements on a single piece of information or data, ignoring all other relevant factors. In arriving at my estimate, I had focused on one piece of data (her timeline) to the exclusion of all other potentially significant information (the complexity of the task, other things on my plate etc.).
Anchoring bias was first described by Amos Tversky and Daniel Kahnemann in their pioneering paper entitled, Judgement under Uncertainty: Heuristics and Biases. Tversky and Kahnemann found that people often make quick judgements based on initial (or anchor) values that are suggested to them. As the incident above illustrates, the anchor value (the manager’s timeline) may have nothing to do with the point in question (how long it would actually take me to do the work). To be sure, folks generally adjust the anchor values based on other information. These adjustments, however, are generally inadequate. The final estimates arrived at are incorrect because they remain biased towards the initial value. As Tversky and Kahnemann state in their paper:
In many situations, people make estimates by starting from an initial value that is adjusted to yield the final answer. The initial value, or starting point, may be suggested by the formulation of the problem, or it may be the result of a partial computation. In either case, adjustments are typically insufficient. That is, different starting points yield different estimates, which are biased toward the initial values. We call this phenomenon anchoring.
Although the above quote may sound somewhat academic, be assured that anchoring is very real. It affects even day-to-day decisions that people make. For example, in this paper Neil Stewart presents evidence that credit card holders repay their debt more slowly when their statements suggest a minimum payment. In other words the minimum payment works as an anchor, causing the card holder to pay a smaller amount than they would have been prepared to (in the absence of an anchor).
Anchoring, however, is only part of the story. Things get much worse for complex tasks because another bias comes into play. Tversky and Kahnemann found that subjects tended to be over optimistic when asked to make predictions regarding complex matters. Again, quoting from their paper:
Biases in the evaluation of compound events are particularly significant in the context of planning. The successful completion of an undertaking, such as the development of a new product, typically has a conjunctive character: for the undertaking to succeed, each of a series of events must occur. Even when each of these events is very likely, the overall probability of success can be quite low if the number of events is large. The general tendency to overestimate the probability of conjunctive events leads to unwarranted optimism in the evaluation of the likelihood that a plan will succeed or that a project will be completed on time.
Such over-optimism in the face of complex tasks is sometimes referred to as the planning fallacy.1
Of course, as discussed by Kahnemann and Fredrick in this paper, biases such as anchoring and the planning fallacy can be avoided by a careful, reflective approach to estimation – as opposed to a “quick and dirty” or intuitive one. Basically, a reflective approach seeks to eliminate bias by reducing the effect of individual judgements. This is why project management texts advise us (among other things) to:
- Base estimates on historical data for similar tasks. This is the basis of reference class forecasting which I have written about in an earlier post.
- Draft independent experts to do the estimation.
- Use multipoint estimates (best and worst case scenarios)
In big-bang approaches to project management, one has to make a conscious effort to eliminate bias because there are fewer chances to get it right. On the other hand, iterative / incremental methodologies have bias elimination built-in because one starts with initial estimates, which include inaccuracies due to bias, and subsequently refine these as one progresses. The estimates get better as one goes along because every refinement is based on an improved knowledge of the task.
Anchoring and the planning fallacy are examples cognitive biases – patterns of deviations of judgement that humans display in a variety of situations. Since the pioneering work of Tversky and Kahnemann, these biases have been widely studied by psychologists. It is important to note that these biases come into play whenever quick and dirty judgements are involved. They occur even when subjects are motivated to make accurate judgements. As Tversky and Kahnemann state towards the end of their paper:
These biases are not attributable to motivational effects such as wishful thinking or the distortion of judgments by payoffs and penalties. Indeed, several of the severe errors of judgment reported earlier (in the paper) occurred despite the fact that subjects were encouraged to be accurate and were rewarded for the correct answers.
The only way to avoid cognitive biases in estimating is to proceed with care and consideration. Yes, that’s a time consuming, effort-laden process, but that’s the price one pays for doing it right. To paraphrase Euclid, there is no royal road to estimation.
1 The planning fallacy is related to optimism bias which I have discussed in my post on reference class forecasting.
The role of the project sponsor
The role of the project sponsor has not been given much attention in project management literature and lore. This is strange because most project managers will attest to the importance of having an effective project sponsor. So here’s a question: what differentiates an effective sponsor from an ineffective one? Well, obviously involvement in the project is important – an indifferent sponsor won’t be much help at all. But what kind of involvement is required? A recent paper entitled Governance and Support in the Sponsoring of Projects and Programs, by Lynn Crawford and others, explores the formal and informal aspects of the sponsorship role, with a view to defining what makes an effective sponsor. This post is an annotated summary of the paper.
In their introduction, the authors state that, “convincing evidence demonstrates that success or failure of projects is not entirely within the control of the project manager and project team. Contextual issues are crucial in influencing the progress and outcomes of a project, and a key theme that has emerged is the support of top management.” In addition to this, the authors recognise the increasing focus on corporate governance adds another dimension to the role of the sponsor – that of ensuring that the project is aligned with corporate policies and, more generally, any relevant regulatory requirements.
The paper aims to provide a comprehensive view of project sponsorship by looking at the role from the perspective of sponsors, project managers, team members and other project stakeholders. The conclusions were based on interviews with assorted stakeholders selected from 36 projects across different geographical regions. The diversity of data enabled the authors to construct a conceptual model of the sponsor role. As hinted at in the previous paragraph, the model views the role as consisting of two independent perspectives: that of the organisation (governance) and that of the project (support).
Background
In true academic fashion, the authors present a comprehensive review of the literature on project sponsorship. Broadly, the literature may be divided into two areas: standards and research papers. The authors find that project management standards provide sparse material on the role of the sponsor. Specifically, the PMBOK views the sponsor in the context of a single project – and mainly in the role of a financier. The standard makes no reference to the wider organisational context in which the project plays out. Other standards such as the OPM and Program / Portfolio Management Standards provide a limited discussion of the sponsor as project champion, but these too, completely overlook the organisational context of the role. Other standards such as those from the APM and OGC have a more rounded view of the role.
In recent years the project sponsor role has been getting increased attention from project and general management researchers, as evidenced by the increasing number of papers published on the topic. In the author’s words, “Initial understanding of the role of the project executive sponsor as the person or group responsible for approving finance has gradually been expanded to include many other key functions that appear to be directly related to project success.” Some of these include:
- Ensuring availability of resources.
- Achieving and maintaining buy-in of senior management.
- Getting political support for the project.
- Serving as a “project critic”.
The literature also identifies the following characteristics of successful project sponsors:
- Appropriate seniority and power in the organisation.
- Political skill.
- Connections and influence in the organisation.
- Ability to motivate
- Excellent communication skills
- Ability to work with people at different levels in the organisation and the project team.
Yet, despite the importance of the role, many organisations do not nominate sponsors for all their projects. From their literature review, the authors conclude that although there is an increasing recognition of the importance of the sponsorship role, it remains largely unexplored. Their paper is intended to be a step towards filling this gap.
Methodology
The authors conducted their research in two phases. In the first phase, they performed five independent studies aimed at identifying:
- Attributes contributing to effective sponsorship
- The influence of sponsorship on project success
- Competencies required of project sponsors
- The sponsorship role in the context of organisational, program and project governance
- A model of factors contributing to the effective performance of the sponsorship role
The researchers were able to identify common themes that emerged from all of the independent studies. This commonality enabled the researchers to build a conceptual model of the sponsorship role, which was then tested against data gathered in the second phase of the research. The details of the research methodology, as fascinating as they may be for professional researchers, are of little interest to the practising project manager. So, I’ll leave it there, and move on to a discussion of the model.
The Model
The project sponsor role straddles two organisational entities: the project and the sponsoring organisation. From the perspective of the project, the main function of the sponsor is to provide support (e.g. champion the project); from the organisational perspective it is to ensure appropriate governance (e.g. compliance with regulations and corporate policy). The authors therefore model the role along two complementary, yet independent, dimensions – support and governance. The dimensions complement each other in that “the act of governing the project requires that the project be looked at from the perspective of the parent organisation (governance), and the act of providing top management support requires looking at the parent organisation from the perspective of the project (support).” Although complementary, one can conceive of situations where one might exist without another – think of an overly regulated organisation, for example – so they are independent as well.
To a large extent, which dimension is emphasised depends on the situation – and a canny sponsor recognises what a particular situation demands. For example, a sponsor may need to emphasise governance if a project has regulatory implications. On the other hand, she may need to emphasise support if some aspects of the parent organisation are impeding project progress. In principle, one can describe all possible sponsor perspectives in a two dimensional plane described by the coordinates (governance, support): the former describing the interests of the parent organisation and the latter the interests of the project. The paper does not describe the framework any further, although the authors do mention that future papers will fill in more detail.
The authors then present a long discussion of the two perspectives, discussing specific situations in which they may be appropriate. In essence, from a governance perspective the sponsor needs to ensure that the interests of the parent organisation are served by the project, whereas from a support perspective he or she needs to champion the project within the larger organisation. Specific examples of each are easy to find, and are left as an exercise for the reader.
It is interesting that the model presented is akin to some existing theories of management and leadership. A well-known example is the managerial grid model proposed by Blake and Mouton in 1964. In the grid model, the two dimensions are (the welfare of) People and (the maximisation of) Production, and an effective leader displays concern for both. Recent research, however, provides only limited support for the hypothesis that high-people and high-production leaders are more effective than others. In fact, Yukl suggests that people-related factors such as interpersonal relationships and teamwork are more important. A good leader should be able to “guide and facilitate” by fostering relationships and teamwork within the organisation. The congruence between the grid model (and others of its ilk) and the present sponsor model is false, and managerial effectiveness should be seen as a third dimension (in addition to Support and Governance).
So what are the attributes of a good “guide and facilitator” as it pertains to project sponsorship? The authors identify the following from their data:
- Good communication skills.
- Commitment to the project.
- Position and influence in the parent organisation.
- Is available when needed
In terms of practical help, the most important of these attributes is availability. In the words of one of the survey respondents, “The sponsor must be accessible. It doesn’t help if you have a sponsor who kind of reports to God and you never get to see them…” I’m sure many project managers will be able to relate to this.
Conclusion
The paper presents a conceptual model of the project sponsorship role, based on an analysis of existing project and general management literature, and data gathered from diverse project environments. The model views the role as being made up of two independent functions: support and governance. These functions represent the perspective of the temporary organisation (the project) and the permanent one (the parent organisation) respectively. It is also interesting that the two functions can, at times (or should I say, often?), lead to conflicting demands on a sponsor. The authors end the paper stating that analysis of data and work on the model continue. I look forward to seeing a further elaboration of their model in the future.
To end, a few quick words about relevance of the paper to practising project managers. From the practitioner’s perspective, the paper is worth a read because it spells out the full range of responsibilities of a project sponsor in very clear terms. In short, after reading this paper you’ll know what to say when a sponsor of your project wanders over and asks, “What do you need from me?”
References:
Crawford, Lynn., Cooke-Davis, Terry., Hobbs, Brian., Labuschagne, Les., Remington, Kaye., Chen, Ping., Governance and Support in the Sponsoring of Projects and Programs, Project Management Journal, 39 (S1), 43-55. (2008).
Eight to Late 