But what about when you are a team of one? This project, the Purchase Order Calculator, was really an effort of a team of one... or was it? There is never a team of "one," is there? In this endeavour, I had a team of testers as well as a team of support, not to mention the stakeholders (one of whom got a hold of the product early and it still exploded onto the "market"). I needed to be in Command of their actions and expectations, and when the situation changes, I needed to be in Command of myself enough to adjust my plan. An old saying is "No plan lasts past first contact." As leaders we need to be aware of this (probably a sub-section of Murphy's Law) dictum and be prepared to adjust fire accordingly.
In my case, Command started with a plan of how to move forward. I would concentrate on one piece at a time, creating stop points after each achievement to assess the level of success, whether it was a viable solution, and whether or not it was worth the effort to continue. I didn't realize it at the time, but basically, I was employing what is called Agile Project Management methodology. I started with a basic layout, deciding what information the user would have available immediately, preferably from one source. Then moved into what that information could tell the calculator. From that point, things started getting complicated. Because each plant had a different rule, the calculations would be different for each. After the calculations were determined, then would be "in house" testing, followed by beta testing, and finishing with a release to managers. Each step would have a stop point to determine lessons learned, as well as a review with a couple of "stakeholders" who might have input. The stakeholders were other Project Managers who would benefit from the calculator, but didn't have the inclination or the motivation to actually create a system on their own (they would love to use it, however!).
The first step, determining the source, turned out to be easy: our Cost Price Analysis (CPA) spreadsheet. The CPA at our company is compiled by the Sales staff and tells anyone who has it what the expected cost for the project is, what the sale price is, and where the equipment will be built. This information is the basis for the Purchase Order decisions of the Calculator.
Once I determined the source, the next step was building a way to determine which calculation would be used. The key indicator here was the location. Once the user entered the location where the equipment was built, the calculator would know which rule to apply. I'll admit it wasn't an elegant solution, but I figured out how to write a series of layered "If" functions in excel to determine the rule based on the value selected from a pull down menu. Getting this step right was difficult, and I will freely admit that there was probably a better way to do it. But it works, so that step was closed.
The next stop point was after I wrote out the actual rules used for each location, and pointed the location calculation to the appropriate cells with the rules. In some cases this was easy. Many facilities were at cost, so the value was similar to "J2=C2." In other words, the value of the purchase order (Cell J2) is equal to the cost provided by the CPA (input in Cell C2). See... EASY!
What wasn't easy were the plants that applied a discount to the purchase order based on the margin of sale for that piece of equipment. How do you write a function that determines the PO price is equal to sale price if the Margin is 0-10%: but is Sale Price - 15% if the margin is more than 40%? NIGHTMARE. Eventually I went back to the "If" statements used to determine locations in order to get the calculations correct. Again, not elegant, but it got the job done.
Now was the opportunity for "in house" testing. I used the calculator at work for about 2 weeks, and confirmed my PO amounts the old way. I would then hand the values over to an Order Manager, and ask her to confirm my values were correct. She didn't know it, but she was helping me validate the calculator. I guess this made her a blind quality control for the calculator. I even went to a series of old POs that were causing arguments and used the calculator on them. When the results from the calculator were accepted by both OM and the constructing plant, I knew I had a winner ready for beta-testing.
So, this is often the hardest part of a project, releasing it into the wild. I needed to see what flaws there were, and I think we can all admit that a developer tends to have blind spots that he/she doesn't know exists. In this case, the test group was the "steering committee" along with a couple of Order Managers I trusted. If you want to know the results of that, see my last blog entry on Communication!
Finally, the item was released to the regular users, and was well received! Of course there were suggestions and tweaks, but that is only to be expected. After all, everyone has personal preferences they would rather work towards. However, the calculations were sound and the arguments between plants and order managers drastically reduced.
un-usable, and my effort and time would be wasted! No leader wants this.
So, what is Command? Command is the formation of the plan, and the execution of it. Whether the team is 1 person, or 100, this is Command at it's most basic. But the plan needs to be fluid (one of the advantages of Agile), because, as mentioned earlier, no plan lasts past first contact!
DoD photo by Gunnery Sgt. Robert K. Blankenship, U.S. Marine Corps. (Released)
No comments:
Post a Comment