How Can We Bridge the Gap Between Business and IT?

How Can We Bridge the Gap Between Business and IT?

#70. Dan Madden, a program manager at Acensus, asks, "What’s the best way to help bridge that gap between [IT and] the business and ultimately the end-users?"

In this episode, you'll learn about the five characteristics of Dynamics 365 and Power Platform projects that have a close relationship between business and IT so that there's no gap in your business applications initiatives.

Winning Agile Projects
Winning Agile Projects is a five-week program for 10 partner professionals involved in Dynamics 365 and Power Platform sales, pre-sales, practice leaders, architects and analysts that will help them qualify agile opportunities, pitch the benefits of an agile approach, create compelling agile proposals, estimate agile applications and write agile contracts. Apply today:

Support the show

Bridging the Gap between Business and IT 

Welcome to the Amazing Apps show -- for Microsoft Business Applications creators who want to build amazing applications that everyone will love.

Hi, I'm 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.

In this episode, we answer another listener question. This time it’s from Dan Madden who sent me this question:

“Hey Neil, how are you, this is Dan Madden, program manager at Ascensus. Love the podcast. Wanted to take the opportunity to field a question out with you. Basically, what I wanted to see is, our number one question about using an agile approach for business applications is: It’s really still largely an IT concept. It kinda falls on deaf ears in the business. I guess my question to you would be, ‘What’s the best way to help bridge that gap between [IT and] the business and ultimately the end-users?’ Thank you, keep sprinting.”

Thanks for your question, Dan.

How do we bridge the gap between IT and the business and our end-users when building Power Platform and Dynamics 365 apps?

I’ve been very fortunate to be involved in business applications projects for the last 12 years, since I’ve been using Scrum really, that have been led by senior business stakeholders where there hasn’t been a gap between business and IT.

That’s not to say that there hasn’t been some tension and that it’s all been a picture-perfect relationship like some made-for-television romantic comedies.

I hope all your projects have had a close relationship too, Dan. I going to give you the benefit of the doubt and assume that they have. So you’re asking this as a hypothetical question for the sake of our community or a ‘friend’ of yours.

Here are a couple of characteristics of the projects I’ve been involved with and the applications that we’ve built that have minimised the gap that has damaged so many others:

1.       Strong product ownership -- when we’re building business applications with an agile approach there has to be a strong product owner who has the full faith and trust of her leadership team to make the best decisions that will maximise the value of the application. That’s never been an IT leader or a contractor hired by IT. It’s always been a business leader. The seniority of the product owner is usually a reflection of the scale of the application. Building a Power App for a department needs a mid-level manager from within the department to act as product ownership. Deploying Dynamics 365 Finance & Operations to all business units worldwide will require a more senior leader from the finance department.

2.       Business sponsorship -- in my projects, the product owner has never been the project sponsor. The sponsor is the person, more often an executive committee, that makes the go/no-go decision and approves funding for the application. I don’t think business apps should be funded from the IT budget. If they are then the project sponsor is usually the CIO and that’s where the cracks between business and IT can begin to form.

3.       Product goal -- introduced formally into the 2020 Scrum Guide, the product goal should be a business-focused statement of the outcomes we’re expecting from the business application. If it mentions technologies APIs instead of the business’s KPIs then we’re in trouble. If it describes the benefits our end-users will get instead of our developers then we’re onto a winner.

4.       Stakeholder engagement -- I’ve found that there are two great opportunities to ensure our stakeholders are involved, and that’s backlog refinement and the sprint review. During backlog refinement we are uncovering the details about our end-users' requirements, so it makes perfect sense to have them in the room. I usually refer to them as subject matter experts and they are volunteers from across the business who care enough about solving the challenge that they invest the time to help us understand their requirements. The subject matter experts and any other business stakeholders who want to should also be invited to the sprint review. That’s their opportunity to provide feedback on our team’s progress towards the product goal and influence the product owner’s prioritisation of the product backlog before we beginning planning the next sprint. The best sprint reviews are led by the product owner rather than the developers or the scrum master. That’s another signal that this is a business project rather than an IT-led one. This level of stakeholder engagement should also extend into acceptance testers, change champions, data stewards and application trainers. It’s better if all these roles are staff by people who work in our business teams instead of the technology organisation.

5.       Claiming the credit -- when the project to build our new business application is successful, who gets the credit at the end of the day? If your product owner’s manager can announce that this project was a success because of the leadership provided by the product owner and the service provided by her partners in technology (whether that’s internal IT or your Microsoft partner team) that’s a clear sign you don’t have a gap. I want my Dynamics 365 and Power Platform projects to be an amazing professional experience for my developers who have become a high-performing agile team, but also for my product owner. In business projects our product owners are often first time product owners and I love to see them return to their business teams with an expanded understanding of the organisation, new leadership skills, and sometimes a promotion or new role within the organisation.

Dan, those are me five characteristics of my business applications projects where there has been a true partnership and no gap between the business and IT. 

You can get show notes for this episode at

I’d love to know what else you’ve seen that contributes to successful relationships in the delivery of amazing business applications. How do you ensure there’s no gap in your projects?

You can let me know by leaving a comment on the Amazing Applications company page on LinkedIn. Follow the page and you should get notified when the next episode is published, then scroll down until you see the post for this episode: Bridging the Gap between Business and IT and join in.

We’ve got a few more Q&A shows lined up for February and then I’ll be doing another season of interview shows with business apps builders just like you who have built amazing Dynamics 365 and Power Platform apps and they’ll be sharing their stories with so we can build on their success.

If you’ve got a story to share, visit

Until next time, as Dan Madden says, keep sprinting!