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 'Weekly Updates', the next strategy to avoid project death is the Agile Project Approach.
Once again, we will look at what it is, the symptoms you will notice from its absence, how you can go about setting the structure up, and the benefits that come from its existence.
What is an Agile project approach?
The term agile refers to something that’s able to move or change direction quickly, and this is the essence of Agile project management as well. Its other tenets include customer focus, transparency, shared ownership, and continuous improvement.
Agile is more of a general methodology than a specific approach, and popular project management methods like Scrum and Kanban are based on Agile principles.
How is an Agile approach different from a Waterfall approach?
Waterfall: Sequential progression through clearly defined stages leading to a polished product
Agile: Rapid cycles of build/test/deploy to build a “good enough” product and iteratively improve it
The Waterfall method has long been the standard way to manage projects and is still frequently used today. A top-down approach, it begins with a clear idea of the end point the project wants to achieve.
From there, it divides projects into distinct phases—from initial research and requirements gathering through to design, testing, and deployment—and works through them sequentially.
The aim of a Waterfall approach is to divide the project into clearly defined stages that allow for simple costing and planning, ultimately delivering a refined finished product.
An Agile approach, conversely, aims to rapidly produce a minimum viable product (MVP), a basic version of the product. This can be used to gather user feedback and inform future iterations, evolving the product each time and delivering functionality at every stage.
An analogy I like that illustrates the difference between the approaches is to consider a user that wants a mode of transport.
The Waterfall approach would be to find out exactly what the user wants, and then spend months building a vehicle that suits their requirements.
The Agile approach would be to build them a bicycle in a matter of days, get some feedback, and eventually evolve the product, perhaps moving to an electric bike next, a moped, and eventually a motorcycle.
The process is broken into short, intense periods of work called sprints, each focused on adding a discrete package of improved functionality to the product.
The benefits of an Agile approach and the risks of not using it
I managed a Waterfall project where on delivery we realised that we got a major part of the design wrong and had to completely redesign the system from scratch! That simply wouldn’t have happened with an Agile approach.
So why build the user a bicycle if they’re going to end up with a motorcycle? We’ll look at the Agile and Waterfall methods side by side to showcase why Agile has the upper hand in so many cases.
Adaptability is key here. If you ask users what they want, they’re likely to tell you everything they could possibly desire.
It may turn out that, having built them a motorcycle based on their dream vehicle, they actually only need something to get to the shop down the road every now and then. A bicycle might’ve sufficed after all! This way, the product doesn’t end up with functionality it doesn’t actually need.
Requirements may change during the project, as technology and the business itself evolve. Having users involved in the process throughout makes it far easier to respond to these changes and adapt accordingly.
Similarly, the user’s circumstances might change. Let’s say after the project begins, they’re hit with some unexpected bills and can no longer afford a fully-spec’d motorcycle.
Using the Waterfall approach, work has to stop when the budget runs out, and if that happens unexpectedly, all that can be handed over to the user is… half a motorcycle. Maybe they only get a wheel, a seat, and the handlebars, which won’t help them at all.
With an Agile approach, the user runs out of money and all that happens is that they can’t afford the fourth iteration. They’re left with a moped which, while it might not be the perfect solution for them, is a lot better than just being stuck with a pile of parts!
How to implement an Agile project approach
Decide it’s right for you > Get managerial buy-in > Follow the communication framework
There are certain activities, like upgrading versions, or migrating from on-premise to cloud systems, that likely better suit a Waterfall approach. Having said that, for most projects where there’s a choice between the two, I’m always going to lean towards Agile.
I switched to using Agile after that major redesign, an error that cost us a lot of money and time, and I’ve never really looked back.
There will however be organisations where moving to an Agile approach is difficult straight away. Perhaps they’ve invested significantly in doing things a certain way. But assuming that adopting Agile methodologies is a possibility, start with managerial buy-in and clear communication.
You’ll need support to change the way that people work. For a D365 & PP implementation, it’s your own team who will see the biggest change to their ways of working. Hopefully, your existing relationships and trust will give you enough influence that, when you articulate the benefits for them, they’re happy to adopt Agile.
Users have to be sold on the process as well. It’s critical they understand that your MVP is not the finished product. Make it crystal clear that the bicycle is the starting point, and that it’s been created to deliver something and gather feedback.
This can be a shock for users who have previously been given motorcycles, but remember that you built this bicycle far more quickly, and assure them that there’s more to come.
The good news is that Agile provides a communication framework that keeps stakeholders involved in every stage of the process. Each sprint has set communication structures, within which stakeholders can have their say and help inform the work.
Sprint planning occurs at the start of the sprint and outlines what work is to be done and how it will be achieved.
Daily stand-up meetings are short chances to assess progress and challenges. Issues are raised here so that solutions can be found as quickly as possible.
Sprint reviews follow the completion of the work and focus on the product. This is where users have their chance to review the bicycle and decide it needs a motor, for instance.
Sprint retrospectives occur within the development team and focus on the process of the sprint, rather than what was delivered. They help the team improve their own tools and ways of working.
We go into plenty more detail on these communication structures and other aspects of Agile in our Consultant Power-Up Course, giving you templates for all these communication structures as well as more guidance on how to implement Agile.
The challenges of introducing an Agile project approach
While introducing Agile won’t always be a walk in the park, I can safely say I will never choose a Waterfall approach over an Agile one, unless it is necessary for something like data migration or a version upgrade project.
Some factors that might favour a Waterfall approach are if the project is very well understood, simple, and communication is difficult for some reason, perhaps due to a highly remote or spread team.
That said, there are a couple of Agile pitfalls to be aware of. The biggest stems from a core benefit of Agile—being able to stop the process whenever necessary. If management’s priorities change, you don’t want to be left with an unfinished product.
Agile makes it easy for projects to be paused or stopped in the right way. When this does happen, we recommend doing so in the right way, rather than just having the team down tools immediately.
It’s typically a good idea to set a termination process that includes a few final sprints to complete the highest priority items. Don’t forget that whatever methodology you’re using, the focus needs to remain on the users, and they have to use the product in whatever state those sprints get it to.
Finishing projects correctly will ensure they are left with a system that makes their life easier, wherever that happens to be on the bicycle-motorcycle lifecycle!
In the next post within the ‘Top 10 Governance Structure to Guarantee Dynamics 365 Success’ series, we will discuss strategy #8, the ‘No Code Rule’.
If you want to get these posts straight to your inbox, then be sure to sign up to the mailing list below.
Richard S White
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