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

[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.

[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]

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.

[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.

[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.

[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.

[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.

[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

[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.

[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.