Case : The implementation of a project approach

Background of the customer

Cepa cvba takes, on behalf of the cargo handlers, care of the social policy of all dockers (+-9000) in the port of Antwerp. They are active in 3 domains :

• Personnel management of dockers and a number of supporting services

• Social dialog between employers and unions in 2 joint committees (PC301 and PC226)

• Representation of intrest on a regional, national and international level

Within the operations of Cepa, there are 5 port-linked operational departments and 6 supporting operational departments. The latter do not only deliver services to the internal departments, but also to external port organisations and non-port related organisations. Two of these supporting operational departments are ICT and PMO.

The Objective

The ICT department consists of an Operations (infrastructure and Service Desk) and Development (develops several CEPA used applications and a Web-application for the cargo handlers) division.

Cepa wanted to move to a consistent and standard project approach and they had a desire to do it on 2 levels :

• A standard way of doing their projects. The standard project approach needed to be clear, open and understandable to all stakeholders.

• Implementing a development methodology The development methodology needed to allow rapid development in a business that constantly evolves and changes (because of legislature). It also should be able to respond quickly to interventions, project requests and changes. The methodology should allow to make a medium-long term planning and to report project statuses to all the different stakeholders and management

The process

Research

Given the requirements of the development methodology it became clear that Agile/Scrum would be the better way to go. It gives the possibility to respond quickly to change, to deliver output in a consistent way, with a totally open and involved communication with the stakeholders.

But since this project was not only implementing a methodology into development, it was necessary to have a governance layer on top of that. A governance layer that would allow to do projects in a standard way, where requests from stakeholders needed to be approved by the stakeholder's department head and the board of directors. Even before a project is defined in detail, an approval is required to be done by the directors whether the projects are acceptable regarding the business value, budget and ROI (return of investment) .

This resulted in combining a standard governance layer with an Agile/Scrum development layer.

Interviews

To find the right people for the right roles in the development methodology, we needed to have separate interviews with the people of the current development team (11 developers) to see whether we could fill the positions of the roles without having to expand the team. This would be the ideal case, because the current team members know and trust each other.

I have to say, we got pretty lucky here. We found a potential scrum master and a technical expert who were fit and up for the job.

Change management

Implementing the governance layer would have a huge impact on the organisation. We had to explain to the different departments the reason why we wanted to implement a standard approach and how we wanted to do this.

If you're working with people, you quickly realise that "change" is one of the hardest things to do and very important to the success of this project. Some people are easy going and some are resistant to change. So the change management on behalf of implementing a standard project approach was not to be underestimated. We needed to keep all the possible stakeholders in the loop of the process, inform them of new evolvements and ask for feedback on a regular basis.

Implementation

Agile/Scrum

This implementation was relatively easy. We informed all the team members through info sessions of what we were about to do, what Agile/Scrum was, and what the advantages of this methodology were.

At Cepa there was one catch though. We could not implement scrum in a traditional way where all team members work on one project. Every developer is working on a different project request (feature/change/new product). Depending on whether it was only front-end, back-end or a combination, it occasionally happened that they teamed up. So we had to be inventive and use the project request as if they were user-stories and user-stories as if they were tasks. Doing it this way we were still able to hold the key values of scrum and let the entire development team work on the same sprint goal.

We gave trainings on Scrum, the roles and the responsibilities thereof. After that, we implemented scrum in a phased way, so as not to make the change to big all at once :

Phase one : - Implementation of a product backlog (in case of Cepa this is a list of desired changes in different programs) and a scrum board - Start the daily standup : up and until this point, team members were hardly up-to-date with who was doing what and merely worked on their own island - War room and regularly timed demos

Phase two : - Creating tasks

- Review and retrospective meetings

Phase three :

- Sprint planning meetings with planning poker

Governance layer

We created a governance layer with 6 phases :

• Initiation : A project request is created by the project owner. The project request contains a project description, the reason for the request and a possible deadline because of legislature. This project request is roughly estimated in budget and sent to the board of directors for a first approval.

• Definition : After the first approval, a definition phase is started. Impact mapping, business analysis, functional analysis and feasibility are determined. From there a project plan is made and sent off to the project owner and board of directors for approval

• Planning : The project is being scheduled

• Implementation : the development team is working on the project in sprints. Every 2 weeks demo's are given and UAT's are performed with feedback to the development team

• Closing : the project is accepted by the project owner and a meeting about lessons learned is held between all members of the project team.

• Exploitation : the project goes LIVE

Statistics

Statistics were implemented in the project approach. Measurement is the only way to know how we are doing and to be able to set KPIs for the team.

We have statistics on :

• Sprints : number of projects done, number of interventions done, number of projects planned but unfinished etc

• Work : rate of billable hours, efficiency rate, rate of rework, etc

Conclusion

Implementing a totally new project approach within a company is never easy. Even though the implementation of Agile/Scrum was relatively easy, the implementation of the governance layer was not.

It's not only the implemention that makes it difficult, but the impact of the change is enormous for an organisation. If people are not aware and involved in the project (because of the lack of change management), it is doomed to fail.

For me as a project manager this was and still is a huge challenge. All of my skills are being called for. And even though the implementation is done ( in +- 6 months), we will need to guard the right execution of the plan, keep improving the statistics of the development team and keep coaching the entire organisation in doing a better job at project management and PMO levels.

A special word of thanks

A special word of thanks goes out to Lode De Maesschalck (Director of ICT and PMO, CEPA) and Filip Matton (PMO manager) for giving us the opportunity to do this project and for their support in writing this case study.