Whose bright idea was scheduling?

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.