Dynamics 365 projects fail for many reasons.
In ‘Series Intro - Top 10 Governance Structures to Guarantee Dynamics 365 Success’, we outlined how we define a failure in Dynamics 365 (D365) & Power Platform (PP) projects.
Without the correct governance structures in place, common symptoms start to appear and imminent death, project death, is just around the corner.
This death is avoidable through good governance structures, our best practices for which we’ll be sharing throughout these posts.
Each governance structure identified in our series has its own requirements and impact.
In this monthly series, one of our lead consultants, Richard White, shares his real-world experiences of how these structures affect the organisations that use, or fail to use, them correctly.
Following our last post on The Corporate Mindset and the completion of the 10 strategies, this bonus strategy to avoid project death is The Documentation Checklist.
While this isn’t a governance structure in itself, it’s still important—often overlooked, rarely done perfectly, but a key factor in the use and longevity of your system.
With that in mind, lead consultant Richard White is once again here to guide you through why you need documentation, how you can stay on top of it to avoid issues, and a specific checklist for some of the core documentation he looks for when joining any project.
What is documentation?
I won’t spend long on this, since most people understand what documentation consists of. But it is important to note that documentation captures virtually everything about a project, from its aims and licensing to its processes and the changes implemented through its lifecycle.
What are the problems caused by a lack of documentation?
Without records of how the system has been built, what it’s been built for, and the decisions made along the way, it’s very difficult to take on the management of that system. Helping new users understand its features will be harder than it should be. There’ll be no record of any previous changes made or considered, meaning there’s a risk of making the same mistakes again.
A lot of organisations rely on Microsoft partners to produce documentation, but they’re often short-changed. Partners know that it can be time consuming, isn’t seen as valuable by the client, and is rarely fully understood or verified by them.
The reason these partners skimp on documentation relates to one of its biggest issues: it’s often not obvious that it’s useful. When things are going right, the system is working well, and the people maintaining it are settled, there’s not a huge need for documentation.
But when someone new comes in, or the system needs changing, or it develops a fault of some sort, suddenly documentation is essential. And it’s far too late to create it. I’ve had projects where I’ve been asked to manage a system and need weeks, sometimes months, to get up to speed because I have no idea what they have, how it has been built and what it takes to maintain it. All the delays this reverse engineering introduces could be avoided by properly documenting the system in the first place.
What issues does too much documentation cause?
It’s just as easy to go too far the other way. Fresh out of university, I started my own database company. One of my first clients asked me to build them an online database. I started, as I’d been taught, developing tons of documentation, which did just what it was meant to. It helped me to understand the client’s requirements and develop it through various stages into a beautiful piece of software.
The documentation I delivered was like a thesaurus, maybe even a set of thesauruses! It looked great, and the client was impressed. But it soon become obsolete and immensely difficult to maintain. It was too difficult to find the information you needed in such a large volume of documentation.
That saw me swing the other way, producing software without enough documentation, since I couldn’t see the value in it!
Discovering Agile principles helped me learn how to develop software with the right level of documentation. The realisation I had about documentation is that it must make practical sense and have a clear benefit to the organisation.
How to reap the benefits of the right level of documentation
Getting documentation just right is a Goldilocks moment—finding the balance between too much and too little isn’t easy. In fact, in my 20 years of experience, I don’t think I’ve ever walked into an organisation or joined a project and seen that they had exactly the right balance of documentation.
The problem is that documentation is a tricky issue with any technology, especially D365 & PP, as it evolves at such a blistering pace.
That said, some organisations have been better than others, and they’ve benefitted from that. People are aligned with a strategy on what documentation is needed and why, as well as how it’s maintained.
This makes transitions of ownership or team members far easier. Proper documentation adds longevity to your system and makes it independent from individuals or teams. Organisations undergo constant changes in personnel, and that needs to be considered.
With proper documentation, it won’t be the end of the world if a system expert leaves the organisation, because the foundations are there to bring someone else up to their level. This level of robustness, which allows the system to be explained, maintained, and evolved, is crucial in avoiding project death as personnel changes occur.
This leads me onto our core list of documentation. This isn’t a definitive guide, since every organisation and project is different, but these are documents that I’ve found useful to have the vast majority of the time.
They’ll help organisations avoid ownership pitfalls if they need to or change partner or supplier, and they should follow our 3 key principles of simplicity. As well as aiding in the development of the system, they should be:
Simple to write
Simple to maintain
Simple to read
Remember that documentation is a communication tool, and so users with no knowledge of the system are your audience.
I was a member of Toastmasters, a leadership and public speaking organisation, for many years, and one of their key principles was ‘know your audience’. It’s the same with software documentation—it’s about knowing your audience first and then writing your documentation for those people.
In the documentation for a D365 & PP solution, you’ll need to consider the following audiences:
Organisation Directorship
Super Users
End Users
Current & Future D365 & PP Team
When creating documentation, we need to look at which one of these audiences we are writing for and how they will benefit from it.
Our Consultant Power-Up Course provides templates for each of these types of documentation.
Core documentation checklist
So, without further ado, here is our (non-exhaustive) core documents list, divided into project, business, and technology categories:
Project Documents
Project Charter
Lays out the project’s purpose, objectives, stakeholders, risks, resources, and dependencies.
Product Definition
The overall scope, description, and estimate of work to be carried out.
Project Roadmap
The project’s schedules, milestones, and deliverables.
Agile Related documentation
Sprint planning, reviews, and retrospectives.
RAID Log
Tracking of Risks, Actions, Issues, and Decisions.
Business Process Related Documentation
User Story Backlog
An informal, natural language description of features within the software system. These are usually contained in systems such as DevOps.
Walkthrough Documents
Perhaps not the official term, but this is what I call them anyway! These are walkthroughs containing As-Is and To-Be process maps for each process implemented to describe their initial background, discovery element, and how they will be implemented. These complement user stories as they provide a complete picture, whereas often user stories will contain pieces of the puzzle.
Governance documentation
These cover a lot of the governance structures described in previous posts, including highlights from steering group meetings and super user group meetings, as well as design authority guidelines.
MS Dynamics 365 & Power Platform Administration Guide
Technology Landscape
In-depth visualisation of the solution and the related technology, as well as how they interact.
Licensing Analysis
An overview of licensing requirements.
Conceptual Data Model (CDM)
A high-level conceptual data model for the overall solution.
D365 & PP Entity Relationship Diagram (ERD) & Logical Data Model
The core MS Dataverse tables utilised as part of the implementation.
Code Analysis
An overview of the customised code utilised in the implementation, the degree to which the implementation is customised, and the reasons why custom code was chosen over out of box functionality (see the post on the No Code Rule for more details).
Data Dictionary
Describes all the data columns of the system and their intended purpose. This can also include views, charts, dashboards, processes, flows, and business rules.
Security Model
The real ‘meat’ of the security model will be contained in the user stories and walkthrough documentation, but high-level security documentation should be in place to describe how the security has been built out with key decisions, along with business unit and team structures.
Request for Change Register
Documenting the history of all changes made within the system, and the ones requested.
Index Guide
Index document
Finally, an index document briefly describing all the documentation, where any given item can be found, each item’s purpose, and how to maintain them.
Why it’s important to get documentation right from the beginning
Whenever, I walk into an organisation, these are the documents I am looking for to better understand their system. They give me a clear picture of how the system is managed, their current challenges, and the kind of issues I’ll be up against.
If these documents aren’t in place or aren’t up to scratch, I always recommend a discovery period to create or improve them. Otherwise, I am working from a vague position, and my experience has shown me that can lead to all sorts of problems.
Conversely, when the right documentation is in place, the foundations are laid both for a really good system and for new personnel to start working with it. It’s so much easier to build this foundation at the beginning instead of waiting for a consultant to come in and ask for it and then have to piece it together.
This bonus posts rounds off our ‘Top 10 Governance Structure to Guarantee Dynamics 365 Success’ series, and with that behind you, you should be well-placed to manage your own D365 & PP implementation far more effectively.
If you’ve found this series useful, sign up to the mailing list below to see more posts like this—I have additional posts and series planned that may well be of interest.
If you want more of a one-to-one discussion, then I am always happy to learn about your specific situation and do anything I can to help. Feel free to direct message me on LinkedIn.
Richard S White
365 InHouse Founder & CEO
A seasoned Digital Transformation Executive renowned for leading high-performance teams towards innovative and strategic technology solutions. Specialises in steering organisations through complex digital transformations, fostering productive and accountable partnerships. Known for effectively guiding projects to success, aligning them with business objectives, and enhancing organisational self-sufficiency. Skilled in blending technology with business strategy, adept at facilitating candid discussions, aligning stakeholders, and crafting strategic roadmaps, positioned as an invaluable asset for organisations navigating the complexities of digital transformation.
Want help with your specific situation? Connect with Richard on LinkedIn to setup a free no obligation virtual coffee: http://linkedin.com/in/richardswhite/
Comments