Have You Ever Fired a Client?

Have you ever wanted to fire a client or maybe a partner? Have you ever actually done it? I feel terrible. I fired a client this week.

Welcome to Amazing Apps Applications, the podcast for Microsoft business applications makers who want to build amazing applications that everyone will love. Hi, I'm your host, Microsoft Business Applications MVP Neil Benson, and my goal on this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power Platform applications.

This week, I had to call a friend of mine at Microsoft, who had introduced me to one of his clients, and let them know that I wasn't going to be able to help them. Then I had to call the client and do the same thing. I felt sick to my stomach, wishing I'd been able to deliver a better outcome for the Microsoft customer and the partner they're working with, but somehow relieved and glad that I stuck to my principles. Stick with me and I'll tell you what happened.

Congratulations to two more Customery Academy students who completed my Scrum for Microsoft Business Apps course and achieved their Professional Scrum Master certification assessment with Scrum.org. Lars Rensinghoff, Head of CRM at connectiv! eSolutions from Munster in Germany, and David Ruston, a freelance ERP project manager and scrum master from Hythe in the U.K. Well done to both of you.

OK, let's get on with the show.

Some Microsoft partners have a standard approach to implementing business applications. They describe that approach in their proposals and sometimes even give it a name and highlight it on their website and in there and in their marketing collateral. It's often a hybrid approach that combines that some waterfall elements, such as upfront analysis with almost all the testing done at the end of the project. In between, there are some areas of development that includes some periodic demonstrations of what the development team has been working on, they might call those showcases. They might even use agile sounding terms such as 'user stories' and 'sprints', but often it's an agile veneer on a classic, traditional approach.

There's no agile mindset involved. There's no understanding of empiricism or the principles of the agile manifesto that are still project managers assigning tasks and requirements, specifications to be signed and change requests to be paid for the desire for this kind of hybrid approach. It's probably not that it actually works very often, but more likely that it's never really offensive. What clients won't reject a proposal that looks like it's got all the best bits of a traditional approach and an agile approach, but it's mediocre and bland. It's the magnolia paint of how to implement a business application.

A few Microsoft partners are still clinging on to Dynamics SureStep the implementation methodology that Microsoft launched in 2008 and retired in 2012. But most of those partners are, thankfully for their customers, fading away into obscurity.

A few more modern Microsoft partners have embraced an agile approach. Illuminance Solutions in Australia uses Scrum and so do many others.

Some partners have invented their own lightweight implementation framework, which I guess is better than a waterfall approach, but if you invent your own approach, you're going to have to teach it to everyone in your organization and educate your clients about it. And you're not going to be able to hire anybody with pre-existing certifications or experience in it.

If you're going to adopt an agile approach, I recommend using an industry-standard like Scrum, SAFe or Kanban because those are widely available. You can hire people who already have the skills and experience. There are training courses and certifications available. And importantly, your clients may already be familiar with those approaches.

Unfortunately, there are still a few clients looking for a fixed-scope, fixed-price implementation. They do this primarily because it shifts all of the risk onto the systems integrator. If the project goes over budget, the client won't have to pay for the overrun. The fixed-scope, fixed-price implementation is based on that assumption that we can define every requirement upfront and those requirements won't change. 

Of course, they do change. They change a lot.

Users only realize what they want when you demonstrate a feature that isn't quite what they want. So we have to pay project managers to raise change requests to extract more money from the client. Think of change requests as a tax for changing your mind or not really knowing what you wanted in the first place.

I've seen this play out over and over again, especially in public services and especially in Australia.

This week, another multimillion-dollar SAP project at Queensland Health was delivered late, delivered badly and went over budget. The new finance system designed to consolidate orders and keep down the costs of hospital supplies to Queensland's hospitals resulted in $540 million of unpaid vendor invoices. I'd be really surprised if Queensland Health is getting the best possible prices from its suppliers who've got $540 million of unpaid invoices outstanding.

Ten years ago, Queensland Health had one of the biggest project failures ever, a $6 million payroll upgrade project cost $1.25 BILLION before it was cancelled and the entire project was scrapped. That's a $6 million project with $1,119 million of change requests layered on top! Some commentators reckoned there was no bigger failure in public administration until 2020's handling of the bushfires ravaged an area of Australia nearly the size of Ireland.

Queensland Health's payroll upgrade caused tens of thousands of payroll mistakes that cost hundreds of millions of dollars to rectify the inquiry into the disaster cost $5 million, which was nearly as much as the original project. The inquiry was damning of the procurement process and the negotiated settlement the state government made with the systems integrator. When a new state government was elected shortly afterwards, they unsuccessfully tried to sue the systems integrator, and the government had to pay even more money for legal fees for the failed lawsuit.

Staying closer to home and bringing it back to Microsoft Business Applications. I recently had a client that asked for my advisory services to help them launch two projects. One to deploy Dynamics 365 Field Service and another to build a custom Power App. We kicked off both projects with user story mapping exercises to help the client's teams visualize the scope, stakeholders, timeline, priorities and costs of their applications. The story map for the field service project illustrated what features would be ready in an initial release after six two-week sprints just before the end of the year and in subsequent releases over the next few months.

The client engaged a Microsoft partner to help them build the application. Getting the partner on board was taking longer than expected, and we didn't want to waste any more time, so we started sprint 1 with a couple of internal team members who plan to complete one or two of the highest value user stories.

When it came to sprint 2, the partner's team joined our sprint planning call, but they let us know that they still hadn't finalized contract negotiations and they were expected to do that in the next couple of days once the contract was in place. They'd spend one sprint specifying the client's user stories in sufficient detail that their offshore team could develop them, and getting those stories approved in writing before spending the second sprint designing the features. That left them three 'build' sprints before there'd be two more 'testing' sprints and something ready to release into production.

My heart sank.

Here was a Microsoft partner using words like 'user stories' and 'sprints' without any real appreciation of what it means to be agile. And this was coming from probably the largest Microsoft partner in the world and one of the largest systems integrators worldwide. I'd hoped for much better from an organization of that size. But it seems I was deluding myself that I could coach them and the client into an agile approach using Scrum, and that we'd be able to build an amazing field service application before the end of the year.

It turns out that the client's procurement team had insisted that the partner present a fixed-scope, fixed-price statement of work. The partner's natural reaction was to spend four weeks specifying the requirements upfront. You need a nailed down scope, especially if you're expecting to raise lots of change requests later.

If the partner had been able to start the project when the client's team were able to start the project, that would have left just six weeks to configure the field service features. But because the contract took longer than expected to agree two weeks of development time was lost and there's only going to be four weeks of development instead. Contrast that with the 12 weeks of agile software development we could have had if we'd used Scrum. Six sprints of analysis, development, testing and deployment of valuable features. No time or money wasted on requirement specifications, change requests and approvals.

One of the biggest principles in the Agile manifesto is customer collaboration over contract negotiation. But in this case, the customer seemed to prefer a contract negotiation over collaborating with their Microsoft partner.

Unfortunately, I had to step out. Last week, I let the customer know that my expertise is in helping Microsoft customers build amazing applications using an agile approach. Their procurement approach conflicts with the outcomes that their business unit wanted. And I wasn't going to be able to add any value in the middle of all of that. It's one thing for me as a business owner to decide which customers and partners I want to work with.

It breaks my heart to have to walk away, to have to fire a client. That's much harder to do when you're part of a large Microsoft partner organization with revenue and utilization pressures. I was in that position when I led the customer engagement team for a big four audit firm and there were several opportunities I was instructed to bid for, even though the client was insisting upon a waterfall approach that clashed with my preferred way of doing it: to use Scrum. I just wish more Microsoft partners were able to modernize their approach and to walk away from customers that insist on fixed-price, fixed-scope projects.

Those projects rarely deliver amazing outcomes testimonials, case studies or rewarding professional experiences for the project teams involved.

Here's my call to action for you. If you're a Microsoft business apps maker at a Microsoft partner. Ask your manager if you, your delivery team and maybe even your sales team can explore Scrum together. (It doesn't have to be Scrum, but three-quarters of agile teams happen to use Scrum). If your manager says "No", well, maybe you need to consider your career choices wisely. Do you want to work on projects that enjoy contract negotiation over collaboration? Where you spend more time specifying requirements than you do building features? And where project managers are constantly looking for change request opportunities to recover some profitability for your services? 

There's a growing number of Microsoft business application partners out there embracing modern, agile approaches. If you work for one of them, I'd love to hear about it. Let me know in the comments on the Amazing Apps show page on LinkedIn. I'd love to help you spread the word.

If you're a Microsoft customer, consider your Dynamics 365 or Power Platform project as an opportunity to try an agile approach. Find a Microsoft partner that's practising Scrum.

And if your procurement policies demand a contract with fixed-scope and fixed-fee, then brace yourself for change requests.

As always, if you're interested in exploring an agile approach for Microsoft business applications projects, you're welcome to join my free mini-course. It's called Agile Foundations for Microsoft Business Apps. In less than an hour, you'll have a solid understanding of why it's nearly impossible to define requirements upfront. And you'll know the basics and benefits of Scrum for partners and customers. You can join for free at customery.com/foundations.

Some of you might have thought about firing your client or maybe as a Microsoft customer, maybe you've thought about firing your partner. Let me know on LinkedIn, but let's keep the names redacted and keep ourselves out of trouble, please. Thanks for joining me in this episode. I really appreciate you and all the feedback I get about the show. Keep it coming. I'll see you next time. Until then, keep sprinting. Bye for now.