Previously our requirements analysis team interviewed the customers to figure out the changes they wanted implemented next year. They wrote down the customer’s business requirements. Then they developed system level requirements. I read one of these system requirements and could not figure out what they wanted. It was just vague. So I asked the requirements team what this was all about. They could only repeat the requirements verbatim. It seems they did not know what we were supposed to do. That did not help. So I scheduled a meeting with the customer. I asked them what we were doing for this requirement. I got an answer that I could understand. With that I ran and designed a solution. Then a developer took this design and implemented it.Today we finally got around to formally presenting our design to the customer. I reviewed the design for the requirement that I previously found vague. Immediately the customer piped up that this was not what they needed. They said that they initially sat down and explained their needs clear to our team. I confessed that I was not at that initial meeting. However I reminded customer that I received clarifications at a further meeting. The customer was adamant that the initial meeting explained all the things they needed. And this was not what we had implemented. Oh no. We are in trouble here.
So far we have tabled the discussions for another time. We need to get back with the customer to find out exactly what they need here. I am not sure if the customer is changing their mind a lot for this topic. Or perhaps they are getting tired of talking to different people at different times from our project. We need to get this right. I am going to propose that we write down exactly what the customer says they want. Then we need to verify that this is what they meant. Normally we delegate this customer interaction to the requirements team. However I am wondering if that is going to be a good idea this time around. We might need to send in somebody who is more familiar with the system.
