Practice Management: Key Roles in a Dynamics 365 Practice (Part 1 of 4)

I came from New Zealand and there's a Maori proverb that really stuck with me over many, many years.

He aha te mea nui o te ao, He tangata, he tangata, he tangata.

It means, “What is the most important thing in all the world? It is people, it is people, it is people.”

When we look at the setup of a practice, it runs around relationships with people. They are your team, they are your customers, and they are your stakeholders.

Engagement with people is not so much a science but more of an art, as I see it. It's understanding what motivates people and understanding not only people's skill set but also their sense of value in what they do.

When it comes to leading people in the practice, it takes balance between knowledge of the technologies we work with and how they can benefit people, as well as valuing members of the team. To do this, you need to develop skills in emotional intelligence. If you are not familiar with this, I recommend the following book as a starter.

“Emotional Intelligence 2.0” by Travis Bradberry & Jean Greaves

How you structure your team comes down to personal preference and your leadership style, but I found with Dynamics projects, there are a few key roles that make up a structure of a team. (Please note I am looking at the specific Dynamics 365 role in this post. On projects, there will also be roles such as PM, BA, EA, ED, and Subject Matter Experts. These roles do not need to be experts in the Dynamics 365 platform.)

If you've got a team that's split across multiple geographies, it's important to have somebody in the role of leader (note, I did not say manager) in each geography to create an effective practice. People need leadership from people that have a similar skill set to theirs. The locale's Team Lead is to look after the welfare of the team members and the growth of their skills. They will be strong in the following:

• a great “people person” and value people and relationships

• support a quality check on work at a high level

• really know the technology

• can guide or mentor staff under particular areas

When I think of an architect, I'm not thinking so much of an enterprise architect, but I'm thinking of an application architect—somebody that knows Dynamics 365 very well. You'll want to look for:

• focused on User Experience of the solution they architect

• a broad understanding of the peripheral technologies around Dynamics 365 (ISV solutions, other Microsoft technologies) that enhance and allow you to make a complete solution

• has a very holistic view: from a functional perspective and from an architectural perspective

• has a lot of experience (5-7 years); I would expect this a norm for somebody in this role.

• has a very strong understanding of integration, data migration, and handling the connectivity of Dynamics to other external solutions

From a career progression path, I would typically see them ultimately wanting to move into an Enterprise Architecture space where they are involved more broadly than just the Dynamics 365 technology stack. I have seen developers and functional BAs move into Architect roles.

The next role within the team would be the Functional BA.

Over the years, I found that more and more Functional BAs are becoming active technologists. In other words, people who are strong in the manipulation of Dynamics 365, but they can't gather those requirements from a customer efficiently, or validate effectively and come up with the best solution. What I'm saying is that the pendulum has swung to people being very strong technologists but very weak on the BA side of things. And to create fantastic solutions, that BA skill is about understanding how people work within their processes and then creating a user experience that actually allows businesses and people to increase their productivity and provided a superior user experience.

The other thing lacking in this role that needs addressing in successful practices is for Functional BAs to run effective workshops and requirements gathering, not just adding requirements without rigorous validation. Are the supplied requirements needed to meet the outcome of a successful implementation?

Essential skills:

• excellent business analysis skills

• great communicator

• can do everything around configuration on the Dynamics 365 platform

• can deploy Dynamics 365 for validation purposes and workshops

• understands security models and processes within the application

• strong functional skill set across a range of ISV add-on solutions (ClickDimensions, XperiDo, etc.)

• can configure Dynamics 365. However, I would not expect them to front-end code.

• can have business conversations with various levels of the organisation and can translate those to technology-based outcomes

• strong skills in the validation of requirements; asks ‘WHY' a lot

Another role I typically see within the team is that of a developer. Developers should be able to do the following:

• security roles

• forms

• views

• reports

• front end scripting

• plugins

• workflow assemblies

• advanced API integration

Their skills will include:

• understands people and understands that what they're creating is going to be used by other people; long after the coder is gone, people will have to live with the quality of what was developed

• very strong in SSIS, and have skills in third party tools like Kingswaysoft

• broad knowledge of ISV solutions

• good understanding of Enterprise Service Bus (ESB), integrations and how to best enrich data

• very thorough understanding of Application Lifecycle Management (ALM)

• skills in PowerShell

• good .Net developer

• totally familiar with Visual Studio, particularly Visual Studio Online

• able to work in multi-geo environments

Depending on the size of your team, you can add in these resources:

When looking for an Enterprise Architect, I seek out people that have Azure skills. They may have come from an on-premise world, but I want to make sure they have strong cloud skills. I prefer all development to be done in Azure no matter what the Dynamics solution being implemented, and then deployed onto production, whether that is on-prem or online. Strength in ALM is important at this level.

A Resource Manager constantly assesses and understands where individual skill sets are at and then applies them appropriately to projects. It's about managing the right skills for project allocation and team dynamics. It's not just about maximising the revenues of an individual, but it's about making sure their health within the business, their career development is also monitored. Are they being upskilled? Is their quality of skills improving with where the technology is in the market?

Those are the key roles that I think every Dynamics practice should have, sometimes you find rear gems that can fill multiple roles effectively. However, with the growth of new technologies that Microsoft has added to the platform and continues to do so, it is becoming harder to be an expert on everything Dynamics. With this post, I have only scratched the surface on this topic. I have written three additional posts that are coming soon.

You may agree or disagree with what I have written, please comment below and share your experience.