My secret to success in creating blog posts is to spend a couple of hours Googling variations of “project management [topic concept],” getting frustrated at the lack of quality articles, giving up for about a day, and browsing reputable news sites for something unrelated. A snazzy-looking article crops up, you read it, and you think, “Hey, this actually is a lot like what we’re learning about in class!” Fire up the ol’ word processor, channel your muse, and hey-presto, you’ve got yourself a topic!
This off-the-wall article I found in my search earlier this month is an unassuming little piece from BBC.com titled “Find it, fix it: solve it like a boss.” The content of the article is about what you’d expect, given the title. You learn about the struggles of a Microsoft executive in bridging a communications gap in his division, and how he concocted a process to right the ship. Some of the things the article shares with the reader include identifying a problem, seeking the optimal solution, planning for multiple outcomes, being ready for failure, making a tough decision, and using processes to find solutions.
Does that sound familiar to anyone?
I’m always fascinated by the things being positioned in media and journals as world-beating concepts. So much of what they come up with seem to be fairly fundamental concepts by MBA standards. I found this article to be no exception, but I thought it was really interesting to realize how interchangeable project management skills are with leadership skills. It was a bit of an Aha moment for me, and I think it might be one for you, too.
I Am A Rock – which is not always a good thing
Over the past couple of weeks, I’ve been paying especially close attention to the lessons taught by our illustrious professor. I mean, don’t get me wrong. The how’s and why’s of creating a project team, defining scope properly, and everything else we’ve learned is so crucial to having a strong project. But me, I like to think about what happens when things go wrong. The timing of this article and recent class content has been very interesting, given something I’m digging into at work.
For those of you who didn’t get a chance to read my original best-seller (M&A and Project Management, check it out at a computer or phone near you today!), one of the things that I’ve come to realize is that my company uses a matrix approach to project management. That’s driven in part by limited resources, in part by the pace of cultural development, and in part by high concentrations of SMEs. As such, the processes used in projects tend to vary, as do the results.
One project that was implemented this year was the adoption of a consolidation of all frozen purchases in the state of California into a hub-and-spoke model, which would service the rest of our continental US warehouse network. You see, shipping frozen products is an expensive and relatively risky endeavor, and when factoring in both the miles and the relatively small PO sizes, a shift to a hub-and-spoke model seems to be quite the layup.
Scarborough Fair(ly well botched)
Unfortunately, the project team was managed in cells and was heavily favored by our supply chain department. This resulted in a project moving all the way to implementation without feedback from critical groups, Pricing being one. The consensus was that general analysis showed the model to be favorable, and we were committing to not impacting our customers’ pricing during the implementation. Because due diligence didn’t take place, the pricing for both the initial inbound POs in California and the transfers to the spoke DCs in the East were never adjusted, driving a six-to-seven-figure variance impact to certain P/L lines. What’s worse, the fact that pricing wasn’t adjusted means that there is the potential to unknowingly pass through some of the variance on the project, which would leave the company with a six-figure hole short-term and some very uncomfortable conversations with our customers long-term.
Had the team taken their time and exploring the possible outcomes, this entire thing could have been managed within the scope of the project and been addressed accordingly. As it is, there is now a fairly real financial exposure, the need to correct the issues in the midst of heavy on-boarding and integration activity, and a fundamental question of whether or not the model will generate the same level of savings as it initially touted. There is no fallback plan in place, and for the moment a fairly uncomfortable shadow hangs over what was supposed to be a prominent accomplishment for the company.
Bridge Over Troubled Water
I stumbled upon this while doing entirely unrelated work last month, and I was able to frame it out in about an hour. If it was that easy for me, it should have been even easier for them to spot. But that’s the kind of stuff you miss when you’re looking to force a project through come hell or high water. Just like the article states, you need to take the time to consider all outcomes and plan for failure. You’ve got to slow it down, then all will be groovy.