Learnings

Outcomes

The key output of the project is a BAU-ready outage planning tool. The scope of the project was to develop and test the tool. Now that a BAU rollout has taken place, the following outcomes are expected:

-          Reduced number of outages impacting DER;

-          Asset Management/CPP can see there are third parties impacted by outages so can consider impact when looking further ahead to engage with Outage Planning and the customers;

-          Asset Management have view of tool to see all works in the future to allow them to see conflicting projects or works that can be aligned;

-          Cost savings due to fewer outage delays impacting major projects.; and

-          Internal cost savings due to efficiencies. Outages including overhead lines can cost £>10K in preparation costs, each aligned outage could save this amount which can scale up.

These will be verified after the 2021 outage season, as this will be the first full outage season since the tool was rolled out. 

Lessons Learnt

An agile approach to system design is an effective way to keep high levels of engagement across different potential business solution owners. However, this is a time and labour intensive process. There is an inherent risk associated with this approach that some key project stakeholders may not be available for the entire duration of the project or unable to commit to the time requirements. However this experience demonstrated that this risk is worth the benefits of an agile approach for a small-medium sized project. For a very large software development project, this may not be appropriate. 

When building a bespoke tool, it is important to consider what in-software notifications will be required. It is easy for users to assume that notifications will be introduced after general tool functionality is developed. However, different users have different perspectives on what constitutes a ‘logical’ or ‘obvious’ requirement for a notification. In-software notifications should be discussed specifically in early stage development workshops, and then re-visited regularly throughout the project. 

Regional differences between teams will impact the way a new tool is tested and used. Future projects should complete an assessment of the team that would look to adopt a tool or process developed in a project. If there are separate teams with some operational differences, every effort should be made to include all teams in the design, development, testing and trial processes. 

As a DNO, there were a number of important lessons learned that were specifically relevant to a cloud computing project. These lessons are unlikely to be novel learnings for other industries, however as this is not our key area of expertise, the learnings will serve us well in future:

-          When conducting user acceptance testing (UAT) of software, ensure all user roles are present for testing. Share UAT testing plan beforehand, and schedule the sessions so that the ‘smaller’ user types can participate just for the sections they are needed. 

-          There are a number of ancillary software requirements when carrying out a cloud computing project. These include cloud environments, any external cloud support if the in-house skillset is not significant, feature manipulation engine (FME) licences, cyber security testing

-          It is difficult to estimate the required budget and time required to complete a software build project from the outset. This is especially the case in building a tool for users that have not previously been involved with scoping and developing a new software tool. It is recommended that a detailed requirements or ‘discovery’ phase takes place before finalising the project timeline and budget. This could be approached in various ways, from implementing stage gates and/or splitting the project into separate phases.