A large key part of business is communication. Part of communication is active listening and then paraphrasing back what you just heard so that you make sure you understood what was just communicated to you. Even when that part of communication is fulfilled, if you do not listen to what is not said and define the terms used, you run the risk of not understanding and getting the requirements wrong. And, if you do not clearly communicate back what you just heard or you leave something out, you run the risk of getting requirements wrong. Also, if you communicate back at a level different than your audience’s level of understanding, you not only run the risk of getting requirements wrong, you risk totally blowing it with them.
Unfortunately, I know firsthand that getting customer requirements wrong is costly. I’m going to take you back through my communication learning experience after college and to my first large customer experience. I’ll show you how I totally blew it on my first project with my first large customer. Hopefully, as you read this you will learn from the communication mistakes I made so that you will not make them.Communication matters! Getting customer requirements wrong is costly! Click To Tweet
Learning the Ropes
After graduating college and receiving a BS in Accounting, I got a job at a small accounting firm in a city away from where I grew up. I moved out of my parents’ house and into a studio apartment in a small town not far from the accounting firm. This was my very first true white-collar job working for someone other than myself. It was a huge learning experience for me being in a true office setting. The closest to a white-collar job I had been was when I worked at TG&Y as an assistant manager trainee yet I was primarily their stock-boy. At the accounting firm, I had my own desk, my own phone, and something rather new to small businesses at the time, an IBM PC connected to a local area network (LAN).
My main job at the accounting firm was to perform audits. My secondary functions were taking care of the PCs and Novell LAN. Also, part of my duties was to answer the general phone line when the receptionist was away. Becoming proficient on a 10 key (an accounting calculator) was by far easier for me to do than answer the general phone line. It was not like I had never used a telephone before. Also, it was not that I was not polite on the phone. The largest problem I had talking to our clients on the general phone line was that I at first was far too bluntly openly honest. For example, when the principle accountant and firm’s owner stepped out to go to the restroom, it did not occur to me to say; “I’m sorry, David is not available right now. May I take a message?” I instead, told it like it was; “I’m sorry, David is using the restroom. May I take a message?”
It was a thrill for me when David, gave me ownership to create the firm’s new client tracking database system using RBASE! RBASE was the first relational database program for the PC. At the time, I had not had any database experience let alone relational database experience. I knew Microsoft Excel and LOTUS 123 but no databases. So, I dove into the books that came with RBASE and all I could find at the library about relational databases. It was a regular occurrence for me to talk with and email RBASE support (including some whom unbeknown at the time a few years later I would work with at Microsoft).
Within a week, I had on paper the tables and relationships defined that were needed for the client tracking database. In two more weeks, I had a fully functional working beta developed. David, was impressed and very pleased with the results I made on the new client tracking database and of my much-improved phone manner. And, I had found a new interest and passion; databases!
Unexpectedly Changing Gears
Overnight however, things totally and dramatically changed. When I answered the phone, it was my brother Chris. He told me daddy was murdered. I was utterly devastated. I don’t remember hanging up the phone or driving to my daddy’s convenience store but I do remember skidding the car to a stop outside it. The police would not allow me in the store where daddy was murdered. So, I drove two more miles to console my mother.
Realization set in. My daddy’s gone. My momma could not run the store on her own. My brother Chris, had recently started his family and had been working on his banking career for a few years. Not wanting Chris, to hinder his banking career, I told David, that I could no longer work at the accounting firm. He understood as was very supportive.
I moved back in and lived with momma and I started managing the store full-time. The plan was to close the store once the underground fuel storage tanks could be removed. It took almost three years for all the paperwork required per government and EPA regulations was completed so that we could remove the underground fuel storage tanks.
During that time, per word-of-mouth and people seeing me around town and on the golf course, it got out that I was back. Which meant my computer skills started being requested. Throughout the day, I would work at the store. Then in the evenings and nights, I would fix PCs, recover hard drives, setup backup systems, develop database applications, program cash registers, and set up accounting software (mainly Peachtree), for my clients.
Larger and More Complex
Although I never advertised Classic Computer Assistance, by word-of-mouth I had as much “computer” work as I could handle. My schedule was full during those years, due to working fulltime at the store, my computer work, and playing golf. My momma would work at the store a few hours during the day and in those hours, I would go play golf at the local course. It was through playing golf that I got my largest client. My friend Randy, (who now prefers to be called, Randall), and I were playing golf together one day when told me that the company he was working in Quality Assurance needed a returned inventory database system.
Randall, set up the initial meeting between myself and the manager in charge of returned inventory. Prior to the initial meeting, I created a 25-page checklist and questionnaire that I would use to help ensure I asked the right questions during the meeting. After each question, I left room on the paper to write the answer. This project was the largest and most complex I had ever taken on and I did not want to mess up during the initial meeting and not get a chance to work on it. It was also going to be the largest paycheck for a single project that I had worked on.
The initial meeting went well and I got the contract to create the returned inventory database system. The checklist and questionnaire I had created prior to the initial meeting worked well and got me started. It gave me a lot of information and insight into what they were asking for in a returned inventory database system. My first focus was on getting the database schema designed and prototyped on the timeline agreed. The manager in charge of returned inventory had shown me a user interface (UI) he had and my next focus would be the UI for the returned inventory database system. The project was well underway and was proceeding rather quickly.
What They Asked For
The project was going well and it was ahead of schedule. Each meeting and discussion I had with the manager over returned inventory going over progress, would excite us both; thinking how the returned inventory database system would help product quality overall improve and lessen the likelihood of returns occurring in the first place. We both had high hopes for this project’s outcome. His plant manager was watching in hopes of being able to bring it to other plant locations and I was looking forward to implementing it in their other locations.
The manager over returned inventory had approved the database schema I designed and I developed it. The schema covered everything discussed. It handled everything from which department shipped the item, when the item was returned, why it was returned, who returned it, how it was returned; to where and when it was placed in the returned inventory warehouse and who placed it there, and more. From all the testing I had put into it, it was also rock solid and handled exceptions well. Quickly I put together a UI similar to the one the manager in charge of returned inventory had shown me. All set with all the files on 5.25″ floppy disks, off I went to deliver ahead of schedule the completed returned inventory database system.
Not What They Needed
As I installed and setup the returned inventory database system on my largest client’s computer to demo it, things went well. No glitches in getting it installed and setup to run. It started showing an opening screen largely displaying center screen their company name with mine as the developer much smaller and to the bottom right. Next came the main screen which showed a sample list of returned inventory items. Selecting one of the sample returned items, opened the information about the returned item captured, i.e., why, when, from whom, where it is now, etc. Going back to the main screen, I selected to enter a new returned item into the database.
Again, the system worked flawlessly just as I had designed and implemented. The manager over returned inventory was pleased with it and was eagerly awaiting to see what was to come next. To both his and my disappointment, what he was waiting to see come next, didn’t come at all.
What I had just delivered was what they asked for but, not what they needed. It “tracked” the returns but did not give any “report” about the returns. I had missed a primary component of what they needed in their returned inventory database system. They needed reports. Yet, I did not create any reports. Not even an on-screen report other than the main screen list of returned items (which wasn’t a report). By missing the primary reason they asked for a return inventory database system, I had just blown it with my largest customer to-date.
What I Learned from My First Large Customer
A communication breakdown was at fault for me getting the requirements wrong. During my first large customer project, I made a few communication mistakes. While I did repeat back what I had heard and used a checklist and questionnaire to keep track of what was asked for, I did not actively listen to what was implied and not directly said. Rather than paraphrase back, I almost always verbatim repeated back what they said.
The level of communication that I used with them was also at fault and helped lead to the communication breakdown and to me missing a key requirement. Instead of being on the same level of communication with them, it turned out that we were not. They were speaking at their business level using terms they were used to using and clearly understood. I was speaking at more of a software developer level using terms that overlapped their business level terms but having somewhat different meanings yet close enough for us to think we were all on the same page.
My first large customer had at each of our meetings said that they wanted to “track” their returned inventory in a database system. Thus, due to my communication breakdown, my understanding of what they needed was faulty and therefore I got the requirements wrong. If I had been actively listening, paraphrasing, and clarifying terms, I hopefully would have extracted their need for reports as an initial key requirement. Thankfully, they gave me more time to design and create the reports they needed. Since the mistake was mine in missing their key requirement per my communication breakdown, I did not charge them for the extra time it took me to design and create the reports.
What communication breakdown have you caused and what did you learn from it?
I have 20+ years at Microsoft (Office, O365, Windows, Windows Phone, Exchange, SQL, MSN, Bing, SharePoint, SharePoint Online, Xbox).
I have Project Management Professional (PMP), Certified ScrumMaster (CSM) and Six Sigma Black Belt certifications. And I aided the successful release of over 150 Microsoft software products and services.