Reply to: Failing Project - unsure what to do.....and out of my depth

[Peter Loew]

Great advice on this thread. This is going to be one of your most useful experiences.

- identify key deliverables, which will involve de-scoping the project to meet the deadline
- get formal feedback on the deliverables and delivery time from your lead devs / techs / architect teams and minute the meeting
- update the project plan and PID / scope doc / bullet list and send it out to your above tech leads and ensure they agree
- once they agree inform your sponsor / manager that the whole team is behind you and this is the new deliverable set for the given deadline. If they don't respond or don't care, then put something in your email like, "we will be proceeding with this unless you highlight any objection in the next couple of days", putting the onus on them and not waiting for their explicit approval, which will never happen
- given the above is a bit crafty, after a few hours of sending the email, arrange a project team meeting with your managers / sponsor and put it in the diary and reference your email- if they turn up, great, if they don't bat an eye, you're still covered
- inform your key users about the new plan / scope and manage their expectations about what's getting delivered
- ensure you have bi-weekly or regular project team meetings to track your new plan
- set up weekly project team meetings with your managers and sponsor and give them the highlights

Key to all this is to ensure you're covered as much as possible, and that you have your team with you, and that they're signed up to the plan and scope.

Good luck.

P

[v8gaz]

Of course the one thing to remember throughout all of this is that the project will be a big success on your CV.

[TheSurfer]

The key job of a PM is to "Descope".

No project will possibly get done on time if the business users have a free reign.

Your 3 prorities are therefore

1 Descope
2 Descope
3 Descope

So true! The best (well, maybe the only) PM book I read was 'The Lazy Project Manager'....... it's in the Kindle Store. He's big on nailing any scope creep.

[Mephisto]

Treat it as your deep end learning curve thingy - my first was similar, plonked in at 11th hour no commercial experience and still a temp.

However got my head around the various facets, translated the big words into layman's and delivered most of what was required.

If you pull it off (not in the office, fnaar) then it will bode you well in the future hopefully

[jmo21]

Precisely why they invented Agile - to give them an excuse for changing it mid-flight.

and so long as the business is happy with having lower priority items bumped off the end of the timeline, it can work very well.

If they don't, then it's not agile's fault, any methodology will fail.

[malvolio]

Here's my opinion (as a developer)

If you get the spec exactly right from the beginning and NEVER change the spec, aside from minor tweaks here and there, the developers (provided they are competent) will deliver a reasonable first pass which after some testing will meet the requirements perfectly.

If you arbitarily decide a spec and then react to every single change demanded by "business" including ones right up to deadline day, it will all end up a disaster with different ideas on implementation and will be massively late and everyone will get fired.

Note that also asking for timescales from developers then chopping percentages off will not go well

but double what they tell you

Precisely why they invented Agile - to give them an excuse for changing it mid-flight.

[oversteer]

Here's my opinion (as a developer)

If you get the spec exactly right from the beginning and NEVER change the spec, aside from minor tweaks here and there, the developers (provided they are competent) will deliver a reasonable first pass which after some testing will meet the requirements perfectly.

If you arbitarily decide a spec and then react to every single change demanded by "business" including ones right up to deadline day, it will all end up a disaster with different ideas on implementation and will be massively late and everyone will get fired.

Note that also asking for timescales from developers then chopping percentages off will not go well

but double what they tell you

[TheFaQQer]

I'd ask these developer bods to develop their sub-plan, provide a work breakdown, and timescales, then I'd tell them I want it quicker than what they have estimated (reduce their times by a 3rd), and start to kick some ass.

And I'd expect any competent developer to tell you to f*** off.

As I've told PM's in the past:

I've given you my estimate, based on my extensive experience as a professional - if you want a different estimate, get a different developer.

Moan all you want about it - that's the estimate, and arguing about whether it's good enough is just wasting time that I could be spent doing the work.

If I give you an estimate, and I miss it because of something that I could control, then's the time to kick ass. If you don't like the estimate because you can't plan, then bitching to me about your failures as a manager isn't going to get you very far.

[northernladuk]

To be fair FA, the OP had PM thrust upon him - he started out as a PMO handle turner.

But this could just be the making of him as a PM - if he can pull this off he will be able to look anyone in the eye and tell them he's a PM.

Amen to that. And because PMO -> PM isn't always a natural progression being thrown in at the deepend may also work in the long run. Going to be uncomfortable in the short term but if the OP can pull it off they will look back in a couple of years and laugh it off.

[cojak]

If a project was going to be delivered on time and on budget all the time and every project member pulled his weight, there would be no position open for project managers. You are in a job because projects go haywire easily. Your job is to prevent it and make sure its on track despite every possible problem, including a flood wiping out all your servers. If you are not capable on managing a project you are not cut out to be one.

To be fair FA, the OP had PM thrust upon him - he started out as a PMO handle turner.

But this could just be the making of him as a PM - if he can pull this off he will be able to look anyone in the eye and tell them he's a PM.

[fullyautomatix]

If a project was going to be delivered on time and on budget all the time and every project member pulled his weight, there would be no position open for project managers. You are in a job because projects go haywire easily. Your job is to prevent it and make sure its on track despite every possible problem, including a flood wiping out all your servers. If you are not capable on managing a project you are not cut out to be one.

[BlasterBates]

I'd tell them I want it quicker than what they have estimated (reduce their times by a 3rd), and start to kick some ass.

I can't see that working. I've seen PM's try that and fail. You can get people working there asses off for a week but then they lose motivation and start f**ing everything up. Development doesn't work when people are stressed because they start to hack. A bit like kicking an artist up the backside to get his painting out.

[Umbongoo]

The key job of a PM is to "Descope".

No project will possibly get done on time if the business users have a free reign.

Your 3 prorities are therefore

1 Descope
2 Descope
3 Descope

The developers will develop everything you've just got to make sure they aren't over burdened.

..and always multiply their estimates by 3.

Oh and as a rule of thumb you need as much time to test as you do to develop. So you can only have 6 weeks for development and unit testing. See what you can do in that time and then replan.

Expect to have a rough system Version 1 up and running in 6 weeks. Then add functionality for say two or three weeks, and freeze the system at least 2 weeks before go live. Just essential bug fixes after that date.

All this is interesting BB, and might be valid (I aint no techie), but as the "PM" it's not his job to do this, it's his job to ensure that it's done, and like has been said - those team members need to wake up. I'd ask these developer bods to develop their sub-plan, provide a work breakdown, and timescales, then I'd tell them I want it quicker than what they have estimated (reduce their times by a 3rd), and start to kick some ass.

[BlasterBates]

The key job of a PM is to "Descope".

No project will possibly get done on time if the business users have a free reign.

Your 3 prorities are therefore

1 Descope
2 Descope
3 Descope

The developers will develop everything you've just got to make sure they aren't over burdened.

..and always multiply their estimates by 3.

Oh and as a rule of thumb you need as much time to test as you do to develop. So you can only have 6 weeks for development and unit testing. See what you can do in that time and then replan.

Expect to have a rough system Version 1 up and running in 6 weeks. Then add functionality for say two or three weeks, and freeze the system at least 2 weeks before go live. Just essential bug fixes after that date.

I can tell you now the day you communicate to your management that Version 1 is up and running is the day you'll feel the "undoable stress" evaporate.

The fact is it's fairly normal to delay go live but you need to be demonstrating progress and you really need to get a grip on when it actually is deliverable. The crime as it were is to leave management not knowing when or indeed whether it will be finished.

Sometimes the basic technology, ideas are total garbage and during testing it becomes clear that thing will never work but that is probably beyond your control.

[craig1]

Forget governance, management and all that other stuff, that's great in theory and in courses but it's broken in your company. Go through the motions with them in terms of reporting.

13 weeks in website development is a good chunk of time. Talk directly to the techies and techie team leads and ask them what they can do in that time, push them to be realistic rather than make optimistic guesses. Spend some time with them going through the project's expected deliverables and don't be shy about descoping anything and everything that's not on the signed-off business case. Your focus should be around delivering SOMETHING rather than EVERYTHING if you know that the timescales won't allow you to gold-plate the delivery. Also, engage directly with the key users if the sponsor is useless, you do know who they are don't you?

On tech specs, push back to the techies and tell them that's their job. If they've been given credible requirements then they should develop to them. If they haven't been given requirements (sounds like this is the case) then they'll have to make best-guesses and document in detail the assumptions they've made. It's your job to then take the assumptions and tell the sponsor/users what you've done so it doesn't come as a surprise.

Jumping in the deep end of PM life is stressful. My first project was a £4m international software development where I was expected to deal with the board of a major Dutch telco. I was so far out of my depth that I had no clue what to do and my company couldn't care less beyond whining at me that they were disappointed with some of my decisions. 15 years later and I'm still managing projects and look back at that time as a baptism of fire that showed me exactly how not to run a project.

If you want a course that helps you with the proper way to run projects then Prince2 is useless, I'd recommend either the Open University's M865 or ISEB PM. Neither will make you a PM but will give you a theoretical grounding on how to run a project and help remove some stresses/gaps.