Dare to ask, Why?

Dare to ask, Why?

Has it ever happened to you while working on an Information Technology (IT) project that you’re dealing with a customer who needs careful handling with kids gloves? Or did you ever feel that the “customer” you’re dealing with is not an actual customer? Instead, a delegated intermediary acting on behalf of some other primary business process owner?

In other words, a cross-matrix technical development team now has an additional representative disguised as the customer making all the critical decisions on behalf of the real customer.

Let me be very clear in phrasing the context – the development team is getting secondhand requirements and bouncing solutions off with someone who may not have the full understanding of the intricacies of the business process that is being solved by the proposed IT project in question.

I am not referring to the cases where the representative is on the customers’ team. For example, a Director of Human Resource (HR) Department as a real customer asking one of the managers, who may be managing the Recruiting, to work with the development team on some IT project. In this case, the Manager of Recruiting is the client, even though the project funding might be coming from the Director’s budget. The situation I am referring to is different.

The context here is referring to a person or a group that is not on the direct chain of command of the business owner (i.e., the real customer). Instead, they are acting as a proxy for the customer, and would probably be saying to the customer, “We will help you with that? Don’t worry; we will get it done.”

The challenge here is that this is a delicate situation, where the real customer has an apparent trust in those intermediaries. After all, the customer delegated the responsibility over to the intermediary, at least that is the assumption. Consequently, I would always keep an open mind and would give these intermediaries benefit of a doubt that they have the business domain knowledge and the authority vested in them to make the critical decisions effectively.

However, among many things that can go wrong, one of the alarming risks is the opinions disguised or construed as the requirements that can act as initial cracks in the foundation of the product for which the development has not even begun yet!

Consider a conversation about how the systems and processes will interact, what would be the impact, what would be the relationships between the systems, etc. The intermediary customer opined, “we should add x number of additional columns, one-to-many or many-to-many relationships, etc.” One of the Project Managers (PM) recorded it, and a Senior Developer made a mental note of it that the comment made is a “requirement.”

If someone present at that discussion table (or on the conference call) did not dare to ask, “Why? What is the business case for that requirement? What exactly are you trying to achieve? How about we keep the conversation at the functional requirement level, let the development team review and propose a solution at a follow-up meeting?” the solution is imposed in the form of a fake prescriptive requirement, which most developers would take very seriously – after all, the “customer” asked for it.

Handle such customers and PMs with kids gloves. One must realize that not everything said is a requirement, and not every person’s opinion counts as a requirement. The Project Managers or Coordinators should be savvy enough to weed out the gossip or off the cuff remarks out of the meeting minutes – because they are documenting and recording a timeline, which turns into a virtual law for some stakeholders, including, but not limited to, the development team.

Let the process of follow-ups, feedback, checks, and balances cover such cases. At times the answer to this daunting problem is simple – just revisit the comment or the decision in a follow-up meeting or even in an email to question the validity of the ambiguous “requirement.”

Something like, “Hey, an interesting comment you made in the meeting that caught my attention, I was just wondering, …” Or any other flavor or style that may suit you to bring up the topic to get a complete understanding and full closure on it.

The development team is a partner, and believe it or not, the folks want (even may very well need!) guidance and feedback from the “expert” technical teams and architects. In other words, it is a responsibility of the development team to provide timely and rational feedback along with some proposed alternatives. Yes, at times they may say, “I hear you, but we want it the way we described,” which is fine. But if the reasoning is sound with supporting arguments and references, one would be surprised how many times they will happily accept the appropriate proposed version (maybe with a few minor tweaks).

Also, the folks need to acknowledge that there is no one-size fit all solution. The answer or the solution is always subjective dependent on various environmental and ad hoc characteristics of the situation at the client end. One of the biggest mistakes could be to rush to a conclusion that, “it worked for a previous client, the current client should not be any different.” Well, surprise! Each client and each customer is different, the degree of difference among clients may vary, but they all are different, indeed.

One may consider taking some time for open-minded analysis of all aspects of the expressed business needs, and respond back with questions and clarification on the assumptions made if any. In the process, consider keeping the following words as allies, like,“Why? Why not? What if? Does it matter?”

The idea is to trigger those gray cells, help folks think through and articulate what is critical and what is trivial, and above all, help people in authority make an informed decision because, in the end, that’s what matters.

Comments are closed.