Have you ever dealt with a customer that is always dissatisfied with your results? In other words: you thought you’d done great work, maybe even got positive feedback from your customer’s counterparts only to eventually find that the results you’ve provided them with are below their expectations. „What the hell” – you think – „They’d agreed on the required specification and now when the system is ready, they’re telling us everything is wrong? What kind of games are they playing with us?!”

 

Headless eCommerce - Download FREE Book

 

Few years ago, while writing down our processes at Divante, we created a model for cooperation with customers. This simple roles-based model had worked well for us. It hadn’t been a new thing – we’d used it for 6 years until that moment!

We used to work in accordance with the following configuration of project stakeholders:

  • Product Owner – single contact point on customer’s side; person to gather and verify all the requirements (along with our analysts of course); the one to make the decisions,
  • Project Manager – PO counterpart on our side; person eventually responsible for all the results and schedule, budget,
  • The Team – developers, analysts, team leader …

This is a kind of reality simplification. We’re using SCRUM – so we were far from roles described in PRINCE2, PMI and other methodologies. We tried to be Agile – and it worked.

 

agile

But then, when we started cooperating with larger and larger enterprises – let’s say – the TOP 10 Polish Retailers – we encountered problems. I recall a few situations that should draw a picture of the kind of difficulties we were trapped in:

Product owner negotiated and agreed upon unrealistic deadlines or scopes internally in his company. Despite our recommendations („Please don’t promise this, you’ll set us on a land-mine!”).

Immediately after this situation I started to hear comments like: „Divante never delivers on time” from the company CEO; and this opinion caused tremendous issues for our overall cooperation.

Product owner agreed upon mockups / requirements that we’d eventually implemented … Only to discover that business users are dissatisfied with. Then what we’d heard about our work was: „Divante’s product (PIM – in this case) is hard to use!”, „What is that!? How can we use this on production!” started to be heard.

During the UATs – there were some quarrels started between business. I mean – like discussing opposed requirements – even things we’d first heard of during those meetings.

Our simplified model didn’t cover two very important roles that we, as the vendor, should reach out to:

  • Business Owner / Sponsor – CxO (maybe CEO) – somebody who pays us for the project,
  • Business User – end user of software we’re to deliver.

Business Owners (BO) are mostly focused on the schedule and budget. Not wondering which features will be included in the project. They are not the ones to discuss details or the problems within.

Unfortunately what I’ve observed is that the Product Owners (the detail guys) aren’t providing the BO with information and estimates as often as it’s needed. Their focus on the product itself was eventually harmful due to information gaps including critical information like budget and deadlines. Sure – we can design and build the best system ever but when it exceeds the budget, none of it matters.

What is also interesting is that the BO often doesn’t know if the system we provided them with is „OK”, or if it only „fulfills his requirements”. They might not even know what the requirements actually are. He relies on his people so …

… you rely on them to make decisions and reach a consensus. The Product Owner is sometimes unable or hasn’t got the power to consolidate the Business Users expectations. He also simplifies reality. This simplification can cause huge issues, specially when working with an unlimited budget.

Business Users have strongly opposite needs and what’s important they are not the tech guys. So you have to sit them down in the room, show them something they can visualize / understand. Like mockups and maybe user stories. They will probably have no time to work with you. Because they are in the ongoing business – but they have to find the time. Discuss it with their CEO if it’s needed. And make them to accept the requirements and the project before writing single line of code. Maybe sounds easy but in reality: it isn’t :)

coding

Everything became simpler when we realized those two truths.

What we changed?

  • Firstly, the Project Manager has to think about the goals and motivations of the Business Owner and create a RACI diagram (which person to inform, who is responsible for decision making, who should be consulted with) – in order to have a better understanding of the business environment.
  • Next we try to make the most detailed analysis we are capable of – working in SCRUM is easy to over-simplify this step – don’t do this when working with Enterprises. In order to be understood by business users, you should use techniques like mockups and user stories because more technical information won’t be understood and probably won’t be easily accepted.
  • Then we plan Steering Committee meetings (yeah! Like in PRINCE2) to keep the Business Owner informed – we focus on budget, deadline, changes.
  • At the end of the project we plan tests with business users – along with our employees and then we hold a „Piloting” stage where the production version is used by a limited number of end users.
  • Finally, armed with feedback, we are able to tailor the product to the high demands of the end users.

 

Manage your content across all customer touchpoints with Pimcore >

 

Business always requires results especially within the schedule and the budget. The real value is in providing users with working, finished products which meet their needs. This is the business value we believe in, above all, at Divante.

Read also: There are no shortcuts. What you don’t know about negotiations.