Deliver Value to the Customer

Just like you don't want to loose any customer getting in business to you, no customer would like to loose a service provider who creates value for their business. Customer retention is all about Delivering Value to the customer. Sometimes it is about understanding and delivering what the customer has asked for, and sometimes it is about proactively figuring out what the customer needs and delivering the same.

 

Let me try to put  this together with a small example from the top of my head.

---

One of our customers had a BPM tool and they were integrating their product with multiple third-party CRM, ALM and SCM tools to push the product in the market. We signed the contract with the customer to integrate their product with a CRM tool. Before the project came to us, the customer’s product had already been integrated with a leading SCM tool and we had to start from that source base.

The customer had no requirements for creating a reusable design with respect to supporting multiple integrations. Somehow, the customer had carried an opinion that writing mostly independent code for different integrations will keep them in a better place to manage the code better in that he would have the flexibility to change one integration without worrying about the other integrations. So, we too didn’t carry this discussion forward as it was not the right time considering the facts  - 1. Our team too didn’t know what were the variables of the equation and 2. There was no proper working code as a base for the discussion.

 

Here is how we approached this problem:

 
• First, we focused on these variables:
• How the existing integration was working?
• How did we need to integrate the new tool?
• For the new integration work, we implemented the necessary design principles like reusability, abstraction, error-handling and fail-safe and other things which were not respected very well in the previous integration that was already done. The new integration started working well and another tool was added to the product’s integration chest.

(As a side note - Because of the way the code was organized, a few of these things, with minor efforts from our side, came as a bonus for the existing integration. Not every single task can be billed to the customer if you are really worried about Customer Delight and Customer Retention.)

• Following this, we had a discussion with the customer on the need for reusable and extensible design - now with some working code as a base, and it was the right time for the discussion. Technically also, we had understood what precisely were the design improvements to be made.
• We worked out the details and implemented a reusable architecture for integrating more tools with the customer’s product.

---

From technical point of view, this example is about identifying and weighing the design decisions based on what-to-do, when-to-do and why-to-do as we discussed in the post - Business-Driven OR Fact-Driven Design. The rule of ‘Don’t change the working code’ didn’t apply here considering the ‘Return on Investment’ if it is overruled.

 

From business point of view, it is about identifying what the customer needs and Delivering Value to the customer. Again, this project is not one of those fortune-turner kind of projects that we handled, yet it carried some business importance and for a service based vendor, unless there is a very strong reason, every customer is as important as the other customers.

 

The design improvement added a lot of business value to the customer that they could add more tools to their product’s integration chest much faster. It is about reduced-cost and faster requirement-to-implementation cycles. The business value for us was that the customer started signing more contracts with us. End of the day. the question “What is in it for me?” has to answered for all the stakeholders. :)



Does your team understand the customer's business enough to identify what the customer needs?

Do your team's decisions on the technical aspects, also consider the requirement of delivering business value to the customer?



(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Business-Driven OR Fact-Driven Design

It’s not always the technical reasons that drive the design decisions. More often, they are business based too. 'What design decision are you making' should also factor in 'When are you making the decision' and 'Why are you making the decision'. This is one of the areas where an experienced project manager or an architect can guide their technical teams in making those right decisions - means just right for the time and the context. This is what we can call as a Business-Driven-Design or a Fact-Driven-Design.

There are two extremes as far as our approach to design is concerned:

Piecemeal Approach - Not paying enough attention to design and writing code on a piecemeal basis. It can be due to lack of necessary technical expertise or due to high misinterpretation of the Lean Development concept and thus making it more leaner than it has to be.

[This leads to highly unmanageable and poor quality code and will have impact during and after the development cycle]

Best Design Approach - Trying to apply everything you learnt about 'Software Design' and 'Design Patterns'. Well, I was not an exception here. :)

[Possible under all imaginary and ideal conditions like - you have unlimited time OR you do everything right to the perfection the very first time. Practically, it is never possible.]

Common sense and business sense play their roles in coming up with a design that is ‘necessary and sufficient’ with reasonable trade-offs made. In other words, it is about the art of looking beyond your code. 'Trying for a right design at a wrong time or for a wrong reason may turn out to be more dangerous than a poor design.

What-to-do?

Invest in better design only if it is necessary and only when it satisfies the simple rule of ‘Return on Investment (RoI)’ .

For example, assume you are developing a tool for some kind of Tax Processing requirement, supporting two different Tax Implementations, say Sales Tax and Corporate Tax.

-- If you are sure that no other tax types will be added in future, do not try to get the best design in terms of abstractions and reusability. It is not necessary though technically right. Handle them with simple if-else logic wherever you can, after having just-sufficient abstractions and reusable code implemented.

-- On the other hand, if you know there are going to be multiple other tax types supported, handle them better in terms of design. It is technically right and necessary as well. Even, this helps you make right decisions on all other connected things like whether to use a radio button or a drop-down box for selecting the Tax type on the front-end.

When-to-do?

• Temporary trade-off

For example, if you are about to make a code drop and you have noticed a 'non-trivial but useful' design change to be made, do not handle this in haste. Your decision might be right, but not the time. Rather, push this to the next iteration, probably as a first things to do.

• Permanent trade-off

For example, if you are product based and your eye has caught a design improvement to be made right before a release, let the technical guy inside you sleep for some more time. You are too late, though you are right. The best design 'now' is the design that is already working. This is where ‘Don’t change working code’ makes sense.

[If the impact is significant but not severe (like a typical performance issue), it can be handled in a follow-up release.]

Why-to-do?
It is mixed with what-to-do and when-to-do.

-- Why do I need to design this way or that way?
-- What is the benefit for me or the impact on me during the development cycle? (Well, it is not about your performance appraisal and pay hike. :) )
-- What is the value/impact for the customer after the delivery?

If you don’t have enough time or enough data and you have to choose between 'better design' and ‘working code’, it makes perfect sense to prefer the latter. Spend the time you have for doing better things like - testing your code properly and fixing any potential bugs.

Are you making the right design decision (to-do or not-to-do) at the right time?


Are you considering the 'value proposition' in making the design decisions?






(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)