I have been working on a project for my primary client for some time. The project has far exceeded our initial estimates for time, and therefore, cost. The solution is very complex, very flexible and very solid. Unfortunately, sometimes that is not what the doctor ordered. I can’t reveal the name of the integration partner but let’s just say they are about the biggest name on the internet and they know it. We have two contacts at this partner who we communicate with. Let’s call them Wui and Suzi. Suzi is the contract representative and Wui is the technical contact. The partnership has been trying at best. Early on, we were sent a generic implementation document. This document described the protocol and interface, as well as provided example implementation. We reviewed the document, it was straight forward enough, and began proto-typing. From here the business representatives were working on contract language. Officially, they didn’t tell us to begin developing. When the contract was signed, however, they set a release date only a couple weeks out. This is when we met Wui and Suzi. Actually, we met Wui’s superior. He worked with us just long enough to tell us the first document was the wrong one, we weren’t allowed to use that protocol (even though it was 100% functional and integration development was complete and in compliance with this document). He provided us with a completely different implementation, a browser based system rather than a server based system, and insisted that we rewrite our entire application. Suzi kept saying, “its easy, it should only take you a couple of days.” At this point, I really didn’t have a feel for what was beginning. I made the assumption that the business sponsors on our side were handling the communication and expectations management with our new partner. Perhaps this is the first mistake I made. I implicitly trust and respect our business management but everyone can get busy and overlook a detail. It is the responsibility of everyone to understand the purpose of a project and the objective desired. Assuming anything without asking and verifying is a mistake. Next time, I won’t assume so much. As the project went on, Suzi repeatedly changed her mind, contradicted the documentation with new requirements, contradicted herself from email to phone conversation to conference call, and spun our development group in so many circles we lost track of what we were doing and why we were doing it. We eventually found ourselves in a position of complete surrender, conceding to every whim and fancy Suzi threw our way. Her companie’s product was not doing what she expected. We discovered limitations that prevented us from accomplishing thins she had written in the contract. It became apparent that she did not know here product. Perhaps she was new. Perhaps the product was still new to the partner. She was not the least bit apologetic when she had to place our efforts on hold while her technical team tried to fix the defects we’d uncovered. On the other hand, she became angry and frustrated at any inconvenience she might come across and made requests for colossal personal technical provisions. Debugging tools, convenience display settings, etc. These requests were actualized without contention and to a surpassed degree of quality. She once said, “oh, that’s good, nice job.” Golly, thanks. Each time a change was requested, usually in an email after reviewing the completed, ready to QA product, we would code the exceptions and alternate behavior. Ultimately, a very generic solution became a very complex implementation of a far evolved version of the original proposal. This is not inherently bad. Unfortunately, during the course of all these changes, the product implementation strayed from, and outright conflicted with, the implementation documentation published by the partner. What does this mean? It means that should they change their product in any slight way, we might become incompatible. A published interface and implementation document is a non-binding contract. It is an expectation device. Since we hacked and manipulated the partner’s product, at the partner representative’s insistence, we are no longer guaranteed it will continue to behave as it does today. I expect the partner to improve their product, fix the bugs we helped uncover, and add new features. When they do, I expect their previous interface to continue to work. I don’t, however, have much hope that our system will not croak and burp when they remove or change some of the undocumented features we exploited. So who will be responsible? On my end, that would be me. As a consultant, I should have taken a more prominent role on the technical details of this project early on. I was given a document and told to integrate it with our system. I assumed that the due diligence had been done prior to the project invocation. “Assume” puts an “Ass” in front of “U” and “Me”. Next time, and going forward with this partner, I will not assume. I will considerately gather the necessary functional details before I design and then code the system. That doesn’t mean get all the small details before a line of code, that means get the details in writing and clearly communicated. I had documents, I had confirmation, I had specific language verified. This is not enough. Some people have to be shown their dinner and smell it before they can decide. You can ask them twelve times if they really want their steak well-done and if they really want it smothered with steak sauce but unless you bring them the raw beef and say, “see, steak?” and then bring it to them half cooked and say, “see, not well-done” and then bring the steak sauce to their table and say, “see, steak sauce, pour on steak?” they will very likely get exactly what they asked for and say, “you idiot, you overcooked the meat and poured tomato sauce all over it and this looks nothing like fish!” I tried to manage this iteratively. With iterate development, the iterations must be small and each small milestone signed off. I communicated iteratively and developed like a waterfall. I am getting out of the waterfall business. I don’t mind requirements gathering, I love it. However, I now understand the touching and feeling is not the same and describing and looking at screen shots and spreadsheets. Just writing this all down has helped me get a step away from it to recognize some subtle but important shortcomings and failures. Failure is just a learning experience. However, it is also prudent to recognize when something is set up just to fall. The projects went live. It is working according to the many extednded requirements. Nonetheless, Suzi sent her comments. She has a myriad of complaints and issues. She is irritated that some things have changed since her last review. These are specifically the things she asked us to change. Further, she asked us to change a few things contrary to her previous instructions and our product manager attempted to accomodate her. He hard coded a dynamic variable value in a different location and turned off the user sensitive targeting mechanism. All of this through our content management system. Unfortuneately, this also turned off the user sensitive header tesxt and displayed only the configured title minus the context information (because he turned it off). She included, at the bottom of her email, a completely inappropirate, insulting, offensive jab that serves to only further our disdain for ever considering this venture. As I explained to the product manager: we learned some good things on this project that we can immediately apply to our other systems. That knowledge and proof of concept has been a win for us regardless of the outcome of this partnership. Based on this first run through with Suzi, I feel we should postpone any further interaction until the partner gets competent representatives and renders their product more stable, reliable and documented. As far as Suzi goes, I hope she finds peace someday. RIght now, she has many demons and she projects such a bad vibe, it spans thousands of miles and stinks up my office.