Communication - The Purchase Order Calculator

When you are a team of 1 working on a projects, most would assume that communication isn't necessary. I would argue differently. Even though I was a team of 1 on the Purchase Order Calculator (thread started last week here), I still needed to communicate with the "stakeholders" of the Project. A stakeholder is ANYONE who COULD be impacted by your project. In my case it was not just the Project Management Group, but also the Order Management group that created the POs. I think many a leader has learned to their chagrin that if you don't talk with stakeholders, your project will fail.

Now in my particular case, since I was working on this during my "down-time" I talked with the workers rather than the managers. I assumed (for once rightly) that it would be better to present a "finished" product to the managers rather than present a concept that would be rejected out of hand. I talked with a sample of 5 PMs and 5 OMs (roughly 1/4 the PMs and 1/3 the OMs) about how each of them created, tracked and validated the internal Purchase Orders. I also asked if they had any improvements they wanted to see. More often than not, this became a gripe session; but I still learned a lot about formats that would be best received, as well as the biggest questions and trouble areas. This new information  allowed me to refine the concept of the calculator, as well as design it in a way that people would actually use.

Now, although Communication is the 2nd C in C4, don't think that Communication is done after the initial interview. Communication (like all the other Cs) permeates throughout the leadership cycle. You need to constantly communicate. I would make a prototype, and give it to some "testers" who would comment. Those comments brought about tweaks to layout, programming (yes, I consider If/Then Functions in Excel programming!), and the initial presentations to the managers for use. Without Communication, this idea would have stayed on my computer, never seeing the light of day.

Over time, those 10 people became my beta-testers. Now, another lesson about communication: BE CAREFUL WHO YOU SHARE WITH. In this case, credit for my design wasn't stolen (although it was a very real concern). Something else happened. Something shocking. One of my beta-testers used the Calculator for about 2 days, then ran to her manager praising the thing at the top of her lungs. It still had some bugs to work out, and I wasn't ready to present it to the managers, but her enthusiasm basically blasted the "veil of secrecy" away from my project. The game was on now.

Photo credit: http://isobe.typepad.com/sketchpad/2004/05/post_1.html

I received a call at my desk from the manager in question, who asked me to stop by her office. When I got upstairs, I was shocked to see my Excel template open on her computer. Thankfully, before I could go into "panic" mode, she simply asked me to explain the calculator. Over the next hour, I found my caution evaporating and my enthusiasm building. That hour became a "practice session" for the pitch to other managers on my Calculator.  After that hour, the manager sent the spreadsheet to her entire team, with directions to use it for the next week and reply with any concerns or bugs. My beta-test went from 10 people to 30!

Thankfully, the calculator, while buggy, was usable. The most common plants for internal Purchase Orders were already in place and stress-tested. The bugs were more to do with small facilities without hard and fast rules for Purchase Order Values (this will be covered in the Complete section of this series). I did learn some valuable ways to tweak the Calculator so that it was more user friendly, and I refined my sales pitch. I also developed a core group of users who were enthusiastic for the amount of time the Calculator saved them. Overall a win-win!

So the next time you have a pet-project and you are the only one "working" on it, remember to think about "who" it impacts. Communication with them can bring about rapid change and progress. Failing to Communicate with them can cause project failure and wasted resources.

Next week: Command!