3

I am an infrastructure PM, providing and managing technical environments for testing a large, complex new application which will then be put into production. I have to produce a plan for a project where I know the skills and numbers of people that I am likely to need, but cannot accurately estimate the start date or the duration of the project because the development team that will provide the code has no history within the company to give me a feel for quality of code (and hence duration of testing) or timeliness of delivery.

I need to provide an estimate of cost and duration for my part of the project, so I need to find a way to present my estimate with sufficient caveats and assumptions to cover a wide set of variables. Can anyone help with specific advice as to how to do this?

3

I've typically handled this by documenting the risk of lack of available resources in the project plan's risk matrix, allocating contingency reserves to the schedule to address that risk, and revising the project plan as the planning horizon changes.

To determine how long a contingency reserve task should be, ask each of the groups on the project team "What are your best, worst and most likely lag times to be able to start work on this project if the go-ahead was given tomorrow". You can then use a weighted average (e.g. PERT) or your best judgement to estimate how much reserve to add to the schedule.

Also factor in some time immediately after code receipt to get a high-level evaluation of the quality, and schedule a project plan review meeting immediately afterwards. Your testing team lead should be able to say at the review meeting they will complete testing in XX weeks. Go over the schedule with other team leads and revise it as necessary. Then communicate any changes to your sponsor.

|improve this answer|||||
  • 2
    Doug, a very helpful answer overall, and the code review is a great idea - +1 for that alone! – Iain9688 Mar 7 '12 at 20:11
3

Lacking (some) information is unfortunately a reality in all projects and often we need to get going without having that information. Here is what I do in these cases.

I communicate efforts and dates always based on the information available. I clearly list the items that are unknown at the time and how they can influence the ball park figure I have provided. I also make clear that how we are working on getting the remaining information and by when we expect to have it. Further I explain how the additional information may influence the outcome. You don't know what you don't know.

Then as I executed the project I try to work in very short cycles (or increments or whatever you want to call them). As my team works through the different items we address the high-risk areas first, e.g. the areas that we don't have enough information about. For example by providing early (pre-release) versions of a solution you may be able to assess the quality level before implementation is complete. Another option is the use of spikes for questions nobody on the team has an answer yet. A rough answer from a spike is always better than not having a clue at all.

In my experience working in short iterations has been an extremely effective technique to address the uncertainty. By short I mean one or 2 weeks, sometimes even shorter. As we refine the estimates based on newer information we reduce or even eliminate the uncertainty. Each time we have a better estimate we communicate this clearly to stake holders, which I think is very important, too.

Make sure your stake holders always know what is going on. You cannot over communicate. In almost all cases I have found that stakeholders are then very reasonable or even fun to work with. They have their experiences, too, and they understand that you don't necessarily have all the information at the beginning of a project. They just want to see a structure approach from you how you address that challenge.

Good luck!

|improve this answer|||||
  • +1 for the reminder that stakeholders understand uncertainty and are likely to be prepared to accept an estimate and a structured approach. Communication is indeed vital, so thanks for that too. In this project I will have no control over the code development cycle but I can see how working closely with the development team between releases will help to inform the planning process. – Iain9688 Mar 7 '12 at 21:05
1

Doug gave you a great answer. One other suggestion would be to break your project into milestones and build your contingency into the rolled up tasks rather than the individual tasks. Then be clear in your initial plan presentation, status updates, and risk monitoring that these milestones are based on the B,W,ML scenarios are suggested by Doug. And then revise and update accordingly as your project progresses.

Also, if you're using a Gantt chart or similar scheduling tool, be VERY clear on the dependencies, predecessors especially, and that one can't start until the other is finished, and that finish date isn't definite.

|improve this answer|||||
  • +1 for building contingency into rolled up tasks rather than individual tasks - I can see that this makes the contingency more explicit and more easily communicated and managed. – Iain9688 Mar 7 '12 at 21:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.