Calculate hours for project

Question

I'm trying to calculate hours for a project, but I feel very stuck and without too much experience I'm not sure where to start. This is for a software project and the requirements for the software has been split into tasks, but each task is very vague (example: "register customer inquiry." it can be everything from integrating with a phone system to a simple text input field.)

I don't completely understand the workflow for the target user of the software and our dev teams has zero experience with the technology will be used for developing the software and to make it even more complicated, I have not worked with any people on the dev team and don't know them, so I don't know how they work, how fast they adapt to new technologies (after courses) and how independent they work.

To get the approval for the project, it needs to be accepted based on how many hours required to complete the project.

I can just put some random numbers on each task, but.. garbage in, garbage out... Where to start?

Answer 1

For a start, you cannot create a project plan if you don't know what you're planning. You say that you don't "completely understand the workflow for the target user".

Well, you need to start by talking to somebody who can explain what is going to be built.

Then you need to understand the underlying technology. Your comment "it can be everything from integrating with a phone system to a simple text input field" means that you need to get a better picture of what is needed - will a database needed to be created and queried, or are you plugging into an existing system?

Once you know what is going to be built, then you need to find out who is going to build each component.

Then you need to sit with each person and ask them for their estimates.

There's no way around this - you don't even have enough knowledge at the moment to "put some random numbers on each task" since you have no idea what the task means.

Once you figure out what is being built, who is doing what and how long they think it will take, you have to add in a "safety factor" (for sick leave, vacation, bugs, etc.) as well as testing time and integration time.

Then double the number ;-) as many an experienced PjM will tell you.

Answer 2

The dev team ought to be responsible for planning and estimating since they are the ones responsible for delivery. Ideally begin with a workshop with the product owner (senior stakeholder) so that the team can have the chance to seek clarification of requirements and priorities. If the team already have a familiar way of planning and working then try to make use of that.

Assuming they will take an iterative approach they just need to break things down into small enough items that they expect might be done in a single iteration (say two weeks). Since they are unfamiliar with the technology they had better use relative estimation ("story points") and then group things into iterations based on that. The estimate is then the approximate number of iterations multiplied by the number of hours effort in each two-week cycle (just assume a fixed team size).

Clearly there are a lot of unknowns here so I suggest giving a range (low-end to high-end) estimate rather than a single absolute value. The estimate needs to be accompanied by some suitable words of caution about the uncertainties.

Answer 3

To be honest, the best advice I can give is to find a new project; I am skeptical that this one can be rescued.

Step 0 is to manage communications. Sit down with the project sponsor (and whichever stakeholders are relevant) and tell them that this project is in serious trouble. Make sure that they understand that any estimate for schedule (and for cost/quality) are going to have a minimum error > 100%. Unless something dramatic happens you cannot make a credible prediction about the future of this project. Personally, I'd frame the conversation as a choice between two recommended choices of action - either cancel the project (recommended), or else choose to manage the project (because the current state is not project management; it is a recipe for disappointment).

Assuming that they agree to put the project under project management, the first step is to rewrite all the task descriptions to be crystal clear. The second step is to work with the SME's to develop credible estimates for each task.

Step 1 - develop estimates. Broker between the SME and the stakeholders/sponsor to achieve definitions of each task that are clear to both parties and are measurable. You cannot estimate what nobody understands. I don't have enough situation specific information but I suspect you're going to have to do this in an iterative fashion - select the earliest and/or most important milestones and clarify them first. See if you can get them clear enough to start production, and then create a process to clarify the remaining goals. This will be a huge task for you, but if you can succeed, you're going to build a lot of credibility for yourself and for the project.

Step 2 - work with the developers to develop a credible estimate for each task. "Credible estimate" means a best/worst/probable estimate with a confidence interval. (I believe that the mockup for the user interface can be accomplished in 2 weeks; I'm 90% confident that it will be complete in six weeks. If the existing code doesn't require extensive rework, we could complete this is 4 days. So the GANTT will show 12 days (PERT estimate (30+(4*10)+4)/6. Repeat for every task.

But don't get distracted by math and confidence intervals; the key to success is the communication with the developers. Developers have been trained to lie about estimates, because they've been held accountable for stupid estimates in the past. Your success depends on convincing them that (a) you will represent and defend them; they will not be penalized and (b) Estimates are estimates - you will communicate that these are estimates in a band - if a task is within the confidence interval, both planning and development were successful. Commit to work with them to continuously update the estimates and to communicate with management. My best approach in the past has been to guarantee that you will let makers work on maker time and you will bridge to manager time, and that you will defend them from managers. (yes, I'm being repetitive). In my experience, devs don't like estimation or tracking, they like creating; I offer to let them focus on the part of their job that they enjoy and I take over the part they don't enjoy (meetings, estimates, communication with non-developers, etc.)

You'll need to build in a management reserve - I'd suggest you begin by looking at critical chain method; that may help to build confidence with the SME/developers.

I've failed to be brief; the summary is that the project you've described is not being managed, and it will fail, damaging the reputation of all involved. If the participants want the project to succeed, they're going to have to back you in your efforts to manage the project, and the first steps are to clarify the tasks and estimate the tasks. Then pick up everything else from PMBOK.

Good luck.