In my last post in this series on solution architecture for working with the Power Platform, we looked at the topic of project governance and governing the delivery of implementation projects when working with the Power Platform, in the context of a solution architects role in this area.
In this next post, we’ll dive deeper into this topic focusing specifically on some of the methodologies and things that can be put in place in the form of ‘good governance’, to work with the aim of ‘keeping a project on track to deliver success’.
What does governance success look like?
So in the last post where we started to talk about governance for implementation projects, we covered the high level of what governance focuses on with issues, risks and changes being a few things we have to wrap process around and govern to see success. When looking at what success looks like relevant to these things we’re thinking about some of these things…
- Ability to report on live and historical issues, risks and changes
- Ability to not only report on the above, but report on audited feedback and outcome
- The potential of a change control board to delegate approval
- Being agile to delivery
- Reviewing what was completed in the attempt to continue improving sprint on sprint
- Not only planning sprints, which will see retrospectives, but also having high level check points as to goals to achieve at various stages in the implementation project
- Much more!
Sprint planning
One of my points around successful project governance and delivery is to ensure sprint planning gets embedded into the delivery process by a delivery or project manager. This allows delivery resources in the team to know exactly what they’re doing in the current short period, but also allows the customer to see what will be complete within the next short period. Furthermore, this gives an architect the ability to report on what was completed within specific time frames if there are questions from the customer concerning this, and lets them see what they need to plan out so that there is enough work for delivery consultants to continue to work on for the next 2-4 sprints.
Risk management
The next point from me around successful project governance is appropriate risk management. We discusses a little bit about this and the idea of ensuring these sort of things are audited and traceable but theres a little more we have to worry about in this area. When it comes to risks that arise, we actually have to do something about them in order to mitigate. So this means once it is in that RAID document, we have to actually now manage the risk, carry out actions to mitigate it and update the document with status checkpoints, continuing to monitor the risk following the mitigation for a period. These are some questions you should be considering when it comes to risk management when governing your implementation projects.
Design too soon
A really simple one to mention is the need to not design a solution too early! It’s super important we gather all of the requirements needed to understand the issues and needs of an organisations department or the wider organisation prior to designing a solution. After all, we cannot build a solution which will deliver success if we don’t understand what we’re building something to resolve. Ensure you spend time on the requirements capture and workshopping stages with the business / organisation prior to moving into the design stage.
Project status
It may be a good idea to keep a high level RAG status on various categories that can be looked at with regard to a projects implementation. This may include things like RAG status on resource available, milestones and deliverables achieved in line with sprint planning, technical implementation issues and more. Having this kind of visible status somewhere in a simple high level graph or table makes it super easy to identify where a project could be going off track and allows the architect with the appropriate other roles to mitigate any risks noticed in the RAG.
Retros
One of the really important points for me that I’d like to finish on is almost actually the round up to the first point we discussed being sprint planning, and that is retrospectives. Retros are effectively recaps over the sprint that we have just delivered to ensure we worked against the sprint, and delivered as was required. This allows us to see if we missed things, or ran over and report back to the customer on current status but also allows us to then move those remaining items into the next sprint to be worked on. It also lets us look at any risks, issues or changes in the RAID that need attention.
What’s coming up?
So friends, in the next post we’ll look at some of the different roles and how they come into this idea of project governance and working in an agile fashion in a team. Stay tuned to get all the next posts in this wider series on solution architecture for the Power Platform! 🚀