TaKaDu’s software establishes a baseline of “normal behavior” within each network. The better it understands normal patterns of water flow throughout the day, the more accurately it can detect aberrations that indicate a leak or a burst. It knows that water flows are highest in the mornings and evenings, before and after people are at work. Anybody Call A Plumber? Bloomberg Businessweek, Jan 12, 2015.

I had studied every past project I could get my hands on. The typical project for a new product went 18 months and we had dozens going on at any time. No one else ever looked at these “old” projects I realized.

I asked the Scada guy what he does with the data. He say’s “We store it.” I thought, “This is it! I’m going to mine this dormant data for golden nuggets.” Anybody Call A Plumber? Bloomberg Businessweek, Jan 12, 2015.

What was great was that we had a management standard that said all project artifacts would be published and archived using a specific software tool for this purpose. It was nicely laid out with folders created following a standard. The folders were periodically audited by the quality team to ensure they were getting done correctly. The project site was available for anyone to access. Nobody, it seemed to me, ever looked at the folders once the project was completed.

See more in How To Get The Project Data We Need

As new projects were completed, I’d dig into their data and capture what happened in their project (e.g. schedule performance, defect trends, critical issues found, etc.). What I was trying to determine was how do projects unfold. What are typical things that go wrong? How long does it really take to get a new product’s software debugged? How long does it take to complete a project from the first time it is approved, through all the regular replannings, to finally approved by a customer? How many open and incoming defects are normal when a customer finally approves a product?

I came to know what was normal in our projects. I had done enough projects with this company that I understood the project archives and the meaning behind the saved data. I knew we always started projects three to four months late which meant we delivered them to the customer three to four months late. I learned we never had an on time project. Never. I learned that we typically replanned a project 2-3 times at the beginning and just about weekly in the last three to four months.

For more see Good Data Is Hard To Find

When things went wonky on my projects, I knew when it was normal. We always had a spike in defect reports at certain points of the project. I knew it took about six weeks to work off the majority (95%) of the defects we detected on any one day. People would go nuts and call emergency meetings three times a day. I’d just manage us through it without all the emergency meetings because I knew it was normal and I knew how long it would take to resolve all the issues. I also had already accounted for this time and “normal emergency” time in my schedule. I had one COO tell me that she liked me managing the emergencies because she knew they would settle down and just get solved.

The key was that I knew what was normal, what a typical project looked like, how the typical project would play out. This included all the typical problems that would go wrong. Most importantly I knew that given just enough time in the overall schedule, we would have the time to fix any issues and further, improve our quality over previous projects. And, by the way, that just enough time was no longer than we had taken to deliver a project in the past (except we delivered on time where none had delivered on time).

You just gotta know what is normal. It makes even the biggest and most complex projects practically easy to manage. Now that’s a project management tool that everyone should be using.

See finally Successful Projects Are Boring!

Do you know what is really normal in projects you manage in your company?