• This topic has 48 replies, 44 voices, and was last updated 7 years ago by br.
Viewing 40 posts - 1 through 40 (of 49 total)
  • Project Management – your no. 1 tip?
  • sc-xc
    Full Member

    I have been asked to get a largeish* ICT programme back on track (lots of delays, 11th hour changes in direction etc)

    I relish the challenge, but have made it clear to the gaffers that I am not a programme manager. I think they just want someone to coordinate the individual streams and keep the whole thing moving.

    Years ago I did Prince 2 Practitioner (but never really used it). A quick scan through the book made me think that there will be some real world great tips from experienced PMs….so where better to ask?

    What’s the one practical tip that you would give a totally green programme manager?

    *(£6.5m, maybe 4 or 5 individual PMs on different streams)

    Drac
    Full Member

    Sounds like you’re the scapegoat.

    thestabiliser
    Free Member

    Go on internet, hand over to sucker in 6 months time.

    Fresh Goods Friday 696: The Middling Edition

    Fresh Goods Friday 696: The Middlin...
    Latest Singletrack Videos
    mrmoosehead
    Free Member

    Run away.

    Failing that, properly assess state of projects, and don’t be afraid to say it’s foobared.

    Either way, the future should be entertaining.

    howsyourdad1
    Free Member

    Delegate. You cant do it all!

    Rorschach
    Free Member

    She’s having an affair.

    lunge
    Full Member

    Bit long, but this should cover it:

    Project management – a beautiful thing!

    1.It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women.

    2.Nothing is impossible for the person who doesn’t have to do it.

    3.You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.

    4.At the heart of every large project is a small project trying to get out.

    5.The more desperate the situation the more optimistic the situatee.

    6.A problem shared is a buck passed.

    7.A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.

    8.A user will tell you anything you ask, but nothing more.

    9.Of several possible interpretations of a communication, the least convenient is the correct one.

    10.What you don’t know hurts you

    11.There’s never enough time to do it right first time but there’s always enough time to go back and do it again.

    12.The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.

    13.I know that you believe that you understand what you think I said, but I am not sure you realise that what you heard is not what I meant.

    14.What is not on paper has not been said.

    15.A little risk management saves a lot of fan cleaning.

    16.If you can keep your head while all about you are losing theirs, you haven’t understood the plan.

    17.If at first you don’t succeed, remove all evidence you ever tried.

    18.Feather and down are padding, changes and contingencies will be real events.

    19.There are no good project managers – only lucky ones.

    20.The more you plan the luckier you get.

    21.A project is one small step for the project sponsor, one giant leap for the project manager.

    22.Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.

    23.If everything is going exactly to plan, something somewhere is going massively wrong.

    24.Everyone asks for a strong project manger – when they get them they don’t want them.

    25.Overtime is a figment of the naïve project manager’s imagination.

    26.Quantitative project management is for predicting cost and schedule overruns well in advance.

    27.The sooner you begin coding the later you finish.

    28.Metrics are learned men’s excuses.

    29.For a project manager overruns are as certain as death and taxes.

    30.Some project finish on time in spite of project management best practices.

    31.Fast – cheap – good – you can have any two.

    32.There is such a thing as an unrealistic timescale.

    33.The project would not have been started if the truth had been told about the cost and timescale.

    34.A two-year project will take three years, a three year project will never finish.

    35.When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.

    36.A badly planned project will take three times longer than expected – a well planned project only twice as long as expected.

    37.Warning: dates in a calendar are closer than they appear to be.

    38.Anything that can be changed will be changed until there is no time left to change anything.

    39.There is no such thing as scope creep, only scope gallop.

    40.A project gets a year late one day at a time.

    41.If you’re 6 months late on a milestone due next week but really believe you can make it, you’re a project manager.

    42.No project has ever finished on time, within budget, to requirement

    43.Yours won’t be the first to.

    44.Activity is not achievement.

    45.Managing IT people is like herding cats.

    46.If you don’t know how to do a task, start it, then ten people who know less than you will tell you how to do it.

    47.If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan!

    48.The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

    49.The sooner you get behind schedule, the more time you have to make it up.

    50.The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

    51.Good control reveals problems early – which only means you’ll have longer to worry about them.

    ahwiles
    Free Member

    there will be half a dozen minions who actually know what’s going on, learn who they are, and listen to them.

    just5minutes
    Free Member

    It depends what “back on track” actually means…

    – reduce scope to hit original milestones
    – increase resource to hit original scope but with cost increase
    – reduce testing / quality control with view to fixing faults after release
    – re-prioritise the deliverables of people working on aspects of the project to deliver on time at expense of BAU

    The first thing I’d do in the OPs situation is to start with a conversation with the sponsor and then then play back in writing what I’d heard on any of the above points. After that I’d do a detailed sit-rep and use programme governance to make some decisions.

    So my number 1 tip is start with a good discussion at the top level of accountability for the programme.

    toby1
    Full Member

    Hard to put into a single tip and in the interests of tl;dr 50 point guide above here are the top 3 things for me;

    The higher up the chain you are the less you actually ‘do’ the more you need to talk. to the people doing the work, to the people who have asked for the work, to the people who will support the work.

    Have a daily stand-up with all the people who need to give you updates, listen to them and see what you can do to enable them to do what they need to.

    Open and honest communication is the most important, people need to honestly tell you if they can commit to a delivery, there is no point in you meeting with people who ‘think’ the team they are running will deliver by X date.

    Best of all – good luck!

    sc-xc
    Full Member

    Thanks all

    There are a couple of really good PMs, and the wider organisation (and leadership) are very supportive. Crucially, there is a real appetite amongst the end users for what the programme will deliver.

    Good point about starting with re-clarifying objectives and creating strong governance.

    Any other practical things? I can be pretty organised when needed – but recognise that this will require a lot more focus!

    EDIT – thanks. I think the point about honesty is very important…

    Rickos
    Free Member

    Try and retrospectively do a decisions log if it’s not been done through the project so far. That tells you why certain things are being done the way they are and how the decision was arrived at (background info, who said what, etc.). Then keep it going. Harder than it sounds though.

    That way you can point to who made what decision and why when it comes to the end of the project and it’s all getting reviewed because it went badly and they need someone to point the finger at. Usually called lessons learnt…

    MoreCashThanDash
    Full Member

    From my own experience of being asked to bring a project back in on track, Drac has nailed it.

    There are some proper nuggets buried in lunges post as well.

    bikebouy
    Free Member

    ahwiles – Member
    there will be half a dozen minions who actually know what’s going on, learn who they are, and listen to them.

    This.

    Plus, they will be fairly easy to track down, most folk will either point them out or give pointers like “Fred does this, that and knows the other”
    Then understand that because of their unrivaled position they will be busy, don’t step on their toes when you first walk in because you’ll be knackered and might as well walk away now. Generally they are very helpful if you treat them right and you’ll find they support (mostly) your proposals (if you have any) There will already be political undertoes to the position they hold, bare in mind they’ll have their own opinions on how things should be, don’t ignore but don’t agree either. Don’t sweeten them by gifts or befriending them, invariably they are loners who like it that way.

    Assess stakeholders: what is the Political stance of the project? Forget the £’s for a moment and go find out what the feeling is for getting this thing back on track.. If you have 4-5 stakeholders only 2-3 will support it, the others will think it’s a waste of resource and they’d like the money it’s sucking away.

    Plan: you’ll be asked to produce something quickly and smartly, take a look at the current MI and replicate. Change anything too far from whats been produced recently (format, typeface, setout, deck) and they’ll look at you like you are an Alien and will dismiss anything you have to say form the outset.. Also you need a timeline and key milestones set out sharpish, this links to the point below..

    Painpoints: make a list, prioritise and then grade. Don’t waste time on shit that will stay brown, you need to polish something and quickly. Assess cost and Mandays, FA’s and IT dev. Get any IT dev work started NOW then plan around deployment milestones.

    I’m giving no more away, I’m a ProgMgr myself and its both rewarding and really chuffing frustrating at the same time.

    Coyote
    Free Member

    Ask to see the original Project Initiation Documentation.

    Marge
    Free Member

    Make clear notes – lots of them…..

    One important thing is not to try to do peoples work for them, but to make everyone involved be aware of their tasks & deadlines.
    (& the sooner you do it the better)

    There’s a fine line between keeping people involved & updated rather than hounding them.

    Listen lots.

    Things that have happened you cannot change. Lessons learnt is a good thing but keep looking forwards as this is the only part you can influence.

    thisisnotaspoon
    Free Member

    there will be half a dozen minions who actually know what’s going on, learn who they are, and listen to them

    There are also several dozen minions who have no particular clue about the project but have their own little agendas. These are indistinguishable for the original half dozen. Choosing your half dozen is simply an exercise in scope creep.

    Identify changes early, and make sure everyone else can identify them, if a minion is asked by their manager “can you just do this…….” they should be straight away asking “who want’s it, is it in the plan, is it paid for and does it make the product better”. If it doesn’t get through all those, then bounce it back and ask for it to be raised as a change (with a man hour budget, schedule impact etc). Any changes that fail that process should be kicked into the long grass for a future project.

    mikewsmith
    Free Member

    Make sure you have a personal plan b and a fall guy.

    Northwind
    Full Member

    We have a Project Ninja. His entire job is to arrive after things have gone to shit, and make it work a bit. Not as planned, but good enough that we can muddle through til the next New Project. Now you’d think it’d make more sense to do things right in the first place but it seems like once you have a Project Ninja it’s your institutional duty to provide him with a limitless supply of failed projects.

    stwhannah
    Full Member

    Cover your ass. Make sure every decision is recorded. If you think something is wrong, make sure it’s recorded that you raised concerns. If you’re recommending a decision, set out all the pros and cons before the decision makers.

    Sounds negative, but if it’s clear to decision makers that they are actually making decisions and there’s a trail that leads back to them, they (might) tend to think about them a bit more, rather than just rubber stamping them or pushing on regardless of advice. (And if it all goes wrong, your ass is covered).

    701arvn
    Free Member

    It depends what “back on track” actually means…

    This is the one question you need to answer first.

    Nail on head

    You will find if you don’t establish this is the first instance you will not succeed because ‘success’ will change constantly.

    theteaboy
    Free Member

    If it needs to get back on track, it has gone wrong.

    You need to find out why it has gone wrong or you will fix the wrong problems.

    Too complex? People challenges? Too expensive? Poor estimating? Poor planning? Lack of buy-in from decision makers? Lack of consistency? Poor comms? etc etc

    I’d talk with all the key stakeholders, find out what went wrong from their perspective and find out what’s of most value to them. Try to work out which bits are critical and which bits are not and focus on the critical ones.

    CharlieMungus
    Free Member

    Try an AGILE SCRUM on a PRINCE shell

    sc-xc
    Full Member

    This is all great, thanks.

    It’s fair to say that pretty much the whole team will resent my involvement (I work with them but in a different role). I recognise that there will be a lot of people out to derail this.

    Documentation – patchy. There are a lot of different streams – some appear to have everything in order, some are clearly being made up as they go along.

    I have made it clear to the top brass that they need to play a role in the governance, they are happy to do this (albeit frustrated that it got to this point without them being involved!)

    My day job is kind of an account manager, so have very strong relationships with the top brass – I have been pretty open with them about what I’m uncovering.

    I’m off to do some actual work now, but will go through each response later – looks like there is some real experience here.

    (look out for the ‘I need a new job’ posts in 6 months!)

    DavidB
    Free Member

    It all boils down to communication

    perchypanther
    Free Member

    ” It was like that when I got here ”

    maccruiskeen
    Full Member

    1.It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women.

    2.Nothing is impossible for the person who doesn’t have to do it.

    3.You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.

    4.At the heart of every large project is a small project trying to get out.

    5.The more desperate the situation the more optimistic the situatee.

    6.A problem shared is a buck passed.

    7.A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.

    8.A user will tell you anything you ask, but nothing more.

    9.Of several possible interpretations of a communication, the least convenient is the correct one.

    10.What you don’t know hurts you

    11.There’s never enough time to do it right first time but there’s always enough time to go back and do it again.

    12.The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.

    13.I know that you believe that you understand what you think I said, but I am not sure you realise that what you heard is not what I meant.

    14.What is not on paper has not been said.

    15.A little risk management saves a lot of fan cleaning.

    16.If you can keep your head while all about you are losing theirs, you haven’t understood the plan.

    17.If at first you don’t succeed, remove all evidence you ever tried.

    18.Feather and down are padding, changes and contingencies will be real events.

    19.There are no good project managers – only lucky ones.

    20.The more you plan the luckier you get.

    21.A project is one small step for the project sponsor, one giant leap for the project manager.

    22.Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.

    23.If everything is going exactly to plan, something somewhere is going massively wrong.

    24.Everyone asks for a strong project manger – when they get them they don’t want them.

    25.Overtime is a figment of the naïve project manager’s imagination.

    26.Quantitative project management is for predicting cost and schedule overruns well in advance.

    27.The sooner you begin coding the later you finish.

    28.Metrics are learned men’s excuses.

    29.For a project manager overruns are as certain as death and taxes.

    30.Some project finish on time in spite of project management best practices.

    31.Fast – cheap – good – you can have any two.

    32.There is such a thing as an unrealistic timescale.

    33.The project would not have been started if the truth had been told about the cost and timescale.

    34.A two-year project will take three years, a three year project will never finish.

    35.When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.

    36.A badly planned project will take three times longer than expected – a well planned project only twice as long as expected.

    37.Warning: dates in a calendar are closer than they appear to be.

    38.Anything that can be changed will be changed until there is no time left to change anything.

    39.There is no such thing as scope creep, only scope gallop.

    40.A project gets a year late one day at a time.

    41.If you’re 6 months late on a milestone due next week but really believe you can make it, you’re a project manager.

    42.No project has ever finished on time, within budget, to requirement

    43.Yours won’t be the first to.

    44.Activity is not achievement.

    45.Managing IT people is like herding cats.

    46.If you don’t know how to do a task, start it, then ten people who know less than you will tell you how to do it.

    47.If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan!

    48.The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

    49.The sooner you get behind schedule, the more time you have to make it up.

    50.The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

    51.Good control reveals problems early – which only means you’ll have longer to worry about them.

    52. When asked for a number 1 tip, give fifty one number 1 tips 🙂

    fasthaggis
    Full Member

    Spike their drinks,take photos,report back here later.

    br
    Free Member

    What’s the one practical tip that you would give a totally green programme manager?

    Find someone who actually knows what they are doing, and get them to do it…

    tbh I’ve not a lot of confidence in your organisation if their approach to trying to ‘fix’ the problem is allocate someone with no/little experience and who probably already has a ‘day’ job.

    But, my nugget, and thanks to Keith Bontrager for assistance:

    “on time, on budget or appropriate quality – pick two”

    BlobOnAStick
    Full Member

    We have a Project Ninja. His entire job is to arrive after things have gone to shit, and make it work a bit. Not as planned, but good enough that we can muddle through til the next New Project. Now you’d think it’d make more sense to do things right in the first place but it seems like once you have a Project Ninja it’s your institutional duty to provide him with a limitless supply of failed projects.

    Hallelujah!

    BOAS – the Project Ninja.

    Top tip for the moment: NOW is the only time you can give some more ‘realistic timescales & budget’ without it reflecting on you. Make sure you build plenty of contingency into both.

    Good Luck!

    Edit: Just seen Perchy’s post. That. In spades.

    slowoldman
    Full Member

    Go and speak to people face to face.

    jonba
    Free Member

    I’d be reviewing initial timelines, scope, budget and assumptions. Document what state you were given the project in and see if you need to make major corrections to the above.

    I’d also be ring fencing unicorns.

    DT78
    Free Member

    Got to say I’m with br here. My number 1 tip is don’t hire a green person to do a programme turnaround of any priority. Chances for success are small. Suggests they don’t really know what a programme manager does.

    Would you entrust millions of £ of your own money to a super keen but inexperienced person?

    As something a bit more helpful, first thing I would do in your situation is look to hire an experienced programme manager, call them something different (maybe senior e2e delivery manager) and task them and learn from them quickly.

    Being keen and being experienced are very different. I’m a good guy and keen to be an architect. Don’t see anyone letting me take over their million pound building any time soon

    Also don’t mix up project and programme management. Or over promise and under deliver….

    bigjim
    Full Member

    Delegate all your work to others

    Keep most of the project budget for yourself

    Say “Sorry I’m too busy managing this project” when anyone approaches you

    Send emails at 7am saying how hard you’ve been working on the project since early and won’t be in until 9am, which is when everyone comes in anyway

    Sigh loudly a lot

    Blame the project team when it goes wrong

    This seems to be how it is done from my experience.

    br
    Free Member

    In fact the best thing you could do is hire my wife.

    Because for years now she’s been hired as a PM and when the hiring organisation find out how good she is they always end up asking her to:

    “just see if you can get this back on track please, it won’t take up much of your time and shouldn’t impact the projects you already have”

    Trouble is, to get the projects delivered she has to crack too many ‘skulls’, consequently isn’t re-hired once the s**t project has been delivered. Life of a contractor and all that.

    woody74
    Full Member

    Make sure that everyone on the project knows it is their job to get the project finished. Therefore no sitting around waiting to be told what to do. If you have a team of proactive people then projects often sail by.

    Make sure management all the way up is fully committed to help you. If they are not then don’t bother. I once ran a UK wide PC refresh program. I had a board level director shouting at me as to why I had not competed the rollout of laptops and at the same time he had just issued a dictate that no laptops could be upgraded or replaced as there had been a data breach. Even when I asked him for written permission to replace some laptops he still said no and in the same breath asked why the project still hadn’t finished. Smashing head against brick wall was an understatement.

    If there is not management support don’t bother!!

    If they want the project just finished then don’t bother about the budget, you can waste far to much time creating reports for the sake of it that no ones even bothers looking at. If they really want reports and budgets, insist you have a project support person to pull these together. Even if it is part time or an hour a day.

    epicsteve
    Free Member

    The main thing for me is making sure that you agree with the relevant parties that the timescales on the project plan are achievable. Too many project managers plan right to left (i.e. to make the tasks fit the timescales) and then don’t have buy in/ownership from the team who have to deliver the plan (as well as the plan usually not being achievable).

    onehundredthidiot
    Full Member

    Do a risk assessment. As in the risks to the project.

    No point in finding out you have one expert doing a crucial role that no one understands. You’ll be screwed when they go off ill.
    We had a £3million per annum project stall because,it turned out, there was 1 guy at a crucial stage and he was a contractor. Amazing how much he thought he was worth 6months in. Fortunately we had started to train 2 graduates in that task.

    richmars
    Full Member

    Ask the people doing the work how long a task will take, don’t tell them. They’re more likely to meet the target date if it’s ‘their’ plan, rather than one forced on them.

    ourmaninthenorth
    Full Member

    What these guys said^^^

    Priority task is to agree the problem statement with sponsor(s). Then to request 2 weeks to set about establishing the facts across the key areas of: requirements, scope, timeline, budget, third party commercials, business ownership, governance (incl. decision-making). You’ll need to grab all the PMs and get them into some sort of team.

    You won’t get all this done in 2 weeks, even if the PMs are all on board from day one. But at the end you should have done clear advice for the sponsors (predictably it will be: requirements are incomplete, scope has changed, timeline hasn’t been met so far, budget is broken, half the third parties don’t have contracts in place, there is no business ownership (so UAT will be a waste of time) and governance is a mess).

    You can then recommend the next course of action: full replan + budget recut, change of RACI….and to hire an experienced programme director to turn it round.

    Good luck!

Viewing 40 posts - 1 through 40 (of 49 total)

The topic ‘Project Management – your no. 1 tip?’ is closed to new replies.

New deal added to Members Discounts