In project management there are lots of discussions around the management of scope and budget for a successful project. I was reading an article around embracing the twists and turns in project management, and I thought back to our class project with marshmallows and spaghetti. The winning team may not have used their entire budget but still had the best outcome of the class, so was that a successful project? Can a project still be successful if we allow for uncertainties that arise during the project?
The article discussed how risks or uncertainties that arise are often viewed as setbacks to a project, but some project managers fail to see them as a potential for opportunity. The article identified four categories of potential opportunity; Technical Innovation, Implementation Processes, New business and Value beyond the initial scale. In addition, it covered 6 primary types of uncertainty; Contextual Turbulence, Stakeholder Fluctuations, technological Uncertainty, Project Uncertainty, Organizational Uncertainty, and Malpractice.
I’m currently engaged in an Oracle ERP upgraded, which is being overseen by an ePMO but implemented by different functions, and I have the HR module. The scope of the project is to get the full organization aligned with one global ERP. The HR function was the original adopter of Oracle and was on an outdated system so to get to the common platform we anticipated having to go through 2 upgrades, one to stabilize and meet the company on a common platform and the 2nd to move to Oracle Fusion to deliver the needed functionality. After the initial move and utilization of the system an uncertainty popped up around process and functionality, and since we were implementing plain vanilla out of the box we saw an issue where the system no longer supported us in the customized way in which we were used to operating. Instead of moving forward with the next phase, we decided to take a step back and map our processes to fit the system, instead of the other way around. Since we didn’t know the new system this was unexpected for us, which resulted in being behind schedule but under budget and without pain points that other functions are feeling.
I think you bring up a good point. Many project managers view setbacks as obstacles that need to be blazed through to meet a deadline. In your case, the setback informed you that the software was not performing the functions you were ultimately needing. I think setbacks are beneficial only if there is open communication with the team and the project manager. If the project manager can openly listen to feedback and adapt the plan, then setbacks can be viewed as opportunities not problems.
Interesting post. Typically set backs can bring delays in project milestones, but sometimes they act as good “breaks” to avoid bigger issues further down the road. As long as you have valid reasons for set backs, scope changes, unfavorable condition, etc. and as long as there is open communication with the team, I believe set backs might be “justifiable” and good for project.
While many project managers see setbacks as delays to meeting the deadlines, they can be very beneficial as well. It is important for project managers to fully understand setbacks. Similar to your case, when setbacks take place they can bring up valid reasons that the path you are taking may not be the right one. As groups work on different project work streams, they may come up with valid reasons why path should be changed. It is important not just to identify what the setbacks are, but how they can be solved. They can be seen as blessing in disguise, just like in your case.