The Delphi Method and Project Management

Spend some time studying software development models.  Fashions change and so do the sizes of projects and the sizes of the teams tackling those projects, so try to avoid getting too enamored with any particular model. Instead try to see behind the individual vocabularies and preferences.  You'll find that whatever they're called, software development models are really risk management activities.  It matters little whether you're looking at Boehm's 1988 paper about the Spiral Model or a new video posted about an agile development model.  In the end, the project manager is using various tools and ideas to manage risk in a software development project.

The artifacts of the various models are good and interesting.  The "Burn Down Chart" from Scrum is appealing to some.  The feature set lists and "Progress Bars" from Feature Driven Development are also attractive.  All will probably work -- if you use the procedures wisely and have good work estimates to begin with.  If you  have good data, you can extrapolate to see likely end dates.  If you have good data, you can see which teams are struggling and try to move work around to make things better.  

To the extent that your work estimates aren't so good, your artifacts probably won't be either.  If you keep good records and manage to survive for a few years, you might be able to get some mean productivity measurements for your product development teams.  These could be useful (if your staff turnover is low) because project decomposition into functions, features, objects, or whatever building block your organization uses will probably be done by a slowly changing set of staff members.  If you keep records and count the number of building blocks completed per engineer per unit time, then for future projects you can use that data for rough schedule estimates.  

If you manage to survive, you'll be able to refine your building-blocks-per-unit-time estimates over multiple projects and multiple years until -- for your teams, anyway -- they might give you some useful estimating tools.

But what do you do in advance of that?  How do you obtain estimates that are credible and reasonable before you have historical data for your teams?  You might consider some variation on a Delphi Method.  (Note: if this link goes bad, please Google some variation on "Delphi Method" or "Delphi Process" to find another paper describing it.  There are also wikipedia articles on this method.)

Delphi Method Summarized:

In any viable development organization, you must have some subject matter experts.  If you don't, well, you're going to have trouble developing viable products, so let's assume that you have two or, better yet, three subject matter experts (SME's) on your team.  Here is a quick summary of the Method:

1. Initially, each SME, working independently, develops a work estimate -- a forecast.
2. Each SME expresses her/his forecast in a specified manner, e.g. via a form, and submits the forecast to the project manager or other Facilitator.
3. The Facilitator combines and summarizes the individual forecasts, preserving anonymity while identifying areas of disagreement and important details.
4. The SME's are convened as a panel to discuss the summary report, ask questions, etc.

The process then restarts at the top and goes through all the steps again.  Iterations continue until a consensus is reached or until the project manager feels that the process has converged as far as it can (in which case the project manager will have to make the final call).

The key to the Delphi Method is that each SME operates independently while developing his or her forecasts.  By combining the forecasts, we assume that we'll end up with something that at least represents some varying points of view.  By letting the Facilitator synthesize the results, we avoid the situation where a dominant personality exerts excessive influence on the process.

Once you have work estimates for your project, you can apply them in whatever development method you choose.  Again, keep a record of actual "burn rates" of features.  If you have several developers working on several projects, you will eventually develop some baseline productivity data that will be valuable in subsequent projects.  Even if you continue to use the Delphi Method to develop work estimates, your historical record will be extremely valuable as a sanity check.