I was shoveling my driveway this past weekend with three 9-year-old helpers. They sort of shoveled but mainly just loved making snow piles and jumping on them. With high hopes, my son asked me if the three of them could shovel the neighbors’ driveways and get paid for it. Sure, I said, as I outlined the process: Neighbors would not pay him until they could see the concrete in the driveway; we needed to finish our own driveway first; working very hard with our two shovels, our driveway would take at least two more hours. In no time at all, my realistic estimate had shattered his dream of making lots of easy money.
That scene reminded me of a time at a previous job when every week the technical team I was leading was blamed by the Millennium project manager for missed deadlines. To figure out the problem, we arranged a meeting between the application and technology teams. The meeting revealed a number of communication and procedural issues. Among them, the tech team stated that it only needed one day to refresh a domain. This estimate seemed really optimistic to me, so I dug a bit deeper into the steps required for the refresh. I discovered that this time frame was based on the following assumptions:
- The tech team would receive at least a seven-day notice that a domain refresh was needed. That would provide ample time for a full backup of production and for our off-site tape storage vendor to bring the tapes back without a rush charge.
- The tech team would have enough space in the non-production domains’ storage area network (SAN) to restore production.
- Once we had completed the database restore and cer_exe copy on the back end and run a scan for components or reinstall on Citrix, we would be done.
So if the application gave us a seven-day warning before the project needed a domain refreshed and if we had a full backup and if we had enough disk space on the SAN and if we had a clean reinstall or clean scan for components and if the tech team worked 24 hours a day seven days a week, the domain refresh could be done in one day. I still shake my head at the memory of this conversation. The reality was that few of these things ever happened and none of them ever happened all together.
- We never had seven days’ notice.
- On several occasions we paid for our off-site tapes to be brought back (yes, I took the beating for that cost).
- Only once did we have enough SAN disk space. Generally, we would have to stop the restore several times to add more.
- The scan for components rarely was completed without issue.
After bringing reality into the domain-refresh process, I modified the project estimate from one day for the tech team to hand over a domain to three to five business days. Did this stop the finger-pointing? Quite the opposite, the application team went crazy. They now blamed the tech team for not delivering domains. I tried to appease them: “Well, if you can tell me how many refreshes and the exact dates you need them, I can modify the estimate.” Oddly enough, no one—not even the project manager—could tell us the number of refreshes they needed, let alone the dates.
I find it ironic that my 9-year-old son had the same unrealistic optimism for completing a task as the 20- to 50-year-olds on my tech team. They also shared the same look of discouragement when I tempered their optimism with the facts. But they eventually reaped the benefits. At work, the project team accepted the new estimates, the tech team was able to put in relatively normal 10- to 12-hour days during a refresh, and we began meeting our deadlines. At home, my son jumped in the snow until he couldn’t feel his toes and then happily warmed up with a cup of cocoa.
Prognosis: Work is no place for a snow job. A realistic assessment of procedures and the time required to accomplish them will keep teams working well together—and meeting project deadlines.
