I was recently driving while listening intently to a radio program as a woman described her inability to survive each day without her Blackberry. I recalled how years earlier I was able to enjoy my twenty-seventh consecutive year of attending the first round of NCAA’s “March Madness” because I had implemented similar survival techniques and had email available at my fingertips.
This year I returned to the phone outlet and found my Blackberry to be far outdated. There were phones with a “bling” for this…and a “jingle” for that. These were electronic office assistants that also doubled as high quality cameras. Storage capacities were available that rivaled hardware ten times their size, perfect for catching that otherwise useless video moment. As if my favorite 250 songs weren’t enough, I had an option to carry them all. I was certain at some point I would be approached by a stranger asking if I might just have Tiny Tim’s, “Tiptoe Through the Tulips” available for immediate play.
I told the customer representative that I wanted him to recommend the “one phone” that was assured to give me the most capabilities and keep me on the cutting-edge until my next upgrade came around. His response left me feeling more embarrassed than satisfied as he stated that “any phone I bought would be outdated in a month”. I thought that if I waited until next month I would surely have the features I couldn’t have today. Sounded like good logic (to me). I was being taken-in by the bling; I found myself unable to discern what I did and did not need. Did I really need “10 Free Ringback Tones”…or the “High-Grade Resolution” upgrade? I had supposed that reading documents and email in crystal-clear clarity might be one way to justify the additional cost. I was considering the options and features that I wanted; but options that were not needed.
The same is true anytime one starts a new project. The most difficult challenge is to clearly define the project goal. A poorly-defined and ill-guided goal has about as much chance for success as somebody asking me if by chance I have some (Tiny Tim) music available.
Once the goal (or need) is defined and buy-in has been received by appropriate management, the path to success must be engineered. It becomes tempting to “grab a little this, and take a little that”, as the plan emerges. As technical resources assess the work to be performed, software features that are more for bling but accepted anyway may result in a project that exceeds the time and cost allotted. While it is important to build the best solution using the best possible approach, it isn’t always necessary to try and apply every feature available. It reminds me of the sign we often see at the head of the buffet line: “Take what you want, but eat what you take”. Applied to the role of a project manager, “use what you need, but need what you use.”
A few years ago a customer set out to redesign their company ERP along with recreating all B2B partner integrations…they would be taking advantage of new features that enabled enhanced capabilities. The existing ERP had been developed in-house but could no longer keep up with company growth. The new ERP would also be a “home-grown” type but would resolve the problems their old application had been unable to weather. Their high-level approach was to create a set of staging databases where EDI would be passed to a set of intermediate files – a sort of collection spot for the data. Design of the intermediate database was a critical component because not only would it be ‘written-to’, it would also be ‘read-from’…data needed to be easily accessible from other applications to include the new ERP.
It is common for EDI interfaces to carry a simple but sound “Header” and “Detail” approach, with a separate table for notes and comments. The development team proposed the new database design. It was approved and they set out to complete the project in six months. Partway into the work they decided it would be easier for large blocks of repeating EDI data (such as names and addresses) to also have a separate table. It was a doable change, having minimal impact on the cost and timeline.
As the “mapping” process commenced, the company realized features existed in the B2B integration platform making it possible to retrieve data from audit logs. While there was no clear understanding of how the audit data would be used, the company determined it to be a significant improvement and warranted a revisit of the database…a period of one week where a new database design would be assessed and would include the audit details. The approval was made and the redesign completed. Some mapping had to be reworked but only a couple of weeks were lost.
Work was well underway when another brainstorm led to the idea that since the integration product could ‘write’ data at any point, maybe “every EDI segment” should have its’ own table. Overkill for sure, but why not, since this system was to be in place for years to come. Sounded like good logic (to them). The timeline was pushed back by two months while the new database was developed.
Over time, the project did get completed, but only after many other changes were made. As the company sat back to look at what they had, their new database contained a group of audit tables, one table for each EDI segment, one column for every EDI element, and some extended comments so a user reviewing the database could understand the values that existed. After nearly a year, and tens of thousands of dollars spent, they had managed to produce a copy of the EDI data, minus the delimiters. A nightmare to say the least! They have since gone back to their old ERP while they assess starting over.
For this company, their eye was taken off their goal by the bling, and before they knew it they had paid for something they didn’t need and would never use. Know your goal and learn your capabilities. Remember, “Use what you need, but need what you use”…it will save your company time and money!