Soliciting Project Estimates from the Team

Project estimates can be one of the more challenging aspects of managing web development projects. There are so many factors involved: defining (and sometimes guessing at) accurate requirements, factoring in learning curves, consideration of client budget and expectations, timeline, etc, etc.

If you have an experienced development team at your disposal, you can leverage team members’ experience and expertise to come up with better estimates. Each person brings a different perspective to the task, which leads to a larger set of questions being addressed, and more thorough and well-informed estimates. But much like the web project itself, the value you get out of this exercise will be determined by how you approach the process.

The best way to solicit estimates from the team is to ask team members to make their assessments separately. Discussing it as a group is liable to lead to consensus which is not a good thing in this case. Consensus isn’t necessarily built around accuracy, but can reflect circumstantial issues such as the order in which predictions are presented, the persuasiveness or seniority of individuals, unpredictable interruptions, etc. By asking people come up with assessments independently, you are more likely to get their actual opinions which can be assessed more objectively.

However, merely keeping assessments separate only assures that one person’s opinion doesn’t affect another’s. One must also provide the team members the data and process necessary to make good predictions. This may include:

• Previous project estimates/actuals: It would be wonderful if we could just use previous projects as measuring sticks for the effort required in future projects. Unfortunately it’s usually not easy. Each project is its own animal, and what we learn in one project may encourage us to approach the next project differently. Nevertheless, previous projects provide real data to inform our estimates and putting this at the disposal of the team can lead to more informed assessments.
• Project requirements: The more detail the better when it comes to requirements. Oversimplified requirements are likely to lead to underestimation. Of course, in order to provide it to the team you have to get it yourself, so making this a part of your process will have the added benefit of improving your overall project approach. But pre-contract specs can only go so far, which means your team will likely have questions. Use this to drive your follow up process and the post-contract requirements gathering.
• Resources and schedule: The team will need to know what tools and staff they’ll have at their disposal to execute the project, as well as the schedule they’ll be following. How much of the team’s resources may be dedicated to the project, what technology platforms will they be using, will there be legacy systems or data involved, will staff members with particular skills be on the project, when are certain deliverables due? You may not be able to answer all these questions, but whatever clarity you can provide will lead to better estimates.
• Client context and expectations: We all know that the particular client can have a powerful influence on the amount of work that goes into a project. Let your team know what to expect so they can factor it in to their predictions. Also, make sure everyone understands to what extent content development and migration, launch procedures and training are going to be part of the project.

Ask team members to write down their estimates and questions before meeting as a group to discuss them, and arrange for everyone to present their findings. This should encourage them to have more confidence in their own assessments and give you a diverse set of opinions.  The group may very well move toward consensus anyway, but having these informed, personal assessments provides a check against doing so without a real consideration of the project complexities and scope.