If you manage development projects, you have likely heard the following statements:
- “I can’t give you an estimate for how long it will take to code this part of the application.”
- “Development is like art; it is a creative process.”
- “We are not sure how this will get done, so we cannot give you an estimate.”
At this point, the relationship between project manager and developer reaches rock bottom. The developer cannot understand how the project manager could be so out of touch that he would ask for an estimate for development work. And the project manager cannot imagine how this developer expects anything to get done without establishing a schedule.
Fortunately, there are ways of bridging this gap between the two worlds.
Provide help on how to create reliable estimates
Generally, the developer in this story is being truthful. For any number of reasons, there might actually be a part of the application that is a sort of black hole—it is not yet clearly defined as to how the task will be accomplished. This might be due to a weak point in the specification, or there might be some uncertainty about a specific technology that needs to be used.
The key here is for the project manager to be persistent. Project managers should help the developer work out an estimate for his work.
Problem: The developer cannot give an estimate because he needs to explore an issue or examine a technology. The developer should work with the project manager to figure out what needs to be done in order to make it possible for the developer to commit to a time estimate.
Solution: The project manager can help the developer to define a set of tasks that need to be done that can lead up to a fuller understanding of the issue or technology.
After the estimate for the undefined task is calculated, the project manager and developer simply add the remaining tasks to the time estimate for the project to reach an overall estimate for the project.
Figure A shows a sample project that has an undefined task that is preventing a developer from coming up with a time estimate for completion.
|Sample project with an undefined or complex task (Develop Server Component Y)|
The task called Develop Server Component Y is in such a state. The developer cannot give a workable estimate because there is some uncertainty concerning the workability of the technology the application will be using. In a case like this, the project manager should work with the developer to create a plan like the one in Figure B.
|New plan with proof of concept task added|
Figure B shows the plan with a new task added for the conducting of proof of concept testing before Component Y can be estimated. The project manager in this case worked with the developers to figure out how much time would be needed to determine the feasibility of the technology to be used. Through this process, the project manager also worked with the development team to get a preliminary estimate for the Component Y task if everything works well with the new technology.
In this case, it is likely that the developer was hesitant to offer a time estimate until after he was certain that the technology would work.
Consult developers earlier in the planning
Communication and planning are key elements of managing projects. The development of a schedule is as much a team effort as the actual project itself. Too often, project managers operate in a bubble, isolated from the people who do the work on the project. These resources are often brought into the project just before their tasks are set to begin. Developer input would be much more useful earlier in the scheduling cycle.
A great way to bring the development team more closely into the scheduling process is to combine functional or technical specification reviews with development phase schedule reviews. As the specification is being reviewed, the project manager can be building the work breakdown structure of the project. The spec review team can then provide input into timing, precedence linkages, and work/duration estimates.
The developers who will be doing the work will know immediately if you have inaccurately modeled the links between the tasks. They know if X must be done before Y or if they simply must finish at the same time. This process will also get them thinking about work and duration estimates earlier in the process and get them used to thinking about the project from the perspective of the project manager.
Specification reviews are a time when much thought is being put into the elements of the application. It is a natural extension to expand this process to the creation of the schedule. Another benefit, aside from a more accurate and complete schedule, is that a development team that has had input into the schedule will feel more involved and more in touch with it. The developers have had a hand in setting up the schedule and were not just handed a set of due dates.
The differences and divisions between project managers and developers may not completely disappear with these two steps, but these tips will foster better teamwork and collaboration.
Time estimates and developers
What’s the best way to wrestle a time estimate from a reluctant developer? Post a comment below with your suggestion.