Is it a culture thing?

At the recent CIO Watercooler LIVE in Leeds event, delegates enjoyed a discussion on how to maximise the relationship between a client and a development provider. CIO Mark Aikman and Future Processing’s Michal Sztanga outlined their experiences and gave their insights – which were sometimes quite radical for our industry - into how a true partnering relationship can work brilliantly. Here’s an extract from the debate:

Michal, what do you believe are the key skills and behaviours needed in a development supplier?

 Michal Sztanga:  I think the first skill is to listen. Taking time to listen to what the client wants – and perhaps even more importantly, how the client wants that delivered - is essential.

 It’s self-defeating to offer your existing solutions too early, without fully understanding the need and the client’s cultural context: that’s simplistic and not credible for the client. So I’d advise listening first and having the skills to ask the right questions. This allows you to then respond to the client’s favourite methodology, the size of their team, or their choice of engagement and pricing models. For me, the provider’s goal is to adjust to the client’s business, not the other way around.

 Mark, what’s your experience in commissioning development work?

 Mark Aikman: The whole spectrum! I’ve used in-house, UK-based suppliers; long-distance offshore; and near-shore.   I’ve worked with Future Processing as a UK CIO, based in England, with them working out of Poland.  For me, it doesn’t really matter where the development team is sitting - it can be anywhere in the world. All I’m looking for is the peace of mind that the project will be delivered on time, right first time. I got that from Future Processing. 

 The working relationship with them was extremely effective, for a number of reasons, such as the good fit with time zones and the ease of travel when needed… but mainly, it was the good cultural fit.   I needed a supplier that understood the urgency of the programme’s deadlines and could demonstrate the exact same work ethic as my own team. I needed people who took time to truly understand what we needed; tell us honestly what was and was not achievable in the time we had; and would think creatively to solve some of our problems. We even ran the project using hybrid teams, combining in-house and Future Processing specialists taking shared responsibility for delivering programme themes.

 I believe the client should perceive him or herself to be making the problem statement and then listening to potential solutions. The client’s role is not to own all the ideas for solutions and requirements. Solutions should come in collaborative partnership between vendor and client.

 Michal, that sounds like a relationship that’s really beneficial – but perhaps tricky to establish. How does a development provider go about building this kind of partnering relationship?

 Michal Sztanga: Yes, it’s not always easy at the beginning! The supplier needs to gain the client’s trust. We find that will not in fact happen if we simply follow the traditional industry practice of agreeing with everything the client says! Instead, we question and listen and we dare to challenge the client’s assumptions or false expectations. That sounds a long way from collaboration, but it’s the style in which we do it that makes it acceptable.

 For example, with Mark, we held a week-long workshop at our offices in Poland as the first activity of the programme. This really intensive form of communication helped us get under the skin of the requirements and build enough of a relationship for trust to begin to build.

 We are always open and honest. If it can’t be done, or we can’t do it, we will say so. If we have made a mistake, we will immediately own up. Whilst this might sometimes seem to be bad news for the client in the short term, in the longer term, it genuinely builds trust. Because of our transparency, the client believes that he or she is truly in the picture, that there’s nothing been hidden that might emerge later and prove to be disastrous. The client will often then relax and become very open to our recommendations and ideas.

 We recognise very quickly if a client is not for us – or we are not for the client. If the client doesn’t agree with the “we’re all in this together” concept, it isn’t going to be a success.  We know that it’s necessary to be brave enough to end such a relationship very early, rather than hope for a cultural change. That’s not realistic, and unfair on that client.

 Mark, this positive style of relationship is great up to a point, but how does the client retain programme leadership?

 Mark Aikman: Good governance arrangements. I agree that mission creep might be tempting, if everyone involved gets excited by what we could do, rather than what we should do. To that end, I’d suggest using rigorous governance.

 For example, I would typically set up a governance group comprising me, the programme sponsor and the executive sponsor. We’d meet weekly to assess progress against global and phase objectives. This way, the commissioning business is fully appraised of progress – and difficulties – at all times. And people who sit outside the day-to-day actions of the project, retaining objectivity, are able to challenge any flights of fancy.

 So, to summarise, what would you say are the key features of a collaborative relationship between IT developers and the client?  

  Michal Sztanga:  I’d say it’s open and transparent communication. Often when it comes to challenges and problems during development, companies are afraid to play with open cards, but in fact true and open conversation about even the hardest issues are the building blocks of successful business. 

 It's not the only way to go, but it’s our way. We consider it valuable and encourage the market to act that way, focusing on culture in order to achieve success in delivery. This brings value even if in some cases there are uncomfortable moments!  

 Mark Aikman: I agree – I'd also add that I think that the gold dust for every client is to very quickly develop a trusting relationship, based on the absence of flannel, then sustain it throughout the whole programme. 

 Sharing and being open to other people’s ideas will only add to the success of your programme. The client does not have all the answers – or even all the problem statements! And if the vendor has taken pains to listen to you, then you need to listen back!