6 Roles Every Enterprise Business Applications Project Should Have

What does the structure of a scales business application project look like? What groups and roles do you need when you've got 50 or more team members working together for a year or more to build a large, complex application?

In this episode, you'll learn about a model project structure so that you can compare it to yours or use as a baseline when establishing your own enterprise project team.

Resources

• 6 Roles Every Enterprise Business Applications Project Should Have poster

• Large-scale Scrum (affiliate link)

• Nexus Framework for Scaling Scrum (affiliate link)

• Scaling Done Right (affiliate link)

Support the show (https://www.patreon.com/amazingapps)

Transcript

Welcome to the Amazing Apps show -- the podcast people who want to build amazing, agile Microsoft Business Applications that everyone will love.

Hi, I'm your host Neil Benson. I’ve been a Microsoft Business Applications MVP since 2010 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.

Welcome to another Q&A episode. One of my agile coaching clients recently asked me about the structure they should have for an enterprise project to build a Dynamics 365 application for an international not-for-profit organisation.

In this episode, I’m going to describe a model structure for an enterprise business applications project to implement Dynamics 365 or Power Platform Applications. This is based on my last five years’ experience working on two large-scale projects to build business applications that are used across the enterprise and where the project team is 50 or more people, the projects have lasted a couple of years and tens of millions of dollars have been invested.

Of course, not every business apps project reaches that kind of scale, but these enterprise projects present special scaling challenges you might not find in smaller projects.

I get asked a lot about smaller projects. In particular, how to apply Scrum to very small projects where a small team of people is building an application in a few months. We’ll tackle that in a future episode, but for now, let’s return to the enterprise project question.

I’d like to emphasise that I’m not recommending this structure for your project. If you’re practising an empirical approach then you know that it’s almost impossible to start building a complex product with the perfect set of teams. You’ll need to inspect and adapt your project structure and discover what works best for you. What I’m about to describe is a model structure based on what worked for my Microsoft customers. One was a university where I ran a delivery team for a global systems integrator. The other was a financial services organisation where I ran a delivery team of freelance contractors and client resources.

You’ll find show notes including a PowerPoint presentation illustrating the model project structure at customery.com/017.

Let’s start with the different groups that are needed to execute a successful project to build an amazing business application. There are six of them.

Product owner group

This group is responsible for the product backlog. It’s led by the lead product owner and includes domain product owners and subject matter experts.

Change group

Is responsible for business change and user adoption. It’s led by the change lead and includes process analysts (if you’re reengineering business processes), and people responsible for business change, communications, adoption, user feedback, training content and delivery.

Quality group

Responsible for ensuring the product meets the Microsoft customer’s security, performance, and quality standards. It’s led by the quality lead and includes people responsible for test automation, performance testing, acceptance testing, data quality testing, system integration testing, and security testing.

Delivery group

This is the core team responsible for building our Dynamics 365 or Power Platform applications, and often has other groups within it responsible for systems integration and data migration.

Architecture group

Responsible for ensuring our applications meet the organisation’s architecture standards and facilitating and documenting the design of our new business application.

Project management group

Our business application’s project management group are often part of the organisation’s project management office, PMO. It’s led by a project manager and includes a risk manager, project coordinator and project scheduler.

That’s six groups -- product ownership, change, quality, delivery, architecture and project management.

Your enterprise project might have more or fewer groups than this, but I hope this is a useful starting point for considering how to structure your project or compare your project structure to my baseline.

Next, let’s take a look at some of the key roles, group by group.

Lead product owner

The lead product owner is the person ultimately responsible for the value of the business application to the organisation and the success of the project to build it.

They need to have sufficient authority from the project sponsor and the organisation’s executives to prioritise the backlog, and they are often senior leaders trusted by the leadership team to build the best product possible.

On an enterprise applications project, it’s a full-time position. Seconding a senior leader to a project on a full-time basis is a critical challenge in most Microsoft customers I’ve worked with.

I’ve worked with lead product owners that are independent consultants. In these projects, they had significant experience working with the organisation and were trusted by the organisation’s leadership team and they had the capacity to be dedicated to the project.

Product owners and subject matter experts

In an enterprise applications project, one product owner is rarely going to have sufficient capacity to get everything done. My customers have had additional product owners supporting the lead product owner with their domain expertise so that they can help create and refine items in the product backlog. These domain product owners are often mid-level managers and are also dedicated full-time to the project.

In turn, the domain product owners are supported by subject matter experts with deep knowledge of specific areas such as existing applications you might be replacing with a Power Platform or Dynamics 365 application. Subject matter experts are not necessarily full-time but they participate in sprint reviews and in backlog refinement workshops during each sprint.

Change lead

The change lead is a business change management practitioner responsible for ensuring the organisation is ready and able to successfully adopt the application. This is another full-time role leading a team of process analysts, communications, learning and development professionals. Whether you’re releasing lots of small increments or a few large deployments, the change team coordinates the successful transition to your new business application and way of working.

They might also be responsible for collecting feedback from user acceptance testing sessions and passing it back to the product owners’ group.

This is another full-time position, and I’ve seen people in this role be successful whether they are a customer employee, an independent consultant or from a change management consultancy.

Quality lead

The quality lead is a software quality professional responsible for verifying that the new business applications meet the organisation’s quality requirements. In an enterprise project, this is another full-time role leading a team of automation engineers and specialists testing performance, security, data quality and systems integration.

User acceptance testing can be coordinated by the quality lead if it’s not run by the change lead.

I’ve worked with quality leads from external software quality consultancies several times and can be helpful to ensure the accountability of the delivery group, which is often run by a Microsoft partner.

Delivery lead

The delivery lead is responsible for the technical teams that are building new applications. This is the role I’ve occupied in the last couple of major projects. The delivery lead is responsible for managing the resources in the scrum teams and working with one or more scrum masters to ensure those teams thrive.

I’ve also had one or more DevOps engineers who sit outside the scrum teams and are responsible for managing the Power Platform environments, helping the applications teams improve their DevOps culture and practices and assist them with solutions to some of the trickier ALM challenges we’re faced with.

I’ve had between one and three scrum teams building Dynamics 365 or Power Platform apps, and in larger projects where were separate delivery leads with their own delivery groups responsible for data migration and systems integration.

My scrum teams have included a shared scrum master (although you might want a dedicated scrum master for each team depending on the scrum master’s experience) and developers who specialise in analysis, application building, custom development and testing.

Balancing those specialities is a critical responsibility of the delivery lead. A shortage of analysts and the developers won’t have enough refined items in the backlog and they’ll run out of work. A shortage of developers and your velocity will suffer. A shortage of testers and you’ll have lots of undone work at the end of each sprint. If you’re tempted to run analysis sprints, build sprints and testing sprints that’s a sign that your scrum teams are imbalanced, and you need to fix the resource mix instead of running special sprints.

My teams have been a resourced from a combination of my customer’s developers who are often new to the Power Platform and are learning as we build the apps, and consulting resources from the Microsoft partner and or independent contractors.

The application testers in my scrum team are usually borrowed from the client’s software testing group or consultants from the software quality consultancy. They could be resources from the Microsoft partner, but I like the extra accountability and separation when they’re from the customer or somewhere else.

My scrum teams have usually had one analyst, 5 or 6 application developers and 2 or 3 application testers. Your mix will vary depending on everyone’s skills and experience.

Lead architect

Maybe my teams are unusual, but the application architecture usually isn’t part of the delivery group, it’s the responsibility of the architecture group led by the lead architect.

The lead architect is responsible for a couple of things. Ensuring the application is being designed as the requirements emerge and before its built. And getting the timing right here is a critical skill. Designing too much up front can be a waste of effort, and designing too late can hold up the delivery group.

The architects are responsible for upholding standards, creating and sharing their designs with the delivery team, and maintaining the as-built design documentation.

The developers within the scrum teams in the delivery group have a strong influence on the application design. I don’t want to give you the impression that the final design is handed to them. Having a separate architecture team enables us to evaluate options, research ISV solutions, run procurement and generally keep the developers from getting dragged into too many meetings.

Again, the best architecture teams are a blend of resources from the Microsoft customer’s and partner’s organisation.

So that’s it for the most important roles in an enterprise business applications project team: lead product owner, change lead, quality lead, delivery lead, and lead architect.

Project manager

Project manager! How could I forget the project manager?

Do we really need a project manager even when we’re using an agile approach like Scrum?

I think we do, yes.

The project manager is responsible for managing the project risks, budgets, schedule and managing all the contracts with our vendors, consultancies and contractors.

Perhaps you could find a lead product owner who can hold these responsibilities, but I usually find that it’s better to find a product owner steeped in business expertise and find a project manager with the right character and project management experience. The project manager can be supported by a risk specialist, a contracts coordinator, and a schedule coordinator as necessary.

Risk mangement

Talking about risk management for a moment, Frieda Maher, the product owner I worked with at University of New South Wales reminded that an agile approach is designed to enable us to take risks and experiment with new ideas. Not all risks need to be mitigated and minimised. Frieda was, in fact, a little disappointed when our eight-week proof-of-concept project was so successful because to her it demonstrated that we hadn’t been bold enough and we hadn’t grasped sufficient opportunities to challenge the status quo. Risks can be a good thing. Thanks for that lesson, Frieda.

You can download an editable PowerPoint slide illustrating the six groups and lead roles for your own use by visiting customery.com/017. There you’ll also find show notes, links to scaled agile resources and a transcription.

We’ve got a couple more Q&A episodes coming up and then we’ll have another season of interviews with Microsoft customers and partners who’ve built amazing Dynamics 365 and Power Platform applications. If you’d like to share your story with the Amazing Applications audience, you can find out more at customery.com/guest.

That’s it for this episode. Thanks for listening. I appreciate you downloading this podcast and squirting it into your ears. Remember, if you found it useful, please subscribe and share it with your connections on LinkedIn and Twitter.

Until next time, keep sprinting.