I’m in the middle of a two year project to roll out a project management software package in a large construction company. The first year was taken up with requirements gathering, writing specs, putting together a tender, sending the tender out to prospective software vendors, evaluating the responses, signing contracts with the successful vendor and setting the scope for the deployment. The second year is scheduled to be designing and configuring the software for the environment (5 months), prototyping and testing (3 months) followed by a pilot deployment with a controlled group of projects (3 months).
If that all goes well, the software get rolled out to the whole company over the following year. So this is a long, involved project with a list of unknowns so long that quite frankly it’s terrifying and BEFORE THE WHOLE THING STARTED the person who signs the cheques wanted a detailed schedule showing how long it would take to complete the project.
Depending on which side fence you live, the request for an upfront schedule is either common sense or insanity. If you’re on the business side and have to authorise the expenditure (in this case, millions of dollars which was an unprecedented IT expenditure for this company) you want to know what you will be getting and how long it will take to get.
If you’re the sucker who has to deliver the project, setting a schedule seems crazy because there are far too many variables. There are the known unknowns and the unknown unknowns (which is not as crazy as Donald Rumsfeld made it sound – he just articulated it badly.) The known unknowns are the things you don’t know the answer to but at least you know you have to figure out an answer. The unknown unknowns are the landmines that every IT worker knows are waiting for them on pretty much every project. You don’t even know they’re there but one day you step on one and you blow everything to hell.
The one saving grace of this project is that the software is not being developed in-house. An off the shelf piece of software is being configured to work according to the company’s requirements. And it has to integrate with the existing core business applications. Oh, and we have to find a way to standardise the processes followed in a variety of inconsistent ways by the hundreds of employees in order to design the software configuration and deploy it successfully.
So a schedule for a project with so many variables is essentially a wild guess followed in blind faith, all the while wishing on a star, hoping that none of the thousand possible unforseen problems derail everything. Why does anyone thing this is a good idea?
Well, there’s this little thing the business world like to call reality. You can call it political reality (you fall out of favour if you can’t deliver to schedule), fiscal reality (businesses want to be able to quantify the return on their expenditure – ahead of time preferably) or comparative reality (a process line worker makes x widgets per day so why can’t I measure how much development gets completed in a day?) Very few companies can liberate themselves from this view of reality (Google seems to be an exception if you believe what you read.)
So very few businesses will let you start a project without a schedule. As wrong as it may be, it’s pretty important to accept it as our lot in life as IT workers. Here’s a little tip: if you don’t feel like accepting it as your lot in life, argue your case from the point of view of how the business will benefit from changing their views, not why it would be better for you. Don’t waste time saying “that isn’t how IT development works” – unless you argue the case from a cost/benefit perspective (again, benefits for the business, not you) you’ll most likely come across as spoiled and/or totally disconnected from business “realities”. There’s a disturbing tendency for IT workers to be seen as spoiled and overpaid already so try not to make it worse.
A business can use a project schedule in one of two main ways: as a weapon with which to beat the project team if they fail to deliver to schedule or as a general roadmap. To those who treat divergence from a schedule as a failure which must be punished: you’re going to get the team, the morale and the results you deserve (hint – they’ll all be crap). But if you acknowledge that your schedule is a best guess at where the key signposts are, that you’ll have to stop and ask for directions regularly and that you’ll find the journey taking you in strange and unexpected directions before you reach your destination, then you stand a chance of success.
In my current role I’m lucky enough to be working in a business that treats the schedule as a rough guide rather than holy scripture. Twice, the management committee has actually responded to a progress report by saying “you’re trying to do too much in this time period, give yourself the extra time you need to make sure you’re doing it properly.” When we report project delays they listen to our reasons and support the judgement calls we make. They will kick our butts if the budget blows out much more but with each change we give two alternatives: more time or reduced scope.
I get the feeling our work is actually valued by management. If I sound a little surprised by this it’s because I’ve worked in a number of jobs over the years where the attitude of management to IT was more like “barely tolerated”. Assuming my work is actually valued (and assuming management are wise to place said value in me) this is actually a very smart business decision. It all goes back to the type of cost/benefit analysis I was mentioning earlier in this post.
I get frequent calls from employment agencies hoping I’m looking for work. There is more contract work available than there are experience contractors to fill the roles at the moment. They have quoted me figures more than 1/3 higher than my current rate. So I could easily earn more but I would be taking a risk – the work might not be as interesting and the environment might not be as good. That’s my cost/benefit analysis.
For management, the cost/benefit analysis goes like this: allowing the project to run beyond initial schedule estimates is an increased cost. But if I left (not just me of course), there would be a number of unpleasant costs. First, the project knowledge I have gained would walk out the door with me – there would be a significant time lag before any replacement gained a similar level of knowledge. Second, in the current tight job market it would take quite a while to find a replacement. Third, any replacement would either cost a lot more than me or have considerably less experience (maybe both).
So we’re forced to have a schedule. But there’s a reasonable attitude to changes in that schedule. Everyone seems sufficiently comfortable with the level of doublethink required to balance the contradictory notions of (a) we are following a schedule, and (b) that schedule could be rendered meaningless at any moment. It isn’t perfect but it feels like the lesser of two evils.
12 responses to “Whose bright idea was scheduling?”
Have you read “Waltzing with Bears” by Lister & DeMarco? If not then get hold of a copy – it’ll not take you more than a day or a weekend to read it.
It’s about risk on software projects, but a lot of it is about how to do schedules given that there will always be risks. Basically they suggest you do a schedule based on your absolute best case – you think of everything you need to do when you put the schedule together and nothing goes wrong during development (none of the risks become issues). This then gives you a delivery date (N-day) when the chance of success is of the order of 0.000 000 001 – before this date the chance of delivery is zero.
Then you take your risks and profile them (the chance of this risk happening is x, the resulting cost/schedule slip is y, so we can expect an x * y chance that the schedule will slip). By combining the results of all the risks, you end up with a graph showing how the likelihood of shipping changes from N-day. You can then go to management and say “our analysis shows we will deliver sometime between N-day and N-day plus 25 months, with a 75% chance we’ll be done by N-day plus 17 months”.
They even give you access to a tool which uses Monte Carlo analysis to produce the overall schedule risk profile from the risks you identify, so you can actually go to management and say “we simulated running this project 500 times, and the most likely ship date is N+17 with a 100% chance of being done by N+25”. That “we simulated running this project” helps convince management that you really do have some good numbers and it’s not just a wet-finger-in-the-air guess 😉
>”Then you take your risks and profile them”
This covers the known unknown’s; but they probably weren’t really the greatest threat to begin with. The unknown unknowns are the killers.
>”…the chance of this risk happening is x…”
Suppose one of the known risks is that you’ll have to learn how to ride a unicycle. Sure other people have learned how to ride a unicycle, and can probably tell you how long it took them. The problem is you wont know how long it’s going to take until your done let alone pulling some risk multiplier out of your butt.
Suppose one of the other known risks is that you’ll have to find a cure for the AIDS. Yeah like, you’re really going to be able to even ballpark how long that’s going to take.
I’m with the author though, management needs to be shown a better way that makes sense from their perspective.
I like the first part, start with a realistic best case, and understand your probability of finishing first is close to zero (although it could happen – sometimes unknown unknowns work in your favor, and there is no way to predict the fastest a programmer can program).
I don’t like the second part. By the time you are done running Monte Carlo, you could have been done with the project.
Rob: I like the sound of that approach, although I doubt I’d ever feel confident making any 100% assertions. Some very big projects run by very smart people have failed utterly to deliver anything at all in the past.
Crashcodes: you’ve highlighted some of the very things that would stop me from ever being 100% sure of delivery
Brad: I’m not familiar with Monte Carlo so i don’t know how much hassle it is.
Pingback: Top Posts « WordPress.com
Your entry entertained me. You were successful in making the complicated simple…and the simple complicated…
I see how important scheduling is. Funny thing is that we don’t really know when something comes. Life is mystery.
CrashCodes: If I was working on a project that required riding unicycles, I’d look at hiring someone who already knew how (risk then becomes: “chance of not finding/hiring someone”, which is probably easier to quantify after an hour with the yellow pages and a phone). Or do some feasibility first – if I can’t manage to stay upright on the thing for, say, 10 seconds by the end of the first day of trying, then estimate that the project has 0% chance of success and should be canned (or given to someone with more core stability than me, and there are many!)
Likewise, as a software engineer it’s beyond my field of expertise to say how long until there’s a cure for AIDS, but asking a virologist might give you a better idea, certainly some reasonable chance of estimating the likelihood of having a cure by such-and-such a date.
Thankfully, most projects I’m involved with only require my team and I to apply skills and techniques we either already have or that are similar to things we already know how to do, and getting a risk profile for things like, for example, “time taken to learn Python” or “delays introduced by the database team screwing up the upgrade” would be a lot easier than the examples you give.
I will agree totally that the “unknown unknowns” (thanks, Don) will be the ones that kill you. That’s why you have to keep searching for new risks – risk discovery doesn’t just happen at the start of the project (although even then would be an improvement for my current team), it’s an ongoing process, and your risk profile may need to be changed as you go along.
The most important thing to realise, though, is that N-day is NOT (or, at least, very unlikely to be) the day the project will be complete. Unfortunately most project managers work on the basis that all will go well and there’ll be no extra work, so the customer is told “N-day is the day we ship.”, only to be told later that the project is slipping like crazy.
Brad Bellomo: I’m not sure why you think running a Monte Carlo simulation 500 times would take such a long time (i.e. as long as the project), given you’ve already got the tool to do it and you just need to enter the data. Unless, of course, you mean the time taken to collect and enter that data in the first place, but that’s just a re-statement of the original problem (identifying and profiling risks) which is not dependent on the simulation method (or, even, whether you simulate or not).
Mr Angry: In a Monte Carlo simulation you basically run the project many times in simulation, but with events occuring (or not) each time through based on their assigned probability (see http://en.wikipedia.org/wiki/Monte_carlo_method)
Would you really never be happy making 100% assertions? How about “I can change the background colour of my blog to light green by the end of next year”. That’s 100% do-able, surely? So what about by the end of next month? Next week? Today? In the next 30 seconds? At some point you can give a reasonable “guestimate” that the chance you’ll have something completed falls to just under that 100% – that’s the other end of your risk profile curve (the one that starts with 0.000 000 001 chance at N-day)
[Great blog, BTW]
Jef: Truly one of life’s mysteries
Rob: I’m not lucky enough to get project that simple. Although I didn’t spell it out, my points were about major projects with a whole range of unknowns. If you’re able to break a project down into small, discrete steps you’re usually able to give accurate estimates. One step at a time.
“I’m in the middle of a two year project to roll out a project management software package in a large construction company”
Oh yuck. Now I know why you’re so angry.
Mr. Angry: I enjoyed your post very much and blogged about it here: http://www.talentontarget.com/talent_on_target/2007/08/scheduling-and-.html.
In my post, I list steps that I have found effective for creating and using project plans. And I agree that scheduling a project, or project tasks, to death, or using the schedule as a weapon, is counterproductive.
I think that even the Monte Carlo approach is overkill–you don’t know how something is going to happen until it happens, especially when people are performing service work. I would rather see PMs put their efforts into managing people with professionalism and grace, and managing risks with their best soft skills, than learning how to run probability analyses to estimate completion dates within a certain margin of error. I know there are mangers who love to see these numbers–so crunch them if you have to–but I think the effort decreases your final ROI.
Rudolph: thanks for the contribution!
Pingback: Scheduling and Project Workforce Management: Management By Reality « TalentOnTarget