My role in a DORA project was both from a risk management expertise and a lead for the strategy and governance parts.
Knowing what I know now, I think I would have loved to be the programme manager for it. 😁
The role of the programme manager is fundamental. He or she will need to be the link between some very strategic sponsors and the project team. They must understand DORA – what is DORA, to which of your divisions applies, what portfolio (not all financial services are impacted) is under DORA, what knowledge and skill gaps you have in the business and how best to resource those gaps.
Other success factors are presented below.
EXPLORATORY APPROACH
I would take an approach similar to product development, EXPLORATORY. Start from a set of requirements and explore possibilities of compliance. Involve many perspectives and people. Brainstorm ideas. Test and learn. The opposite approach is command-and-control. You use command-and-control in crisis situations but using it in the design phase simply limits the options. The SPONSOR should be a facilitator for exploring the best ideas.
PROJECT OBJECTIVE
This is very clear – to be DORA compliant. The project objective should then INFLUENCE ALL THE DECISIONS : e.g., the external consultant profile, the type of contractor used (for areas where you lack expertise), what tools you will use, budget. For example, you will need an asset inventory. Is excel good enough given the complexity of your IT architecture? Would a more sophisticated asset inventory tool put you in a better COMPLIANCE position?
UPFRONT TRAINING ON ROLES AND RESPONSIBILITIES IN THE PROJECT
What is the role of the SPONSOR, PROGRAMME MANAGER, PROJECT MANAGER? Authorities? Can the PROGRAMME MANAGER challenge the SPONSOR? In which situation? What is the role of the EXTERNAL CONSULTANT?
UPFRONT TRAINING AND AGREEMENT ON DORA REQUIREMENT
Facilitate an agreement session. I would put the requirements on a screen. For each requirement I would facilitate a discussion. This is also a brainstorming session as part of the exploratory approach. It is unacceptable that the project team does not know the DORA requirements and deliver what they THINK DORA requires.
SMALLER PROJECTS AND DELIVERABLES
The monster separated in small deliverables that you can deliver quickly, celebrate the success to create momentum and have the power to move forward. I even celebrated the risk taxonomy. I needed the boost to make the team to get going.
CONCLUSIONS
I led the strategy and governance workstreams, with eight deliverables. For each of the deliverable, I created a concept paper with the following sections:
· DORA requirement. The exact DORA wording and related standards.
· Consultants’ initial recommendations.
· Proposed (by me) solution.
· Validation of solution by consultants.
· Action plan.
I then scheduled one hour meeting with my team to discuss the solution and action plan and from there I just monitored the action plan.
Posted initially on LinkedIn: Claudia Craia
One response to “DORA Part 2 – Approach to DORA implementation”
[…] Part 1 – High-level conclusions after working on a DORA project· DORA Part 2 – How I would approach DORA implementation now· DORA Part 3 – My thoughts on how the project team should look· DORA Part […]