Archive for the ‘Project Management’ Category
On the inherent uncertainty of project tasks estimates
The accuracy of a project schedule depends on the accuracy of the individual activity (or task) duration estimates that go into it. Project managers know this from (often bitter) experience. Treatises such as the gospel according to PMBOK recognise this, and exhort project managers to estimate uncertainties and include them when reporting activity durations. However, the same books have little to say on how these uncertainties should be integrated into the project schedule in a meaningful way. Sure, well-established techniques such as PERT do incorporate probabilities into schedules via averaged or expected durations. But the resulting schedules are always treated as deterministic, with each task (and hence, the project) having a definite completion date. Schedules rarely, if ever, make explicit allowance for uncertainties.
In this post I look into the nature of uncertainty in project tasks – in particular I focus on the probability distribution of task durations. My approach is intuitive and somewhat naive. Having said that up front, I trust purists and pedants will bear with my somewhat loose use of terminology relating to probability theory.
Theory is good for theorists; practitioners prefer examples, so I’ll start with one. Consider an activity that you do regularly – such as getting ready in the morning. Since you’ve done it so often, you have a pretty good idea how long it takes on average. Say it takes you an hour on average – from when you get out of bed to when you walk out of your front door. Clearly, on a particular day you could be super-quick and finish in 45 minutes, or even 40 minutes. However, there’s a lower limit to the early finish – you can’t get ready in 0 minutes! Let’s say the lower limit is 30 minutes. On the other hand, there’s really no upper limit. On a bad day you could take a few hours. Or if you slip in the shower and hurt your back, you could take a few days! So, in terms of probabilities, we have a 0% probability at a lower limit and also at infinity (since the probability of taking an infinite time to get to work is essentially zero). In between we’d expect the probability to hit a maximum at a lowish value of time (may be 50 minutes or so). Beyond the maximum, the probability would decay rapidly at first, then slowly becoming zero at an infinite time.
If we were to plot the probability of activity completion for this example as a function of time, it would look like the long-tailed function I’ve depicted in Figure 1 below. The distribution starts at a non-zero cutoff (corresponding to the minimum time for the activity); increases to a maximum (corresponding to the most probable time); and then falls off rapidly at first, then with a long, slowly decaying tail. The mean (or average) of the distribution is located to the right of the maximum because of the long tail. In the example, (30 mins) is the minimum time for completion so the probability of finishing within 30 mins is 0%. There’s a 50% probability of completion within an hour (denoted by
), 80% probability of completion within 2 hours (denoted by
) and a 90% probability of completion in 3 hours (denoted by
). The large values for
and
compared to
are a consequence of the long tail. In the example, the tail – which goes all the way to infinity – accounts for the remote possibility you may slip in the shower, hurt yourself badly, and make it work very late (or may be not at all!).
It turns out that many phenomena can be modeled by this kind of long-tailed distribution. Some of the better known long-tailed distributions include lognormal and power law distributions. A quick, informal review of project management literature revealed that lognormal distributions are more commonly used than power laws to model activity duration uncertainties. This may be because lognormal distributions have a finite mean and variance whereas power law distributions can have infinite values for both (see this presentation by Michael Mitzenmacher, for example). [An Aside:If you’re curious as to why infinities are possible in the latter, it is because power laws decay more slowly than lognormal distributions – i.e they have “fatter” tails, and hence enclose larger (even infinite) areas.]. In any case, regardless of the exact form of the distribution for activity durations, what’s important and non-controversial is the short cutoff, the peak and long, decaying tail. These characteristics are true of all probability distributions that describe activity durations.
There’s one immediate consequence of the long tail: if you want to be really, really sure of completing any activity, you have to add a lot of “air” or safety because there’s a chance that you may “slip in the shower” so to speak. Hence, many activity estimators add large buffers to their estimates. Project managers who suffer the consequences of the resulting inaccurate schedule are thus victims of the tail.
Very few methodologies explicitly acknowledge uncertainty in activity estimates, let alone present ways to deal with it. Those that do include The Critical Chain Method, Monte Carlo Simulation and Evidence Based Scheduling. The Critical Chain technique deals with uncertainty by slashing estimates to their values and consolidating safety or “air” into a single buffer, whereas the latter two techniques use simulations to generate expected durations (at appropriate confidence levels). It would take me way past my self-imposed word limit to discuss these any further, but I urge you to follow the links listed above if you want to find out more.
(Note: Portions of this post are based on my article on the Critical Chain Method)
The effect of organizational culture on project success
It is a truism that two organisations using the same project management practices and structures will have different levels of success with them. Clearly, there’s a lot more to project success than project management. Despite this, most studies of project success tend to focus on project level, or operational, variables such as level of user involvement, use (or not) of a formal methodology, reliability of estimates etc (Note: these variables have been taken from the oft quoted Standish Report). As important as these factors are, they fail to take into account that projects live and evolve in a wider environment which includes the sponsoring organisation. A recent paper entitled, New Product Development Projects: The Effects of Organizational Culture published in the December 2007 issue of the Project Management Journal, studies the effect of organisational culture on project success with specific reference to new product development (NPD) projects. I summarise and review the paper below.
The authors claim that despite the importance of NPD projects for the long term success of an organisation, the effect of strategic level variables (organisational culture, organizational strategy, management involvement etc.) on project success has not been widely studied. They suggest this might be so because these variables are hard to define, quantify and measure. Further, on reviewing the existing literature, they find that the few published, organisation-oriented studies tend to focus on the end result of the development process (i.e. the product) rather than on factors affecting the project. Hence the motivation for their study.
Incidentally, they note that there has been some work on the effect of national culture on NPD project performance, but these studies find no correlation between the two.
To measure something as elusive as organisational culture, you first have to pin it down by defining it. The definition does not have to be all-encompassing, but it needs to be precise enough for people to have a common understanding of what you’re talking about. To do this, the authors created a set of questions based on various definitions of organisational culture available in the literature. The resulting questionnaires were mailed out to various organisations engaged in NPD projects. The responses received (from over a hundred organisations) were analysed using exploratory factor analysis, enabling the authors to group the questions into the following dimensions of organisational culture:
-
Positive work environment: this includes factors such as
-
openness to new ideas,
-
employees feeling valued as individuals,
-
open discussion with superiors encouraged etc.
-
-
Management leadership: this includes factors such as
-
clear goals set and responsibilities delegated,
-
employees have input in decision making,
-
incentives offered to work on new ideas,
-
high-risk high-return projects encouraged etc.
-
-
Results orientation: this includes factors such as
-
employees are pressured to finish work,
-
correct procedures more important than correct results etc.
-
These dimensions define organisational culture for the purposes of their study.
To measure project success, the authors use the following dimensions adapted from Griffin and Page:
-
Consumer-based: the customers are satisfied with the product. This can also be classed as Customer Satisfaction.
-
Commercial success: the product makes money
-
Technical success: the product works as intended.
Note that these variables are actually a subset of those suggested by Griffin and Page.
Project success was measured by getting upper management in the surveyed companies to rate product success along each of the above dimensions.
Finally, the authors correlate organisational culture to product success (for the surveyed companies) using correlation and regression analysis. The results (which are really no surprise) indicate that:
-
Positive work environments and management leadership are strongly correlated with each other and with the three measures of product success. That is:
-
Strong management leadership and positive work environments go hand-in-hand.
-
Companies with positive work environments (and, by implication, strong management leadership) have better commercial success with new products, enjoy better customer satisfaction and have greater technical success than those with less positive work environments (and, by implication, weak leadership).
-
-
Results orientation is not strongly correlated with any of the other variables. If this seems surprising at first sight, take another look at what goes into making up this variable and it will seem less so!
Although the paper focuses on NPD projects, I think the conclusions – especially those pertaining to customer satisfaction and technical success – apply to other projects as well. Further, though the conclusions may be obvious to many, such research is important because it lends analytical backing to otherwise intuitive notions. It does this by:
-
Defining (albeit, in a limited way) what is meant by organisational culture and project success.
-
Studying the relationship between the variables that make up the two.
Defining variables and quantifying relationships can give us a sense for which organisational culture variables are the most significant determinants of project success. So, although the study is a preliminary one (as the authors themselves admit), the work is a useful step in understanding the relationship between projects and the larger environment in which projects live and breathe.
References:
Belassi, W., Kondra, A. Z., and Tukel, O. I., New Product Development Projects: The Effects of Organizational Culture, Project Management Journal, 38 (4), 12-24 (2007).
Portents of project failure
Most project managers have had to deal with a failed project or two. Unfortunately, by the time it is recognised that a project is in trouble, it is often too late to do anything about it. Many project failures, however, are presaged by other, less serious problems. It is useful to keep an eye out for these so that one can take action to prevent subsequent disaster. To use a medical analogy, it is best to to identify sick projects before they become terminally ill. As doctors say : the earlier the diagnosis, the better the prognosis.
So here they are, six symptoms of sick projects (in no particular order):
-
Low team morale: Team members complaining that things are out of control and that they can’t cope is a sure sign of trouble ahead. Solution: get to the root cause of the problem. Figure out why they think “things are out of control” or “they can’t cope”. You need to find the underlying cause for their angst before you can address it.
-
Chronic buck-passing: A typical case of this might be where a team member says, “I coudn’t finish on time because X didn’t give me what he was supposed to last week.” Project roles and responsibilities should be defined in the plan, and I’m assuming that this is the case (if not you have bigger problems!). In a situation where responsibilities are defined, buck-passing is usually a consequence of communication breakdown across a project interface. This has to be handled by smoothing out the obstacles to communication.
-
Sponsor loses interest (or worse, quits!): A sponsor quitting is a situation that a project manager can’t do much about, except be aware it might (will!) impact the project. Loss of interest, on the other hand, could mean that the business no longer considers the project important. Whatever the reason, it is probably best to speak to the sponsor to find out more.
-
Chronic distractions: This is possibly the most common one I’ve come across. It typically happens in corporate environments where team members are temporarily “loaned out” to the project team. The demands of their regular jobs still remain and consequently they’re continually pulled away to do non-project tasks. The way to handle this is to speak to the relevant managers, reminding them of the importance of the project and their original commitment to it. As a last resort, one might need to involve the sponsor. The preferred option, however, is to settle the issue at the level of the manager.
-
No one in-charge: This is really a variant of the previous point, but is important enough to stand on its own. It typically happens when the project manager is a part-timer who has to focus on his or her real job whilst (additionally) looking after the project. Although such an arrangment might work for a small project with limited scope, it will not do for a project of any decent size. It still surprises me how many important projects (such as ERP implementations) are run by part-timers. Although the people involved do their best, part-time attention is rarely enough to stay on top of the complexity of the project.I should also add that this can also happen when a project manager is incompetent!. This, however, is much rarer as such folks tend to get weeded out of the profession before they get to handle a big project.In either case the solution is to get management to understand that (competent!) full time attention is necessary for project success.
-
Lack of familiarity with technology or processes (coupled with the lack of external help): This one is common enough. I’ve seen several frustrated project teams struggle to familiarise themselves with an unfamiliar technology whilst attempting to use it in a project. The time to a learn a new skill is before the project. It’s too late to throw people into training after the project starts; they need to learn and practise the technology well before that. If your team doesn’t have the necessary skills, for heaven’s sake get help from outside. Else you’ll kill morale along with the project.


