Is it a culture thing?

Mark Aikman • October 14, 2019

How cultural fit between buyer and seller drives successful programme delivery

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!


May 9, 2025
Many companies initially believe they can handle complex ERP implementations internally. After all, who knows their business better? Grant du Preez of Ignition Transformation looks at what to consider before deciding to go it alone: and he’s a guy who’s seen all the elephant-traps. He advises:  Don’t underestimate how complicated it will be Enterprise Resource Planning implementations are challenging under normal circumstances. When layered onto major business transformations like carve-outs or mergers, they become exponentially more complex. These scenarios introduce unique challenges, such as: · Multiple legacy systems that must be harmonised · Interdependent business processes needing careful redesign · Data migration requiring deep technical expertise · Compressed timelines driven by business imperatives · Organisational resistance amid broader change And all that is needed simultaneously… At best you might see missed business opportunities if you can’t make the speed: at worst, you’ll spend too much or possibly even see a failed implementation. Remember Transition Service Agreements (TSAs) are real rules TSAs present some of the most significant challenges during carve-outs and acquisitions. These agreements typically impose strict and legally-binding deadlines for transitioning from parent company systems. There are substantial financial penalties for delays. Hard cash. To work within TSAs, you will need: · Proven strategies for meeting TSA deadlines · Templates for identifying and prioritising critical path items · Tactics for negotiating more favourable terms when necessary · Experience balancing short-term TSA requirements with long-term system needs It’s a Matterhorn-steep learning curve if you haven’t done it before. Make sure you have just one source of truth During business transformations, competing narratives inevitably emerge. Typically, there are strands on requirements, data structures, and implementation approaches. It soon becomes 3D chess. You will need to establish what we call a "single source of truth" – authoritative references for decisions that prevent revisiting settled issues. This includes: · Documented design decisions with clear ownership · Master data governance frameworks · Process models validated by business owners · Requirements traceability matrices Without this discipline, projects often circle Heathrow, cycling through the same decisions repeatedly, wasting valuable time and resources. You need to know what’s going on You will need complete transparency across all aspects of an ERP programme. Every day, you have to be in a position to give your stakeholders an unvarnished view of: · Project status against critical milestones · Resource allocation and utilisation · Emerging risks and mitigation strategies · Budget consumption and projections This transparency creates accountability and enables early intervention when issues arise. But it can’t be a hefty administrative burden that slows progress. Get the top corridor on board You will need to secure the right level of commitment from organisational leadership and key stakeholders. You will have to be clear about the specific involvement needed at different stages. Most importantly, you will need to be listened-to when you communicate these needs to busy executives. Executive steering committees, dedicated business process owners and carefully structured sign-off procedures will help ensure decisions are made by the right people at the right time. Without this orchestration, ERP implementations often stall waiting for critical decisions or proceed with insufficient business input. Remember DIY may only LOOK like the cheaper option Whilst engaging experienced consultants requires investment, the return is substantial. Looking at dozens of implementations we've led or observed, those with experienced consultants consistently: · Complete on time or with minimal delays · Stay closer to budgeted costs · Deliver more of the promised business benefits · Create less disruption to ongoing operations Organisations embarking on ERP transformations during carve-outs, mergers, or other significant business changes face a choice: invest in experienced guidance upfront or pay far more in delays, overruns, and missed opportunities later. DIY-er, beware!
May 7, 2025
Five questions to ask providers of business transformation programmes
By Mark Aikman November 7, 2022
How to write reports that busy people will read
By Mark Aikman March 7, 2022
Thanks to our good friends at Future Processing for inviting us to make a guest appearance! On their blog, I've shared some ideas about what to consider in order to get best-fit suppliers: https://www.future-processing.com/blog/selecting-a-supplier-natural-selection/
By Mark Aikman October 19, 2021
IT's supplier relationship need to stop using the master-servant model. Partnership gets more done - and to a much higher standard.
By Sharon Gregory September 7, 2021
Ideas for analysing and dealing with resistance to change in transformation programmes
By Mark Aikman August 10, 2021
Considerations when transitioning from development to BAU
By Mark Aikman July 20, 2021
Support for surviving and thriving after the pandemic from Ignition Transformation
By Mark Aikman July 8, 2021
Three different leadership styles to steer you through a crisis
By Mark Aikman July 1, 2021
How to have better and/or fewer meetings
Show More