Recently I participated in a group discussion with Colin Vermander about what it takes to have a successful implementation of Dynamics 365 Portals. Among many other factors that I’m sure we’ll discuss in the future, one that struck me is how to build the perfect Portals Implementation team
I thought it would be fun to take a look at the skillsets that are needed to build that team, and the roles associated with those skillsets. Now let’s make the distinction clear before we get started that many of these roles overlap, and the people who fill these roles simply need to have the skillsets required. Very often, one person might fill multiple roles on a smaller project. For example, the Business Analyst and Functional Consultant might be the same person. Conversely, on large implementations with tight deadlines, you might have a very large team with multiple workstreams. Each workstream might have a team of BAs, its own dedicated functional, solution architect, and development team. The golden rule at the end of the day is to ensure that the project is not understaffed, and that each of the below skillsets is taken into consideration when building your team.
Also note, that this article tries to be methodology-agnostic as much as possible. Some roles might only apply to certain methodologies – for example if you are using scrum you’ll need a scrum master, etc. Alright, without further adieu, let’s get down to it.
Discovery and Requirements – Business Analyst
It probably goes without saying: for any implementation – of any solution – to be successful, a very solid understanding of the business need is absolutely required. I can’t tell you how many times I’ve gone into an implementation where this wasn’t actually the case – sure we had requirements, but there wasn’t a sanity check done on these requirements – they weren’t validated to match the understanding of the business – or the understanding of the business just wasn’t there. Requirements should always come from business processes that are not only well-documented, but also properly engineered. This engineering effort can be a part of, or be done prior to, the implementation, but it does need to be done.
For this effort a solid Business Analyst needs to be engaged early in cycle – preferably as a key part of the proposal team. You need a strong value position & solution fit. Bear in mind, that Dynamics Portals are not always going to be the right solution for a given problem. It’s a question of trying to fit a square peg in a round hole. Does the client want an E-Commerce solution, such as an online store with a shopping cart? Portals probably aren’t the right fit in that case. We’ll talk about when portals are the right fit and when they aren’t in the future, but the right technology needs to be selected for the job and for that a true understanding of the business need is paramount.
Functional Portal Design – Portals Functional Consultant
With an understanding of the business requirements under your belt, time to work on that solution fit I was mentioning earlier. The Functional Consultant is a key player on any Dynamics implementation, and in no situation moreso than a potential Portals implementation. Speaking from experience, the Portals product has many quirks and limitations that sometimes require innovative solutions to workaround – and in some cases, requirements discovery might make it clear that a different solution altogether might be required. The Functional Consultant is the one who needs to be able to say “we can do that” or “no, we can’t do that”!
The Portals Functional consultant owns the functional design of the portal. They are ultimately responsible for the experience encountered by users of the Portal front-end and are a key player in forging the overall solution design. They also need to work closely with the stakeholders and need to be closely engaged throughout the entire lifespan of the project.
Assuming that Portals are going to be used, a solid solution design is needed. Remember that Portals implementations consist of many moving parts. The front-end design, consisting of Web Templates that are designed using Liquid; the Website Structure and Security Model, consisting of Portals components like Web Pages and Web Roles; Access to CDM entities using Entity/Web Forms and Lists, and possibly other custom pieces. Knowledge of the Portal components, capabilities and features is essential to implementing the right way and in a profitable manner. It’s important to know what components to use to achieve each outcome, and it’s equally important to know when to say “no, we can’t do that”. Sometimes even if you know something is hypothetically possible using a custom solution, that doesn’t make said custom solution advisable or warranted. Sometimes it’s better to stick to doing things the way the product has been designed and a functional consultant with strong knowledge of Portals can help make those calls.
Many readers might be thinking: “I’ve never heard of a Portals Functional Consultant – is that a Microsoft Certification?” While there is no certification specifically on Portals, what we are really talking about here is a Dynamics Business Consultant with a strong knowledge of Portals. In fact, getting this knowledge is simpler than ever, thanks to the efforts of great MVPs like Nick Doelman, who have added tons of awesome learning material on Portals to Microsoft Learn. Be sure to follow my Blog as well!
Dynamics 365 Mastery and Design – Dynamics Functional Consultant
One of the biggest mistakes to make on a Portals Implementation is to think of it as just a Portals implementation. The Portal does not exist in a vacuum! If you lose sight of how the Portal fits into your overall Dynamics 365 solution, your are going to be in trouble. The Experience of the Dynamics user is crucial, as is the business value brought into the organization via the Portal, which is ultimately experienced via Dynamics 365. If your Dynamics implementation is a separate workstream from the Portal, these teams need to work closely to ensure harmonization of goals and design. How are the pieces going to fit together? Note that the Portals Functional and Dynamics Functional don’t need to be separate roles. On a smaller implementation, they can certainly be owned by the same individual, in which case that person needs to own both the front-end experience and back-end design and data model.
Technical Solution Design & ALM strategy – Solution Architect
The Solution Architect on a Portals implementation is responsible for the overall technical design of the solution and needs to have a solid understanding of web technologies in general as well as Dynamics 365 and Portals. There’s a lot of overlap between the Solution Architect and the Lead Developer, as well as between the Functional Consultant and the Solution Architect. On larger projects they are likely all separate roles, while on a small ones one person can wear a few hats.
In addition to Dynamics 365 and Portal solution design, the Solution architect will be involved in design of other aspects of the overall design such as security, infrastructure, and integration, though the technical details of these pieces can often be handled by a separate role (see below). Additionally, another very important piece of the puzzle is to ensure you have a solid ALM strategy and understand how you will be managing customizations and data during development, testing and production.
Portals Configuration – Portals Functional Consultant
Portals is a powerful product with a large amount of functionality available using point-and-click configuration. It’s not as intuitive as it could be, so having someone with portals expertise is critical to getting the most out of the product. Someone on the team needs to have knowledge of Portal Content Components like Web Pages and Web Link Sets, CDM Components like Entity Forms and Lists, and Portal Security pieces like Web Roles and Entity Permissions
Dynamics Configuration – Dynamics Functional Consultant
In addition to the Portal configuration data, someone needs to build out the Data model as well as forms and views in Dynamics 365, to make no mention of charts or dashboards. Again, the Portal does not exist in a vacuum and if these pieces are overlooked, the implementation won’t be successful. The data model should be driven primarily by the business need, and when pieces need to be added to enable functionality on the Portal, careful thought is needed to understand how these pieces interact with the end Dynamics user experience. I’ve been involved in many Portal implementations where the Portal has been built to a high standard and delivers a great experience, but the Forms that are deployed to the end users who will be using the data coming in from the Portal are treated like an afterthought. Don’t let this happen.
Liquid Templates – Web Developer
There is a huge amount of functionality that the portal is capable of in terms of accessing the Common Data Model and using it to provide a very custom experience. This is achieved with a combination of Liquid for front-end (client side) data access and manipulation (as well as layout) and Dynamics 365 Plugins, Workflows, Actions, and Custom Workflow Activities for Server-side processing. Finding really solid guides on Liquid is tough but you can check out Nick Hayduk’s and Megan Walker‘s Blogs for some good posts on the subject.
Since so much of what you can do with portals beyond point-and-click configuration is dependent on Liquid Expertise, my recommendation is that the Development team lead and Solution Architect (often, but not always the same person) have a very strong footing with it.
Dynamics 365 Plugins, Custom Activities – Dynamics Developer
The other half of unlocking custom functionality with portals is clever use of plugins and workflows. Understand that CRUD operations that are executed by the Portal will trigger plugins and workflows as normal, and this is really how sever-side code happens in the Dynamics Portals scenario, since we don’t have access to the Web Application’s code base like in the Adxstudio days. Trigger an event via the portal, and wait for the result of a real-time process within dynamics before responding on the Portal. You don’t need code-behind to do this! Obviously there are some nuances, and furthermore don’t forget that custom code should always come second after extracting maximum value from point-and-click configuration.
HTML, CSS & Bootstrap – Web Designer
Many Web Developers have solid knowledge of CSS & Bootstrap, but on a large implementation you’re going to need multiple developers especially if timelines are tight. It’s helpful to divide the work between those that focus on functionality and those that focus on look and feel.
Graphics – Graphic Designer
If you are going to need any kind of custom graphics or animation on your portals, that role will need to be filled by someone with experience in that area. Probably not a full-time role – someone who comes in as needed.
Security, Integration & Infrastructure – IT Consultant / Technical Architect
The amount of knowledge of these areas will depend heavily on the technical choices made and the business need. Is a custom security provider needed and if so is it a fit with the Portal? Will the Portal be used internally by a organization or externally? Is single sign-on needed with an on-premise AD? If the answer to all of these questions is no you can use OOTB configurable Portals security (Azure B2C being the recommended approach) but a “yes” to any of these questions complicates matters. Are integrations with third party software needed? When everything is OOTB and in the cloud, integrations between Dynamics and OneDrive, OneNote, Sharepoint and Exchange are simple. But when other integrations are needed you need to asses the technicalities involved. As always with integration consider whether you will perform the integration yourself or by partnering with someone like KingswaySoft. Are any of the systems to be integrated with on-premise? In that case infrastructure considerations enter the picture. All of this might land on the plate of one or multiple technical resources involved in the project.
Test Strategy and Execution – QA Specialist
Having a proper and robust test plan and test team is as important a part of any successful implementation as anything else. All Portal use cases need to be documented in advance and test cases created for each one. Quality QA Specialists can also help drive User Adoption and User Acceptance Testing.
Without Quality Assurance and testing, even the most skilled group of designers and developers are setting themselves up for failure. Let’s leave it at that for now, but in the future i’d like to explore testing strategies for Portals in more detail. Stay tuned!
Project Management – Project Manager
The larger the implementation, the greater the need for skilled Project Management – especially relevant when multiple workstreams are involved. The PM doesn’t need knowledge of Portal specifically, and Portals don’t involve anything which would make this role different than in other implementations, but I wanted to make sure to mention it.
This was by no means an exhaustive list, but hopefully it gives you some sense of what needs to go into a proper Portal Implementation it order for it to be successful! See you next time!
One thought on “Building the Perfect Portal Team”