“I’ve never been in doubt"
When Energinet.dk needed to upgrade their SCADA system, the heart of Denmark’s most critical infrastructure, they chose an untraditional project manager. In this interview, Helen Holdt tells us how she steered the project to success.
Interview with Helen Holdt, program manager
Could you describe the project briefly?
The project was an upgrade of Energinet.dk’s SCADA system (System Control and Data Acquisition), which controls the Danish electricity infrastructure. The system needed to be moved to a new platform with a new network, both in order to future-proof the system and to improve security. The upgrade was necessary to achieve the company’s strategic objectives in relation to sustainable energy. At the same time, the servers were on their last legs.
I took over the project in September 2013 with an analysis phase, and the upgrade got started in early 2014. The plan was to go live in November 2015, which we succeeded in doing.
What were your thoughts on your lack of experience with the energy sector?
I don’t have a degree in IT, but I do have an educational background in law, finance and business processes. Over the last 13-15 years, I’ve been responsible for a range of IT projects. No matter what the business, there are a variety of conditions, processes and working methods that apply to all IT projects and all IT support. I’m quite familiar with these conditions, and they are my primary tools in connection with any IT project. For all IT projects, I’m dependent on being able to draw on resources from the business and on making sure that we in the IT department understand what it is the IT deliverable is meant to support. And so it made no difference to me that I wasn’t familiar with the energy sector.
What did you think about the project when it was offered to you?
That it was big and incredibly exciting. That the project was important to Energinet.dk, which means a lot to me. Most clients have a lot of projects – I would like to have the project that’s most important to them, because that means it’s usually easier to get the project moving forward.
How did you approach it?
We made a contract with the supplier of the application, the French company GE, which required sub-deliverables in the form of 20-25 work packages, which meant that we received smaller deliverables on a regular basis. We asked GE to provide estimates and plans for delivery of each work package, for example delivery of a module or a specially coded functionality.
In addition, we also established a test strategy in the steering committee quite early on, which basically was that we should test as early as possible. When a sub-deliverable was delivered, we tested as much as we could for the given deliverable, where we worked with work packages and milestones.
In the test strategy, we and GE defined what was considered a minor error and what was considered a critical error. We worked with five categories in order to establish a shared understanding of the definitions. We practiced looking at results, at what it meant when corrections of errors were delayed, which were more important than others, and what it meant when there were x number of errors within each level (minor - critical). In the steering committee, we only looked at the number of defects within the different levels, whereas in the test strategy it was a question of what we would accept within each level.
Early on, we decided to involve the end-users in a go-live plan. We had a fall-back strategy as part of the go-live plan: if something in the plan started going badly after a few weeks, we could fall back on the earlier version of the system.
Was there anything that you hadn’t anticipated?
In a big IT project, new issues arise every day that no one has thought about. It’s a matter of how you handle these issues. I’ve never been in doubt about where we were going. We always managed to figure out who could help us move forward, or how we could solve our challenges together.
Which elements were important to the success of the project?
GE’s commitment, the project managers, the steering committee and the project room. In relation to the steering committee, what’s fundamental to every project is that it is able to stay on course despite difficult decisions. Here the steering committee’s extremely competent chair, Jens Møller Birkebæk, played an central role. I cleared difficult decisions with him, after which either he or I discussed them with the other members if there was anything that needed to be clarified.
The steering committee had a good understanding of the business and the deliverables, and was good at handling difficult challenges, which is also central to every project.
What did the project room mean for knowledge sharing?
People sat in the project room when they were working on the project. It quickly filled up with posters of integrations, the platform and work packages, which we used in different ways. For example, we wrote the names of the individual deliverables on the work packages poster, along with their status and when they were scheduled to land. From the beginning, we used these posters to communicate how far we had progressed. Having them hanging in the project room really helped the project group communicate.
In addition, one of our minimum requirements was that the French supplier GE had to be present and participate in testing in the project room along with us every time they delivered a work package that was ready for testing.
All of the project participants came to like the project room, and after a couple of months, it was functioning as the primary tool in relation to our ability to work together and make what we were doing visible.
What other tools did you use to create an overview of the project?
SharePoint for gathering documents in one place, and Energinet.dk’s intranet.
The biggest challenges along the way?
The usual challenges, such as: getting enough resources allocated; getting people to work together instead of passing the ball; getting the right resources at the right times – both from Energinet.dk and GE. The latter problem mostly applied to us, but it’s very common in this type of project.
For example, it took a little time to get Energinet.dk’s staff down to the project room, but it was important for communication and cooperation in the entire project group (Energinet.dk and GE). If you only communicate by mail, you lose valuable information and time. If it takes more than two or three mails to clarify something, it’s time to pick up the phone or sit down together.