When You Assume | ||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
||||||||||||
 |
[ Login/Subscribe ] | |||||||||||
 |
||||||||||||
 |
 |
 |
 |
 |
 |
 |
|
 |
||||
 |
||||||||||||
Features
Departments
Executive
Resources
|
Home > Departments > Methods & Means
The plan looks good on paper. Competent professionals are executing it. But unexpected delays and costs still crop up. It could be the one area of project management where your years of experience can actually hurt you: assumptions. So how do you weed them out of your plan? Here are some unassuming ideas.
It happened to me again last week in the initiation phase of an Archiving Implementation project. We completed a successful proof of concept and were moving ahead with the implementation, which required a refreshed database. I had asked the database administrators (DBAs) how long it would take to build the refresh and they answered “4 hours.” I assumed this was a full estimate of the time required for the refresh, based on my experience working with DBAs on similar activities. What I didn’t realize is that changes in storage technology had changed our refresh procedures and this was now a System Administrator operation as much as a DBA operation. Consequently the estimate did not include either the System Administrator work or the coordination work.
I hadn’t waited until the last minute to get started, so this false assumption didn’t cause a delay in the project’s critical path, but it did cost some of my time and caused work to be done on a quasi-emergency basis rather than as a planned activity.
Every time I turn around, I run into an assumption.
Please login/register to read the entire article.
| |||||||||||||||||
|
Privacy Policy Contact Us User Agreement