With the company’s mission and vision in place, my colleagues and I could start the analysis of the project. The maritime company needed a new module for their ERP software to automate the purchasing department’s procedures and integrate their orders (POs) with the Accounting department.
First meetings were of crucial importance to uncover what the customer really needed. I was responsible to understand the technical part of what we had to deliver. However, we couldn’t define specific features and goals as the client knew what they wanted only in terms of high-level project deliverables
We decided to follow a traditional project management method (Waterfall) and develop a work breakdown structure (WBS) as the basis for a detailed project schedule and resource plan. The project manager had also to select the human resources who will be allocated to the project and will be assigned work. The team was mostly consisted of software developers and business analysts.
In the planning phase of the project, we analysed the business needs and collected the requirements. It is essential part of the process to summarize on a document what has been agreed with the client and clearly state the requirements and objectives of the project, especially in a Waterfall project.
Generally, in large and complex projects it is reasonable to expect changes to the initial planning. People usually change their minds about the requirements because the marketplace changed or because they missed a requirement or even because they didn’t understand their actual need. Depending on the project management methodology, changes are either well accepted or subject for discussion between the vendor and client.
In our case, the problem started when in the middle of the project our client requested changes to the initial requirements. From a non-technical perspective, the requests could be classified as minor changes and the project was planned to run for 9 months, so many of my colleagues thought that there is available time to change our plans. In my opinion, though, the changes were affecting the core infrastructure of what we had already developed. This means that a lot of time was needed to re-develop the software if we had to accept the amended requirements. After analysis, we found that, indeed, about two more months were needed to implement the change requests. This extra implementation time created a major issue internally in the company as we were running the project with Waterfall.
In the planning phase, the project manager conducted a risk analysis to determine which factors may affect the normal execution of the project. The PM didn’t have a technical background in software development, so I was responsible to inform him about any technical subject and together analyse potential risks in the technical part. However, no one is able to identify all risks with certainty at the begging of the project.
Although we had identified the risk of potential changes to the initial requirements while the project was underway, we chose to execute the project with the Waterfall PM methodology. If we had used the Risk Categorization Framework, instead of using just a list of risks to organize the risks, we would be able to effectively address this high of importance risk and take preventive actions and.
Furthermore, I believe that the project manager’s role could have been performed more effectively if we had followed an agile project management approach instead of a traditional one. Agile projects embrace change, accepting the idea that requirements will evolve throughout a project. Agile was created because projects cannot always be planned entirely from the planning phase. Especially in software development, the likelihood that changes will occur is high.
As a vendor, we had two options; either stick to the agreed requirements and reject the requested changes or to accept them. Accepting the changing would affect our cost estimation though.
Eventually, after a lot of internal meetings for defining our strategy regarding the issue, we decided to accept the amended requirements. Customer satisfaction is one of our top priorities. However, we knew that it would be costly since we had to increase the team of programmers to meet the deadlines. As a result, these significant cost overruns put pressure on profit margins.