A Business Analysts View Project Sponsorship / Impossible Deadlines

Posted by Kevin Brady on Fri 27th October 2006 at 09:00 AM, Filed in Project Management

Project Sponsors ask yourself this question – ‘would you rather identify that a project cannot be delivered within the timescales you would like before you have spent £thousands of your budget, or after you have spent all your organisation’s cash and just a month before expected delivery?  Bit of a no-brainer eh?


Then why oh why do we in IT repeatedly find ourselves having to work towards what we know is an unachievable deadline and certain project failure? 

Admittedly, there is (too) frequently an issue with incompetent IT project managers who lack either the motivation or skills to plan to the necessary level of detail, and identify whether the thing is feasible.  It is much easier to be a ‘yes man’ and make the plan fit the desired timescales.  Typically poor Project Managers also do not like to raise too many risks and issues as they can be perceived as being negative (instead of realistic). 

However, Sponsors aren’t helping themselves when they confuse being tough in an effort to squeeze the most out of their IT staff, with not wanting to hear reality when something is absolutely not feasible.  Too often I have heard edicts from Sponsors that it “just has to be done” and failure is “not an option”, Oh, and by the way the delivery date is three months away.  Yes, it’s a fine line to walk between not letting someone pull the wool over your eyes and putting them in a no-win situation. For a real word example of this kind of attitude please refer to Get Sacking - The Path to Project Success 

So what can you do?  One of the key things a Sponsor can do is to foster a culture of open-ness and transparency.  Actively encourage issues to be brought to the table, ask to see risk and issue logs and be suspicious / ask questions if there is much on them.  Risks and issues are NOT bad things – they are key tools to get delivery of your project.  Make sure you really understand the risks and issues, that they get properly assigned and monitored on a regular basis.

Next planning.  Find out if the project plan has been ‘bottom-up’ planned – which means that estimates have been given by the technicians / developers themselves, or at the very least verified by them.  NOT forced upon them.  If you have scared the ‘be-Jesus’ out of the project manager he is hardly likely to admit to you that he /she has bullied his /her team into agreeing to the impossible, because they have done it to try to keep you happy! You may need to try to find out whether the plans are bottom-up by the back door / subtle networking. If the project manager doesn’t seem to know what bottom-up planning is, or states it isn’t necessary, be concerned. 
Look at the detailed project plan at least once, not just the high level milestones.  I know you are unlikely to be a planning expert yourself and may not understand all of the plan, but you do need to satisfy yourself that the milestones are based on some degree of reality.  There are a few basic things to look for that can give you some clues –

Ask to see a Gantt Chart. If the project manager can’t show you one worry.

Does the Gantt Chart identify individual named resources against tasks?  You might have to ‘drill down’ in the Gantt Chart to see this, but if it isn’t there be concerned.

Has any resource levelling been done?  If not, resources on the project may show as being ridiculously over-committed & assigned to 12-hour days.  The project is on to a loser from the start!

Does the Gantt Chart show any holidays, bank holidays, contingency (for sickness etc )

Do tasks on the Gantt Chart show dependencies (i.e. are they linked-up to each other?) and is there a critical path identified?  Again, if not worry.

If you only look in detail at one part of the plan make it the critical path.  Get a bit familiar with it and make sure that milestones on the critical path are milestones that will be reported against.

In my experience IT staff seldom over-engineer plans or make a ‘meal of it’.  Too often it is the opposite.  IT people are usually keen to prove themselves and indulge in optimistic planning.  Seldom has too much time been allocated by IT staff, so really, don’t try to prune it – you will only be hurting yourself.

Project Sponsors; do not take on a sponsorship role for the ‘glory’ without giving it   the proper commitment.  If you do take on the role I beseech you, please don’t be an “Ostrich” when it comes to risks and issues, and don’t make your project managers too scared to talk to you about reality if you genuinely seek timely delivery. 

Finally, don’t take on a sponsorship role if delivery of the project doesn’t directly impact you (you just won’t care enough) and if you don’t have the right level of influence to ensure users are as involved as much as necessary.

This entry has been viewed 2800 times.


No comments yet.


Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.


Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

20 + 2 =