Project Planning in Teams

I have to admit I hate having to write up a plan which is why I always do my project planning in teams for the simple reason that it lightens my workload and also ensures a far more accurate project plan is produced.

So how does this work? well very simply follow the points below:

1.0 Who Are Your Project Team Leads?

Well the first thing when you get asked to write a project plan is to find out who has been allocated to your project. At this stage, whilst the exact makeup of the team won't be known, the team leads should be.

2.0 Communicate the Big Idea

At this stage you should have a high level view of what your project is going to deliver and by when. Therefore hold a kick off meeting with the team leads you have been told about and communicate the Big Idea to them. You will also want to the assigned Business Analyst team lead at this meeting as they will have a clearer idea regarding the lower level detail of the project scope and also the Business Case.

Just ensure that everyone is clear that you are the project manager delivering this project and as such in charge. The reason I say this is because if the BA involved has been at the Organisation for a long period of time, they will often unintentionally I hasten to add, try to take over this meeting. You must stop this quickly and assert your authority especially if you are new, so that the team leads know that you will not be a pushover. A skill which is particularly important later in the project lifecycle when scope creep and problems over project cost controls rear their ugly head.

3.0 Initial Team Estimates

You will find that no self respecting team lead will provide any type of plan or resource estimate at this stage. The reason being that all too often they find these being touted around and being stated as reality.

Consider this scenario as a team lead. You provide a high level estimate basd upon the BRS (Business Requirements Specification) for a team of 5 developers being required for 20 days. Despite your caveats that this estimate could fluctuate drammatically based upon the detailed requirements this estimate of yours ends up being stated as fact to the project sponsors. When the detailed requirements are done you realise that in fact there is a great deal more work to be done and you will actually need 8 developers for 40 days. Only problem is that this isn't in the project budget and worse still it mucks up the project plan and scheduled launch date.

Before you know it you have become the difficult team lead who can't estimate properly, and is causing the project to fail in terms of cost and time. You end up in numerous meetings trying to explain yourself and finally when you get the additional resources and complete the work, you get no thanks because of your initial estimate.

Now, can you see why team leads are reluctant to provide initial high level estimates?

Having said that if you play it right you can still get verbal high level estimates from your team leads along the lines of, "I think it will take 4 testers 30 days to do what is required. But if the test environments we need aren't there then it could take double that". Then when you are pushed by project sponsors you will at least have an answer to their incessant questions regarding "how long do you think the project will take and for what cost?"

Click here for Project Planning in Teams Points 4 & 5