Learning to See Through the Walls

Is project management an art or a science? Probably a bit of both. But there is one thing I can tell you for sure: project management requires creativity…

Like any other profession, over the years project management brings you professional wisdom, especially if you get a chance to work for many different organizations across multiple industries. An experienced project manager would typically offer a much wider variety of tools and techniques when facing a particular challenge than someone relatively new to the profession. One of the things that senior PMs typically develop is that professional project management “paranoia,” when you constantly identify risks and look for mitigation strategies. This is a very valuable qualification, yet sometimes you can see so many risks and dependencies that you miss the “easy way” through the wall they create.

I have been through that experience. And sometimes I still have to force myself to shed that “worst-case scenario” prism in order to see more available options.

I was once in the process of initiating a new project that involved integrating data from multiple database sources. Each of these sources was actively used for operational purposes, and hence, integration with a live database represented operational risks. It required a reliable real-time replica that would take weeks, if not months, to create. Quite a constraint. On top of that, one of the sources was undergoing a complex version upgrade, which made integration impossible for at least a few more months - a clear dependency. And in addition to all of that, the corresponding database resources were fully occupied with the upgrade work and could barely spend any time on my project.

"Taking Shortcuts - In a Good Way". - PMAID Consulting Group Blog

On one side, I had the vendor ready to proceed with the integration and the management eager to implement the tool. On the other side, I had two database products that were not ready for integration and would require at least 3-4 months of preparation to make the integration safe. What would an inexperienced PM do in this situation? Ask to postpone the project? Escalate the issue? Extend the project duration? Ask management to revisit enterprise priorities?

As always, the best cure in such situations is communication. I spoke with another client company that had implemented a similar solution with the same vendor, and I learned that while it took them only four months to complete the integration, the actual time required afterward to adopt the new tool was a few more months. Now, what is that “adaptation”? It is the period required for the change champions to receive training, try the tool, configure it properly, establish the training program for all users, work on the support model, and finally get the tool ready for operations.

The key question then became: do we actually need the real-time production data anytime before the tool is fully transitioned to operations?

Then I spoke with the database teams, and I found out that they had DB replicas captured a few months earlier. Some of the data might be outdated, but it would still work for testing and training purposes. Which meant the integration could proceed with the existing replicas, with very minimal involvement from the database resources. The real-time data sources could be connected later, while training was still in progress. Of course, there were other factors to watch for, like database schemas following the upgrade, but those were manageable.

This is just one example, but imagine how many great initiatives are put on hold or rejected because decision-makers are too busy or too afraid to explore all the options.

Communication is the cure. Creativity is the key. This is why I love project management!