CHOW # 202 – The challenge of too many layers between development and the business users

Indus Mercantile bank is your customer headquartered in Delhi. Garima is their Director of IT based in Delhi. You are the Project Manager responsible for delivering a Compliance and Enterprise Risk Management solution for them. You need to work with a Partner, Global Solutions, to deliver this solution. The Partner will work with customer’s IT to get requirements and you deliver based on the requirements document provided by your Partner.

Your first delivery (an incremental delivery of features) is ready after 2 months and as you go through the Show and Tell (demo) session, you realize that a lot of business users who are present are not happy with what has been delivered. You know that you have delivered as per the specifications provided to you by Global Solutions but realize that the end users were perhaps not involved in the requirements process as they should have been. You are caught in a situation where you are dealing with the end users while two interfaces in between – the Partner and the customer IT team – who should be dealing with the questions and concerns from the end users – are both watching helplessly.  Garima who is present in the meeting, closes the Show and Tell session assuring the business users a better product soon.

What should your approach be in this situation?

Suggested Solution

Before anything else, you need to understand what the business users were unhappy with. If you believe the software was delivered as per requirements, the gaps with respect to expectations happened perhaps in the detail – for example the user experience etc. You need to understand the reasons before you start addressing the problem.

The other question in this situation is what was the role of business users in defining requirements initially. It does look like the customer IT team and the Partner worked together to define the requirements without involving the users as much as they needed to.

This is also a classic case of too many layers between development and the users with some layers adding very little value – perhaps the customer IT team in this case. Even the role of the Partner is suspect as they are not taking responsibility for what they need to do – which is to truly represent the business users in this case.

So, before you proceed with further changes or development there are some things that need to be done:

  1. What the S and T has revealed may be only the tip of the iceberg. A review of the rest of the specs and understanding of the gaps with respect to expectations may be warranted.
  2. Clarify the roles of the different organizations involved – if business users are going to accept the software, they need to be involved in the requirements. And you may want to ensure, as the final provider, access to end users to understand their expectations. Alternately, you need to ensure there is an equivalent of an Agile PO role who would be the ultimate authority to decide on requirements and accept the software – it may be your Partner but this role needs to be taken seriously.
  3. You may want to consider iterative delivery moving forward – get requirements prioritized and deliver in shorter increments so you get early and continuous feedback.
  4. You may want to re-visit your SoW/contract, especially if you are working on a fixed price engagement, to ensure appropriate clarity and mutual understanding of roles, responsibilities, expectations as well as the way you will deliver and the way the software will get accepted.


What do you think?

Leave a Reply

What to read next