Eight to Late

History repeats itself;  first as tragedy, then as farce - Karl Marx.

Although Mr. Marx didn’t say anything about repetitions beyond the second, one can safely assume he would have considered them beyond farcical. Yet, in the world of corporate IT, we’re continually faced with the following repeat offender:  the solution in search of a problem (or SSP).  I should define the term before I go on - a SSP is a project that has been sanctioned without any regard to  the actual value or utility of the deliverables. This post is aimed at assisting project managers in identifying a SSP, so that they can take appropriate action when confronted with one. This basically amounts to of the following: sidestep it (i.e. duck it somehow), step down (i.e. resign) or suffer (i.e. accept the responsibility of managing the project and, well, suffer).

So, here we go then, seven deadly signs of SSPs:

1. No one knows what the project is about. Everyone talks about it, but no one seems to know why it is being done.
2. It’s all about technology or standards (SOA anyone?), not the business. The justifications on offer for the project are seasoned with phrases like “best practice” or “state of the art technology”; terms that  have more to do with technology than business need.
3. There’s a committee responsible for implementation (often with a global reach). You’ve got to love global committees with their 10,000 metre view of ground level realities. Most recommendations that emerge from these are either so general as to be unusable,  or worse -  patently incorrect. 
4. Since no one knows what it’s about, the project is more about the means than the end. Put another way, project management processes or process improvement methodologies in their full bureaucratic glory will reign supreme. Be sure that you’ve filled in all the right forms and have all the right signatures, else all hell will break loose.  
5. No one is aware of a successful implementation: The global committee has little to show for their three years of the project, barring the pilot they did two years and nine months ago,  involving 1.5  users. 
6. The project will replace a perfectly good existing solution: You have a good system in place? Don’t worry, the SSP will replace your tried and tested solution with  one that will give your staff many  hours of debugging fun, and the gray hairs to prove it. 
7. And finally: these projects often originate in the upper reaches of the corporate hierarchy, where the connection with  ground level reality is somewhat tenuous. Corporate mandated projects have a fair chance of being SSPs.

So, it isn’t hard to spot an SSP. What do you do if confronted with one? Well, that’s up to you. As mentioned earlier, you have three options: sidestep, step down or suffer. The choice is yours.

Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified.   There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.

My motivation for writing this post is a recent conversation I had with a colleague. It went like this:

“Do you think a PM certification is worth the effort?” 

“Depends on what you want out of it,” I replied.

“Well I reckon it will make me a better project manager and help me stand out from the crowd .”

Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:

1. To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes  as decreed by  a particular certifying authority. These processes are easy to learn  by reading a book or two. The “hard bits” of project management - negotiation, people skills, crisis management, conflict resolution, prioritisation, stakeholder management (I could go on and on but I’m sure you get my point) - are not, and cannot be, learnt through certification.
2. To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day. 

Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology.  The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognise jargon-laden bulldust when I hear it (which, unfortunately, is  quite often). 

In the end, formal knowledge is always useful. So, gaining a cert won’t hurt,  but be sure you aren’t doing it for the wrong reasons.

A manager’s response to A corporate IT tragedy in five limericks:

I see you have taken offence.
But axing your job made good sense.
You had to go
to save us some dough,
and that’s why you are in past tense.

It broke our hearts to do it,
but it’s because of the market.
Our bottom line
has to climb
a long way to make us a profit.

Let me say this just between us:
For savings, on me was the onus.
And it’s better to see
you gone, than me.
It may even earn me a bonus.

I know you will soon secure
another big fat sinecure.
Where you’ll do no work,
and continue to shirk,
while gaining promotions galore.

And so I bid you adieu;
and many good wishes to you.
See, writing bad verse
may feel good at first,
but later you may just get sued.

They tell me my job’s on the line
I think it’s for real this time.
The bosses, they say,
“Your job’s going away,
it’s heading for sunnier climes.”

This time it’s gone really far.
I reckon they’ve been reading Carr.
Who tells us that IT,
is just a utility.
Strategic it isn’t, for sure.

Consequences of centralization -
servers in another nation.
Miles away from here.
Too far, I fear;
QoS goes to hell - “Oh damnation!”

Every little bit and byte
traverses a long and thin pipe.
All the way to our users
who’ve become snoozers,
waiting for docs from last night.

I know the circle will turn.
But not before users get burned,
by rotten support.
They’ll see it’s a rort,
then bring the whole darn thing back home.

If you enjoyed this piece, you may like to read my project management tragedy in five limericks. Feedback is welcomed via your comments.

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 and make it to work very late.

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)