Managing a large project

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply
Natalie
New Member
New Member
Posts: 1
Joined: Sun 02 Apr 2017 9:30 pm

Good evening

I'm hoping you can offer some advice.

I am currently going through 2nd stage nterview for a brand new team to develop a new product (moving from desktop to web). I've been told that it's going to be a 3 year project. The designs are complete but that is it.

I have managed many projects in my career, mostly agile but never a 3 year project!

I have no idea how I would kick this project off. Would we need to produce a backlog and complete estimations for the entire project upfront? That feels more like waterfall to me. I'm thinking of breaking the huge project down into smaller deliverables and estimating them separately.

Any advice greatly appreciated.
Mino Trombetta
New Member
New Member
Posts: 1
Joined: Tue 04 Apr 2017 11:52 am

I'd be a little worried too... :D If the Designs are completed I guess that means the requirements are known and that therefore there is a budget... but you refer to "estimations" which implies that part of the project is to estimate how much it's all going to cost? You're on a hiding to nothing if you're not careful...

There should be a Business Case. What is the project supposed to achieve, over what time frame (RoI) and at what cost? Someone had to sign off that the business case stacked up (i.e. that spending £xx over 3 years would be worthwhile and that the funding/resources required would be made available. So.. read the Business Case.

There must also be a set of requirements. Your first job is to dig them out and have those validated and signed off by whoever the project is for (your Beneficiary). They could be fine... but it could equally be a lash up and you'll have gaps. Whatever the requirements .... build them up in as much detail as you can get... they must be "agreed" (i.e. someone has to sign in blood that this is everything the project needs to deliver).

Once your requirements are agreed then you need to validate the designs. Will the designs deliver the functionality that is implicit in the requirements? You only have to deliver what meets the requirements... so as above, once you have them nailed down, your recipient has to sign them off. If you give them "x" then that satisfies requirement "y". Make them agree. They know more about their requirements than you do. Get it signed off (their other arm will still have some blood in it).

Now I guess you have to estimate it. Get a broad(ish) canvas of opinion. People will be afraid of under-estimating whereas Business Analysts will tell you everything can be done in half the time. The truth is often in the middle. Get a feel... add some contingency (the more doubts and unknowns there are, add more).

While people are estimating Work also get duration... since some tasks might be quicker/allow multiple resources. Others will be the work of just one... but then you can build up your Backlog and start putting tasks in order (if you want Agile). Once you're this far then you're ready to work out how many Sprints you need (depending on resources) and that will tell you how much it's likely to cost.

You must revalidate the Business Case before you get going... since it may say "if we spend £500 we will save £1000"... and your revised costs may come in at £2000 (...to save £1000). Don't let them mug you, since it'll be your fault when they discover that they didn't know what they wanted except that it should cost a quarter of what it will and deliver twice as much functionality as is possible for the price. :D

Good luck with it..
Post Reply