Typically, EPC projects are quite heavily loaded and complex which is why they follow traditional project management methods which help organize and segment tasks and time schedules. However, getting the project in the first place can be challenging. Competition and the initial investment can dictate the success of the delivery, and the particular values of such a project can be the determining factor for winning the project as a PMP. This is where the agile aspects of project delivery can make the difference, especially if there are software components involved.
For example, setting up a pilot or demo section for a larger railway project is great for defining how the installation needs to be done for each component used, and also to document each step properly. This will help loads in terms of organization and testing and is already a standard in this sort of large EPC project. As an additional aspect, the agile principle of measuring velocity and rhythm to define the best iterations for the entire project will be very helpful in delivering a successful project. In other words, the project will then be planned in sections to define practical iteration steps where a team can work independently from each other. However, the workload for each iteration is determined at the beginning of each iteration. Each completed iteration will give more accuracy on the velocity of the team performance and as well the work which could differ in an EPC project from section to section. And with this new understanding, the future iterations can be better predicted.
An agile approach is needed during the testing phase of a project. Especially for EPC projects which need to be integrated in a previously existing operational infrastructure, like an already running railway or highway etc. The testing for these previously existing and operational works usually take place during the night when these works aren’t in heavy use by the public. The agile approach here would be to finish the testing, regardless of the outcome. The test results will be recorded and if there are issues and mistakes, they will be fixed by a separate team ideally during the day. With this approach, the testing schedule will not be disrupted by immediate intervention during the valuable night hours and a separate team can take care during more convenient hours. It is also beneficial to measure the fault rating and its cost for repairing or fixing. If an issue or fault has been fixed, it needs to go onto the backlog for another night for testing (if it is required). The velocity for the testing iterations will give an idea of how much time an additional test will take and it provides a clear completion of the testing which leads into the commissioning.
In agile projects, the velocity is measured with story points which can be completed in one iteration. It can be arranged for an EPC project where the tasks have to be weighed with story points and how many tasks finally can be completed in one iteration. To make this clear for each iteration, the project team has to meet before the iteration starts and define clearly what workload can be achieved with the team at hand. Here I suggest to define an iteration for one week, maximum two weeks. If the workload is bigger for an iteration than before, perhaps the team size needs to be adjusted or the workload reduced to match the iteration schedule. Ideally, to give a steady pace to the team, the iteration steps should be fixed and adjusted accordingly.
The above makes a lot of sense to me personally as I have used it in practice over and over again in my large scale EPC projects. From my experience, the planning and clear definition of a working week or double week is more important for the team than just having a fixed work package over a long period. Long time planning is important to determine the end date, but from a psychological point of view, the continuous planning and execution iteration has higher priority as it provides the necessary results and the velocity of work performance which helps to determine the project completion. In case the project is delayed and a delay estimation is predicted, but the team is continuing with the same performance, the project cannot be rescued. To change the velocity is usually not easy as it is strongly related to the rhythm of the project. However, based on the information available, it is easier to define additional measures to cover for the loss of time; story points, velocity and rhythm. These terms are unique to the Agile model. Blending it into EPC projects provides additional dynamic for successful projects.
Wishing you well in your integrating agile methods into your EPC projects!