Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on real-life situations. He then offers a solution, using practical project management practices and techniques.
I recently had a meeting with Matt, who was asked to estimate the effort required to upgrade to a new version of our standard database management software.
I could tell Matt was worried. “I need to put together a high-level estimate for this project,” he said, “and I’m having a hard time figuring out where to begin. We have over 200 databases in our environment, and they each bring their own complexities.”
“Have you discussed this project with the people who installed the previous release?” I asked. “If you knew how much effort they used on the previous upgrade, you might be able to estimate the effort for this one.”
“The vendor is already telling us that this new release will require a substantial amount of effort over the previous one,” Matt said. “I’ll be talking with the people who did the last upgrade, but it doesn’t appear that experience can be leveraged for this project.”
I thought about estimating based on an expert’s opinion. “Is it possible to find someone else who’s gone through this before? Perhaps someone at the database vendor or one of the research analysts could provide some insight.”
“I’m afraid not,” Matt answered. “We’re going to be one of the first companies to install the new release. The vendor is willing to help since we will be one of their beta sites, but they don’t want to put an estimate on the table without knowing what our learning curve will be.”
“A modeling approach might work well for this estimate since much of the work will be similar once we understand exactly what is required,” I suggested. “We can do a paper migration for a complex, medium, and simple database, and then apply some fairly easy math to estimate the total project effort.”
When conducting a complex project effort estimate, it’s wise, when possible, to reuse the knowledge gained from prior, similar projects or to get feedback from someone who has done the work before.
Unfortunately, this approach will not work on Matt’s project since the database management software is new. Instead, Matt can come up with his estimate by using a combination of work breakdown structure and modeling.
Matt has 200 databases to upgrade. Although each database is unique, there will be many similarities among them. Matt needs to identify a number of unique cases that he can use to categorize all 200 database conversions. My recommendation is to identify a very simple and small database, a very complex and large database, and one that falls right in the middle. From there, Matt should:
- Look at the entire population of databases and categorize them into similar groups of complex, medium, and simple. This may require some help from the other members of the database administration staff.
- Conduct a detailed work breakdown analysis of each type of database to estimate what it will take to migrate to the new release.
- Multiply the number of complex databases by the estimate required to convert one and do the same with the medium and small categories.
- Add the three numbers, including time for project management and some percentage for contingency.
When Matt is finished, he will have a fairly scientific, defendable estimate for migrating all 200+ databases.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America, and has developed a project management methodology called TenStep.
Tell us about them. Tom Mochal will answer those that affect the widest number of readers. Post a comment below or send us a note.