Correct Solution for Incorrect Business Requirements
| Solution (Implementation) | Requirement (Specification) | Results |
| Incorrect | Correct | ? |
| Correct | Incorrect | ? |
Just as an incorrect solution to a business requirement cannot produce the desired results, a correct solution to an incorrect business requirement is also a waste.
Since many of the solution providers follow the notion “customer is always right”, they don’t bother to ask their customers the reason “why such solution is needed?”. There remains a possibility that a customer wants to solve a particular problem and as such engages a vendor to build / deliver a solution which s/he thinks is the only way out. The system integrator, who has technical expertise in the application(s) considered by customer, is involved and the story begins. Often the customers get to know the capabilities of solutions only after deployment when they start using the applications and by time they learn that the return on investment (ROI) is not as expected and as promised the supplier has already left the show, with clearance certificate.
Whom to blame? The vendor or the customer? I think “both”. What is your take on this?
If you are working on Buy or Sell side of the solution you may think it differently. To facilitate you in assessing the situation better, I’d refer you to the compliance terminology provided by The Open Group.
To illustrate, let’s say the customer required two features to be implemented, A and B. Here’s what you say of compliance, when you compare the specifications with implementation:
- If C and D are delivered, it is Irrelevant,
- If B and C are delivered, it is Consistent,
- If ONLY A or B is delivered, it is Compliant,
- If A, B, and C are delivered, it is Conformant,
- If A and B are delivered, it is Fully Conformant,
- If a and b are delivered, it is Non-Conformant.
Please share your thoughts.
Love this! It is so true. The customer NEVER tells you everything! I love the broken swing example. So the problem becomes expect to fail. Fail often, fail early. I'm not sure who that quote is from. It is so true.
Now we have some nice tools at our disposal. Build helps a lot. Straw models are good. Any drawing you make is not wasted. For me it is stick people.
And in the end it is both the vendor's and customer's fault. But the customer is always right, so unless you dig, it's the vendor's fault. 🙂
Michelle
Thank you Michelle Crapo for the reference. I had a quick look at the "Build" and think such tools can help in managing requirements and delivering solutions better.
I wonder if it's also a matter of the implementation approach used at the project? In the typical waterfall model, customers were usually engaged during the testing phase to provide confirmation on solutions meeting the business requirements and therefore both parties used to have conflicts on understanding of statement of need (SON). However, with agile, where fail but fail early approach is followed, it's relatively easy to know who's at fault.
You think? I personally wouldn't want to tell the customer they are wrong. I'd like to persuade them to my side. Telling them they are wrong? If it is an external customer - probably not unless it is the end of the project and it will cost your company money. 🙂
Faisal,
“Since many of the solution providers follow the notion “customer is always right”, they don’t bother to ask their customers the reason “why such solution is needed?”.”
E X A C T L Y, you nailed it.
I am from a Service based IT Company.All the things here get driven by timeline and money.Very rarely people spend time on brainstorming on ….
Is the requirement right ?
Is the Solution that we are going to deliver is right from a wholistic approach ?
People just jump and start working with a blind notion that ” Customer is always right ? ”
There are many more things that get added to the notion ” Customer is always right ? ” .
K.Kiran.
Thank you Kiran for your thoughts.
I have worked on both sides of the fence and as such understand the limits both the vendors and customers have.
The businesses engaged in delivering certain services argue “it’s customer’s responsibility to verify the requirements before hiring someone to build a solution”. They augment their point with valid reasoning stating “they were hired to deliver a solution they have expertise in, not to study & analyze business problems”.
On the other side some of the customers, in particular those who do not have any technical knowledge and are completely dependent & trust on their partner to deliver a solution, believe they have hired a solution provider to advise them on best course of action. They are not wrong either in their expectations.
I read somewhere that a well-written contract can’t achieve what a gentleman agreement can. So if both parties, the vendor and the customer, work hand in hand from beginning until end of a project, they can possibly reach to an acceptable conclusion.
How do you get them to look and understand the requirements. Usually they have a job other than working on the project.
I like your answer. It is a bit of both.
Michelle
Faisal,
“they were hired to deliver a solution they have expertise in, not to study & analyze business problems”.
Whoever has said as mentioned above, is fundamentally wrong.
One can claim expertise in delivering a solution only if he is capable of studying,analysing and then zeroing down the pros and cons.Without understanding the business how can we even arrive at a solution.Both goes hand in hand.
Brainstorming among the Technical,Functional and SME can help us in zeroing on the right approach.
May be we will get to see some more experts opinion too.
K.Kiran.
In fact, it depends on the level of the delivery engagement.
If it's a complete architecture design (or redesign), the vendors (specialized in specific off-the-shelf software products, such as SAP ERP) are involved to implement the solution while the options have been studied earlier by Enterprise Architecture organization to define business, information system, data and technology architectures prior to even exploring different products having potential to meet specific business requirements. Once a solution (such as SAP) has been selected, it's planned for implementation and project organization focuses on delivery, WITHOUT being responsible for the ORIGINAL architecture designed before.
In another scenario, where a solution has been implemented and a support organization (such as CCOE) is in place, troubleshooting the issues, managing design change requests, or working on new business requirements, vendors are sometime hired for specific work such as to implement a particular functionality within system. In such scenario, customer which is (both the internal IT and business owners) rightly expect the vendor to be able to understand all the requirements before committing to deliver a solution.
Your reference applies to the second scenario which is definitely correct. I was referring to the Architecture Development Method, detail of which can be seen at the Introduction to the ADM.
Thanks for your comments and hope to hear from others as well.
Thanks for sharing your thoughts.Nice blog indeed.
K.Kiran.
The customer may be right. You just need to question a lot more to get to what they really want. Then present the solution in a way they understand.
However, I am guilty of just working on the fix without questions. It's something we all have to remember - I guess.
MIchelle
I would not agree with the second: "a correct solution to an incorrect business requirement is also a waste"
as with agile method of transformation it can be - and i witnessed it in practice - that even in the case of wrong business requirements (as these are always in some extent wrong - as that is not possible to prescribe the result in great details like in construction business) - in the course of transformation organization is learning and correcting the course.
Because the business requirements are always somehow wrong we cannot and in fact don't use any waterfall method in business transformations. All method we use are agile - the thing is to institutionalize the change rather than do it ad-hoc.
Hi Waldemar Falinski
Thanks for taking time to read the article and to provide your feedback. While I understand and completely agree with the point you have made of Agile practice where "fail early and often" does lead to aligning the business requirements and the solution, I don't believe that in a project just the implementation partner could be held completely responsible, especially if the SON (statement of need) provided by customer is vague and can be interpreted in different ways, and that's what I meant.
To provide the context of our viewpoints, I've compiled our discussion in a blog at the link provided below:
SAP Projects – Avoiding Failures
I have highlighted the key points and copied part of our discussion to share the key learning that with Agile approach business requirements could be understood better and as such right solutions could be developed.