What is your current position, what are your missions?
I am the manager of the one-man company Oraone. I am a senior consultant, project manager and trainer. I have an engineering degree in computer science which allowed me to develop these professions.
How did you hear about AgilePM, what was your initial need?
I had already started to study and apply the Good Practices in project management such as PMP and PRINCE2®, in a rather traditional way, but I wanted to discover the agile world and see what these methods and techniques could bring to my projects. I followed a PSD (Professional Scrum Developer) training course, but I was stuck in the end in terms of project management, particularly in terms of governance. I then followed an AgilePM training course, based on the DSDM (Dynamic System Development Method) framework, where I was able to find the rigorous side of the PRINCE2 method, but with the specificities of agile project management.
Did you use the AgilePM method, following your training, to manage certain projects?
Yes, absolutely, I can provide the example of my first project with AgilePM, which is still relevant today. It was a medium-sized project in the aeronautics sector which lasted for a long time. The project was started using PRINCE2, which was particularly well suited to the needs and requirements of the time. However, we encountered a number of problems throughout the project, in particular interconnection problems with IT, but also performance and security issues… To solve this, my client’s IT team was trained in the AgilePM method, which made it possible to improve collaboration between the various departments and to define new roles, which were necessary for the project to run smoothly. For example, a business analyst from the IT department was put in place and supported the aviation business unit. From then on, everything was simplified, both the work and the integration between IT and the business units.
Once the first product was delivered, there were updates every year, hence the usefulness of switching to agile mode to manage the rest of the project. Since agility is very well positioned to keep updating an existing product, there is continuous improvement. However, agility does not mean there is no control and this is the strength of AgilePM. The method enabled me as the consultant/external supplier, as well as the IT department and the aircraft business unit, to keep rigorous documentation while setting up an efficient monitoring process. This prevented us from losing all the processes put in place for the first version of the product. We also took advantage of regular agile meetings, which enabled us to work better together as a team.
What were your constraints and challenges?
On the one hand, there was the challenge of improving the working relationship with the IT department, so that the integration and updates of the product went well. The AgilePM training of the team allowed to create a common vision and build fundamental values to facilitate relations but also connect the various services and business units. This resulted in acceleration of the project.
On the other hand, AgilePM facilitated continuous improvement, which requires keeping up to speed with a backlog of possible improvements. AgilePM is the ideal method for this as it includes these Agile techniques: MoSCoW prioritisation and Timeboxing. At the beginning of each release, we could take this backlog and predict what we would do to solve the next increase.
Finally, when working on continuous improvement, agility becomes almost a necessity. The Scrum framework might have done the trick for this project but it did not allow for the rigour imposed by AgilePM. Moreover, there are 3 roles in Scrum, whereas AgilePM has about ten. This makes it possible to position roles that would be on the IT side, as well as on the supplier, the customer and business side. We can see very clearly this breakdown of the different roles which are very important from the moment we start a project. If we are only performing development on existing products with small backlogs of products that need to be corrected, then Scrum is suitable. However for project management, I recommend the AgilePM method, which allows the interaction of different roles, knowing who does what and allowing you to interconnect. If I take my own example as a supplier and as project management support; I needed to have precise specifications on project requirements and management.
How did the implementation of the method go?
The implementation went quite smoothly as the IT team had been trained and the aircraft business unit team knew the method (I could also help them with this). We were able to start immediately to clearly define roles, break down the list of requirements, monitor progress at regular progress meetings, while keeping the documentation in place and up to date.
The business analyst played a key role in the success of the project, being available to support the project and facilitate understanding between all departments (IT and business).
I think it is important to emphasise this role, which is found in AgilePM and not necessarily in other agile methods. As there were initially some communication difficulties between internal IT- and the aviation business units (the company being large, the IT department has to interact with many business units, not only the aviation part), the choice of the business analyst was crucial. The business analyst in question had a very good understanding of the issues of the various stakeholders including the needs of the aircraft BU. In particular this was about modernising their documentation and the needs/limitations/constraints of the IT department.
How did the AgilePM method help you? Which part was most useful to you?
Various elements of the method helped us, on the one hand the strictness imposed by AgilePM to maintain the quality of the documentation. On the other hand the fundamental values facilitated the communication and collaboration of the teams. In addition, the importance of roles, necessary for the distribution of tasks and especially of responsibilities, is also important. Finally, and this is the key point of the method, in my opinion, the effectiveness of the agile techniques “MoSCoW” and “Timeboxing” on which AgilePM is based.
Indeed, AgilePM is based on the MoSCoW/Timeboxing combination, which can be found or used outside AgilePM, but at least this method has the merit of clearly defining these techniques as essential. Without the MoSCoW technique, teams cannot deliver on time at the end of the timeframe. These techniques make it possible to define the duration of a timeframe and to commit to delivering what is needed at the end of the defined time. This forces the customer to structure his need, to explain it in terms of the “absolutely necessary” (vital), “should be done” (essential), “could be done” (icing on the cake) and “will not be done this time but maybe later” functionalities. With AgilePM, the duration is fixed whereas with traditional methods, there is a tendency to push the delivery date back when time is short. Therefore, with AgilePM, the team delivers, perhaps a little less at a time, but in time, the priority items.
Have you encountered any reluctance to change and agile transformation?
We have encountered a classic reluctance to agile, i.e. the sponsor, who plays a financial role and agrees the budget, very often wants all priorities to be “MUST”. So there is a reluctance to understand that they are going to pay for things that “might” only be delivered. In our project for example, the documentation manager had to propose the project and the budget for approval by the management (the sponsor). It turned out that it was difficult to get a budget understood and accepted if you didn’t evangelise about agile to the decision makers beforehand and explain how the agile project management mindset works.
Do you have any advice for professionals in the sector?
You realise that a project like this, which could perhaps have been done purely in traditional mode in one go, over two or three years, would not have been as effective in the end. Indeed, thanks to agility, this project was carried out over five years, in an incremental way. This welcomed customer feedback after each version, which led to major strategic changes as well as continuous improvements that created value. This formed a solution that was sometimes far from the one initially thought of, but which finally matched and met the customer’s needs perfectly. This would not necessarily have been the case with a traditional working method.
Skip to content
