AgilePM Success Story: Smals Interview with Karine Picart

Smals is the joint ICT organisation of Belgium’s public social security institutions.
It realizes innovative ICT projects and services in the line of work, family and health for social security and healthcare institutions and offers them a wide range of ICT services.

ICT for society is not just a slogan for Smals; Smals participates in pioneering work in e-government and e-health in Belgium and is an important factor in the digital transformation of social security and healthcare.
They are also active in the development of the G-Cloud, the Belgian government cloud.

To hear how they apply the AgilePM methodology, QRP interviewed Karine Picart.

 

What is your role at Smals?

I am responsible for the SharePoint Competence Centre at Smals, the joint ICT organisation of Belgium’s public social security institutions. I am a project manager in charge of the SharePoint projects that are entrusted to us by our members.

 

How did you hear about AgilePM and what was your initial need?

AgilePM training is part of our training catalogue.

I was looking for an agile method and I knew that the Scrum approach – which is also used at Smals – is primarily designed for software development teams. We had previously tried to implement this approach on SharePoint projects but it had not been convincing.

I was looking for a more global approach that also integrates project management, which would allow us to better involve the business representatives in our projects to ensure we are working on the things that mattered.

 

Shortly after AgilePM training you successfully applied it to key projects. Can you explain the background of the projects?

The first project on which we applied the AgilePM approach concerned a Belgian social security institution that wanted to renew two applications, which previously existed in Lotus Notes, into SharePoint applications.

These were two large pilot projects (a request management application and an internal communication portal) which would also allow them to develop their SharePoint and project management skills.
We implemented the AgilePM approach and it went very well; we were very satisfied for many reasons.

Following my training, I trained one of my colleagues to act as an architect/developer/technical coach to the customer. The aim was to ensure that the approach to the projects was well understood on the customer 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 business 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 requirements as must-haves in the first round).

 

What were your constraints and challenges?

The first challenge was that of coaching, as part of the team was not my usual team.
The second challenge was to make sure that the whole project team followed the rules, the vision and the issues.

One of the developers who were very good technically was, for example, not convinced by the AgilePM approach; he was a bit sceptical at first. But he finally played the game and was able to see the logic of the approach and that relations with the business went very well. The clients also appreciated working in an agile way thanks to AgilePM, which allows the business to be much more involved in the project and in day-to-day decisions.

It is not unusual for the business to think something is simple, but being involved makes them better understand the task and associated challenges. Conversely, the developers have a better understanding of the underlying needs.

The AgilePM approach allows for a transparent dialogue and the right choices to be made, without the development teams getting hung up on things that are not so important to the client/business.

The clients expected the project to progress (and results materialize) quickly without setting a deadline (which can be a trap as it can take much longer than necessary). However, we managed 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 simply preferred to wait and solve the network problem rather than deliver a tool that would have been perceived as underperforming, even if the cause was external to the tool.

 

How did you implement AgilePM?

After the coaching and kick-off, we set up sprint review/sprint planning meetings every fortnight for each of the projects, which meant that one project would be dealt with one week and the other the next, and so on.

One of the two business ambassadors would automatically attend 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 involving the project team (business and technical contacts).

We organized a monthly one-hour project board and that was enough to follow the progress of the project.
It is important not to go into too much functional or technical detail during the project boards, but to stay focused on the project monitoring.

Once this monitoring structure was in place, the project almost ran itself!

At the end of the project, we carried out a remote lessons-learned exercise and the feedback from the client was that, in the beginning, they did not necessarily understand what had been 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 the reason for the intensity of the efforts. For a future project, we will pay more attention to this dimension.

The client was also unaware at the beginning of the effort that it would require on their side. Being a business ambassador is almost a full-time job and it’s important that they are given the time to carry out this important role. There are various meetings to attend and you also have to be ready to address questions and concerns from the development team on a daily basis, participate in tests, etc.

How did the AgilePM approach help you?
Was there a particular element that was most useful to you?

The most useful in my opinion is the MoSCoW prioritisation technique.
There is a big difference between ranking the requirements in an order (1-2-3-4-5) and accepting that a requirement that you consider important is only a “should-have” that may never be implemented because other requirements come first.

Continuous prioritisation is probably THE most useful aspect.
Of course, this is not the only point, the whole framework is useful.

 

Do you have any advice for fellow project professionals in the sector?

You have to get trained.
I recommend taking a training course with an expert and not just watching, reading the book and picking up elements according to what speaks to you.

I took a training course in a small group and it allowed me to understand the method, to have templates and to ask my questions. Personally, without the training, I would never have read the whole manual and I would have missed key benefits of the method.

 

A few words to conclude?

Recently I also attended a DevOps course and I can see that the two fit together well as the philosophy and culture are similar.

 

→ Curious to read another AgilePM success story?
Read on how FLIR implemented the AgilePM methodology in their daily work.

 

Karine Picart

Karine is Project Leader & Team Leader at Smals. She is a specialist in collaborative tools and is responsible for the Smals SharePoint competence centre.