With this successful application of the Agile PM approach, you can read that Scrum and the Agile PM approach can work well together. It is precisely the combination with some project management aspects that makes the difference here. Namely, monitoring by a Project Board was helpful here. In addition, the MOSCOW prioritization technique has helped them the most.
This is in line with the experience of my colleague Natasja Spaans, who wrote in her previous blog about the added value of a “scope governance board”. There also appears to be a need for a coordinating body that organizes coordination around scope, prioritization and budget.
Smals is the joint ICT organization of the public social security institutions in Belgium. They realize innovative ICT projects and services in the field of work, family and health for social security and care institutions and offer them a wide range of ICT services.
'ICT for society' is not just a slogan for Smals; they participate in pioneering work in e-government and e-health in Belgium and are a key player in the digital transformation of social security and healthcare. They are also active in the development of the G-Cloud, the Belgian government cloud.
Karine Picart
Karine is Project Leader & Team Leader at Smals. She is a specialist in collaborative tools and is responsible for the SharePoint competence center of Smals.
What is your role at Smals?
I am responsible for the SharePoint Competence Center at Smals, the joint ICT organization of the Belgian public social security institutions. As a project manager I am responsible for the SharePoint projects entrusted to us by our members.
How did you get to know AgilePM and what was your first need?
The AgilePM training is part of our training catalog. I was looking for an agile method and I knew that the Scrum approach - which is also used at Smals - is mainly intended for software development teams. We'd tried to apply this approach to SharePoint projects before, but it wasn't convincing. I was looking for a more global approach that also integrates project management, which would allow us to better involve business representatives in our projects to make sure we're working on the things that matter.
Shortly after the AgilePM training you have successfully applied this to important projects. Can you explain the background of those projects?
The first project to which we applied the AgilePM approach involved a Belgian social security institution that wanted to renew two applications, which previously existed in Lotus Notes, into SharePoint applications. These were two major pilot projects (a request management application and an internal communication portal) that would also allow them to further develop their SharePoint and project management skills. We implemented the AgilePM approach and it went very well; we were very pleased for many reasons.
After my training, I trained one of my colleagues to act as an architect/developer/technical coach for the client. The aim was to ensure that the approach to the projects was well understood on the client side and to encourage maximum engagement.
We briefed our business (business ambassador) and technical (developers) contacts at the same kick-off for both projects. I explained the method, the roles and responsibilities of each, and how it would work. At the end of the kick-off, we gave the company the task of creating a first version of the backlog by describing their requirements and prioritizing them according to the MoSCoW prioritization technique (Must have, Should have, Could have, Won't have this time). The challenge was to designate 60% of the total project effort as must-haves, which can be difficult (often we get 70 or even 80% of the requirements as must-haves in the first round).
What were your limitations and challenges?
The first challenge was that of coaching, as part of the team was not my usual team. The second challenge was to ensure that the entire project team followed the rules, the vision and the issues. For example, one of the developers who was technically very good was not convinced by the AgilePM approach; he was a little skeptical at first. But in the end he played along and was able to see the logic of the approach and the relationship with the company went very well. The customers also appreciated the agile way of working thanks to AgilePM, which makes the company much more involved in the project and in the day-to-day decisions. It's not uncommon for the company to think something is simple. But by being involved, they better understand the task and its challenges. Conversely, the developers have a better understanding of the underlying needs. The AgilePM approach makes it possible to have a transparent dialogue and make the right choices, without the development teams getting stuck in things that are not very important for the customer/business.
The clients expected the project to progress quickly (and deliver results) without setting a deadline (which can be a pitfall as it can take much longer than necessary). However, we were able to deliver quickly and within three months we were ready to go live. There were some network performance issues that prevented us from going live as planned, but we were ready. We preferred to wait and fix the network issue rather than deliver a tool that would have been perceived as substandard, even though the cause was outside of the tool.
How have you implemented AgilePM?
After the coaching and kick-off, we set up sprint review/sprint planning meetings every two weeks for each of the projects, which meant that one project would be covered one week and the other the next, and so on. Each of the two business ambassadors attended the other's meetings to ensure consistency in decisions as we were working on the same technical platform. Every day there was also a 15 minute stand-up meeting with the project team (business and technical contacts).
We organized a monthly project board of one hour and that was enough to follow the progress of the project. It is important not to go too much into functional or technical details during project councils, but to stay focused on project follow-up. Once this monitoring structure was in place, the project almost ran on its own!
At the end of the project, we performed a lessons-learned exercise remotely. The feedback from the customer was that at the beginning they didn't really understand what was explained during the kick-off, nor why we were asking for certain things. However, as time went on everything became clearer, they understood why and why we worked so intensively. For a future project we will pay more attention to this aspect.
The client was also unaware of what it would require on their part at the beginning of the effort. Being a company ambassador is almost a full-time job and it is important that they are given the time to perform this important role. There are several meetings to attend and you must also be ready to answer questions and concerns from the development team on a daily basis, participate in tests, etc.
How has the AgilePM approach helped you? Was there a particular element that was most helpful to you?
The most useful, in my opinion, is the MoSCoW prioritization technique. There is a big difference between arranging the requirements in an order (1-2-3-4-5) and accepting that a requirement you care about is just a "should-have" that may never be implemented because other requirements come first. Continuous prioritization is probably the most useful aspect. Of course, this is not the only point, the whole framework is useful.
Do you have advice for fellow project professionals in the sector?
You must be trained. I recommend getting training from an expert and not just trying it, read the book and pick out only those elements that appeal to you. I followed a training in a small group and that allowed me to understand the method well, to create templates and to ask my questions. Personally, without the training, I would never have read the entire handbook and would have missed important benefits of the method.
A few words to conclude?
Recently I also took a DevOps course and I can see that the two are a good match because the
philosophy and culture are similar.
Source: APMG International, QRP Developing Professionals, APMG International AgilePM, Agile Business Consortium
With this successful application of the Agile PM approach, you can read that Scrum and the Agile PM approach can work well together. It is precisely the combination with some project management aspects that makes the difference here. Namely, monitoring by a Project Board was helpful here. In addition, the MOSCOW prioritization technique has helped them the most.
This is in line with the experience of my colleague Natasja Spaans, who wrote in her previous blog about the added value of a “scope governance board”. There also appears to be a need for a coordinating body that organizes coordination around scope, prioritization and budget.
Smals is the joint ICT organization of the public social security institutions in Belgium. They realize innovative ICT projects and services in the field of work, family and health for social security and care institutions and offer them a wide range of ICT services.
'ICT for society' is not just a slogan for Smals; they participate in pioneering work in e-government and e-health in Belgium and are a key player in the digital transformation of social security and healthcare. They are also active in the development of the G-Cloud, the Belgian government cloud.
Karine Picart
Karine is Project Leader & Team Leader at Smals. She is a specialist in collaborative tools and is responsible for the SharePoint competence center of Smals.
What is your role at Smals?
I am responsible for the SharePoint Competence Center at Smals, the joint ICT organization of the Belgian public social security institutions. As a project manager I am responsible for the SharePoint projects entrusted to us by our members.
How did you get to know AgilePM and what was your first need?
The AgilePM training is part of our training catalog. I was looking for an agile method and I knew that the Scrum approach - which is also used at Smals - is mainly intended for software development teams. We'd tried to apply this approach to SharePoint projects before, but it wasn't convincing. I was looking for a more global approach that also integrates project management, which would allow us to better involve business representatives in our projects to make sure we're working on the things that matter.
Shortly after the AgilePM training you have successfully applied this to important projects. Can you explain the background of those projects?
The first project to which we applied the AgilePM approach involved a Belgian social security institution that wanted to renew two applications, which previously existed in Lotus Notes, into SharePoint applications. These were two major pilot projects (a request management application and an internal communication portal) that would also allow them to further develop their SharePoint and project management skills. We implemented the AgilePM approach and it went very well; we were very pleased for many reasons.
After my training, I trained one of my colleagues to act as an architect/developer/technical coach for the client. The aim was to ensure that the approach to the projects was well understood on the client side and to encourage maximum engagement.
We briefed our business (business ambassador) and technical (developers) contacts at the same kick-off for both projects. I explained the method, the roles and responsibilities of each, and how it would work. At the end of the kick-off, we gave the company the task of creating a first version of the backlog by describing their requirements and prioritizing them according to the MoSCoW prioritization technique (Must have, Should have, Could have, Won't have this time). The challenge was to designate 60% of the total project effort as must-haves, which can be difficult (often we get 70 or even 80% of the requirements as must-haves in the first round).
What were your limitations and challenges?
The first challenge was that of coaching, as part of the team was not my usual team. The second challenge was to ensure that the entire project team followed the rules, the vision and the issues. For example, one of the developers who was technically very good was not convinced by the AgilePM approach; he was a little skeptical at first. But in the end he played along and was able to see the logic of the approach and the relationship with the company went very well. The customers also appreciated the agile way of working thanks to AgilePM, which makes the company much more involved in the project and in the day-to-day decisions. It's not uncommon for the company to think something is simple. But by being involved, they better understand the task and its challenges. Conversely, the developers have a better understanding of the underlying needs. The AgilePM approach makes it possible to have a transparent dialogue and make the right choices, without the development teams getting stuck in things that are not very important for the customer/business.
The clients expected the project to progress quickly (and deliver results) without setting a deadline (which can be a pitfall as it can take much longer than necessary). However, we were able to deliver quickly and within three months we were ready to go live. There were some network performance issues that prevented us from going live as planned, but we were ready. We preferred to wait and fix the network issue rather than deliver a tool that would have been perceived as substandard, even though the cause was outside of the tool.
How have you implemented AgilePM?
After the coaching and kick-off, we set up sprint review/sprint planning meetings every two weeks for each of the projects, which meant that one project would be covered one week and the other the next, and so on. Each of the two business ambassadors attended the other's meetings to ensure consistency in decisions as we were working on the same technical platform. Every day there was also a 15 minute stand-up meeting with the project team (business and technical contacts).
We organized a monthly project board of one hour and that was enough to follow the progress of the project. It is important not to go too much into functional or technical details during project councils, but to stay focused on project follow-up. Once this monitoring structure was in place, the project almost ran on its own!
At the end of the project, we performed a lessons-learned exercise remotely. The feedback from the customer was that at the beginning they didn't really understand what was explained during the kick-off, nor why we were asking for certain things. However, as time went on everything became clearer, they understood why and why we worked so intensively. For a future project we will pay more attention to this aspect.
The client was also unaware of what it would require on their part at the beginning of the effort. Being a company ambassador is almost a full-time job and it is important that they are given the time to perform this important role. There are several meetings to attend and you must also be ready to answer questions and concerns from the development team on a daily basis, participate in tests, etc.
How has the AgilePM approach helped you? Was there a particular element that was most helpful to you?
The most useful, in my opinion, is the MoSCoW prioritization technique. There is a big difference between arranging the requirements in an order (1-2-3-4-5) and accepting that a requirement you care about is just a "should-have" that may never be implemented because other requirements come first. Continuous prioritization is probably the most useful aspect. Of course, this is not the only point, the whole framework is useful.
Do you have advice for fellow project professionals in the sector?
You must be trained. I recommend getting training from an expert and not just trying it, read the book and pick out only those elements that appeal to you. I followed a training in a small group and that allowed me to understand the method well, to create templates and to ask my questions. Personally, without the training, I would never have read the entire handbook and would have missed important benefits of the method.
A few words to conclude?
Recently I also took a DevOps course and I can see that the two are a good match because the
philosophy and culture are similar.
Source: APMG International, QRP Developing Professionals, APMG International AgilePM, Agile Business Consortium
It is our mission to help customers get their change ambitions to come true.
Our location in Amersfoort is located directly opposite the main entrance of the NS station and is therefore easily accessible by public transport.
If you come by car, it is best to park at the Q-Park P+R Barchman Wuytierslaan, approximately a 5-minute walk from our office.
