Network Estimating is better than Standalone Estimating. Follow our best practices for network estimating, you will be happy 99.6% of the time.
I noticed a sudden flood of emails cascading frantically across my screen a week or so ago. One of our clients was experiencing the pain of a network outage with the estimating, takeoff, and scheduling systems on a Monday morning. Not a pleasant way to start off a week to be sure. The emails kept coming, sizzling and becoming more caustic by the hour. The system was down for slightly over six hours, which kept the department scrambling like a grammar school at its first fire-drill, trying to figure out ways to squeeze some productivity out of its collective time. All our usual techniques, restarting license server programs, bouncing servers, and our trusted, tried and true troubleshooting efforts were frustrating and fruitless. When all was said and done, it turned out to be the result of an IT system changeover during the weekend. With apologies, the skilled info systems guys admitted the error upon discovery, and they got us back up and running in time for the last couple hours of the shift.
The Network Naysayers proudly rode the wave of discontent, smugly working their “I told you we were better off all on our own pc’s” look for all it was worth. Yes, it was good fortune that the department wasn’t swamped with crucial takeoff and scheduling tasks to perform in that period. And yes, it’s also true that isloated “silos”, each with a separate hardware key and unsynchronized copies of the databases would have been able to function normally during the network outage. So do we rethink our strategy of insistence on network-resident SQL databases, data files, & license keys? Nope, not for a minute. Are we hard-headed, single-minded, inflexible ‘net nerds?’ Maybe. But I can tell you from experience, that it costs the company far less to endure the annoying and temporary debilitating effect of that lost productivity, than it costs daily, weekly, monthly, and yearly to fight the constant battle that de-centralized information management causes. Joe’s kids are sick and the bid that needs to go out is on his computer, that no one else has access to. Susan is using a different database than everyone else, and the productivities are different, and the spec sections don’t match with the rest of ours.
It’s called the “One of Us Might Get Hit By a Bus” theory. Good companies know and understand this, and unsynchronized, pc-based data is not an option. It’s far more expensive than those rare network outages. In the big picture, if the network goes down for even eight hours once every three months, which calcs out to 8 hours out of over 2200 hours, or less than 4 hours in a thousand. (that’s a better than a 99.6% productivity rate. Wish I could claim that!) And that’s exaggerating the outage rate, it’s often better than half that downtime, or twice the performance.
That said, it”s important to have a few safeguards in place when you utilize network estimating.
1. Keep at least one or two license keys to run the software, either with physical keys or checked out licenses, for mission-critical programs.
2. Set up a synchronized folder with key data folders.
3. Backup crucial files before leaving work for the next day for urgent work.
Also remember that neither a database nor a network connection is required to close a bid. As long as you can access the data file, (see rule 3 above), and open the software, (rule 1), the bid can be closed normally, despite the unlikely instance of downtime at a critical juncture.
So here’s your homework, if your company isn’t compliant with our best practice for network estimating rules:
1. Databases reside on the server. It’s ok to keep a local copy for emergencies. Just make sure it’s sync’d at least monthly.
2. Develop a CONSISTENT file structure for all estimating and project files.
3. Save all data files to the server, in the folder structure designed in #2.
This came up at a job meeting yesterday, with a good company struggling to standardize its procedures. After some discussion, we’re moving their system to one that’s network-based.
Please check back next week,
BC
