(Larson, E., Honig, B., Gray, C., Dantin, U., & Baccarini, D. (2014). Managing risk. In
Project management: The managerial process (6th ed., p. 223).
Considering the particular case of the QHS payroll system upgrade, the system lacked the implementation of step by step project management stages and at each stage, the outcome of the stage was not mature enough to start the next stage (Kloppenborg, 2009). For example, a poor planning phase will surely result in an unsuccessful project initiation phase. As per my knowledge, the approach to selecting the non-financial and financial project lacked the below-highlighted points :
During the project planning phase, QHS failed to identify the correct stakeholders and list them.
QHS did not distribute the plan in small modular projects like
- Creating the blueprint of the interim payroll system with all critical features required (non-Financial)
- New Payroll System Development (Financial)
- Procure infrastructure and required hardware and software for deployment (Financial)
- Training of staff for the new System (Non-Financial)
- Deployment and feedback of the system from staff (Non-Financial)
- Roll out the new system by rolling off the old system. (Non-Financial)
- Choose Agile model for development to incorporate timely feedback from customer
Create a phased delivery plan with the development vendor IBM
As per the Project Management standards, the initiation phase should result in a clear understanding of the scope and a backlog with all critical features identified. At the same, the budget allocation should be divided into hardware/infrastructure and then the IBM delivery resource cost (Verzuh, 2015). Another important factor about the initiation phase is identifying the role of the Program Manager, Development Team and Stakeholders also. For running the project in agile, the role of scrum master and product owner must also be identified.
Usually while implementing the program management methodologies, a risk register is maintained by the program manager and from time to time the risk register is updated by the product manager based upon the status of the project. The program manager also notifies the stakeholders about the identified risks and what could be done to mitigate the risk (De Meyer, et.al. 2002). Below is a list of risks and their possible mitigation from the QHS case study :
|Budget overshoot from time to time
|The program manager must keep a tab on budget and should have raised to stakeholders about the budget overshoot right from the beginning.
|Lack of a detailed plan of testing
|This one is the biggest risk while delivering a solution as lack of testing resulted in 3500 anomalies (Muriana & Vizzini, 2017).
|Absence of a mutually agreed scope
|The scope of the project was not discussed with stakeholders and hence it failed in the delivery of critical features.
|No accountability of roles
|Since the roles were not identified, there was no accountability associated with the leadership and that failed in accountability of the failure (Muriana & Vizzini, 2017).
|Absence of skillset
|Since IBM had not handled such large projects before, after some time after starting the project, it could be identified that we need an SME to run the project.
|No pilot for deployment (De Meyer, et.al. 2002)
|For such large systems, deployment must be done as a pilot for some users so critical failures/feedbacks can be registered in time and phased deployment will help fix show stopper bugs at an early stage (Muriana & Vizzini, 2017).
Had the above risks had mitigated in time, it could save a lot of money and effort from the QHS. Also, an update to the project documentation would help later analyses the project performance and support (Muriana & Vizzini, 2017).
A key point in the project initiation phase is to identify the list of stakeholders for the systems as they are the ones who drive the system development. The stakeholders are categorised into four categories:
- High impact high stake
- Low impact low stake
- High impact and low stake
- Low impact and high stake
That makes very clear the accountability of these stakeholders and a gap in identifying these people creates a lack of responsibility. Also, the role of the program manager is extremely critical in communication effectively the status to stakeholders. In the absence of stakeholders, the program is not driven in the desired direction (Hillman, et.al., 2001). As per the famous saying, the lack of communication or timely review with stakeholders results in producing an elephant while the requirement was to produce a goat. The least difference in the requirement v/s the outcome is the only measure of the success of a project or program (Eskerod, 2015).
Also, another failure from the leadership is lack of review and failure of timely correction in the plan. The stakeholders help in grooming the backlog for the development team and since that is not taken care of, the business-critical features are not prioritized and hence the system fails to comply with the use case (Hillman, et.al., 2001). In a healthy running program, the stakeholders are demoed at a regular interval with the status of the project to keep them aware and also get their feedback at the initial stage to mitigate the risk (Eskerod, 2015).
This case study is a classic example for the program manager to learn required lessons for any future projects they learn. While the theoretical program management concepts help all program managers align the project goals, the practical exposure to real projects helps them keep things afloat and practically viable (Kendrick, 2011). The case studies like QBS highlight how failure to comply with some basic results in big failures. Also, how Project closure is as important as other phases of the project as it completely determines the success or failure of the project overall. The feedback surveys, calculation of ROI, calculation of how much of business goals and identifying if any new phase is required are some important aspects of project closure that were completely omitted during the QHS case study. (Havila et..al, 2013) Some of the main lessons to be learnt from the above case study could be highlighted as below:
- The projects documents are extremely critical and well laid out project charter helps the whole team understand the common goals to be achieved.
- Program implementation methodology choice is instrumental to the success of any project. Hence enough time must be spent on choosing between waterfall, Agile or any other possible options.
- Strong leadership can only drive long complicated programs like QHS system payroll update. In absence of strong leadership, the team might feel lost and the outcomes could be difficult to achieve.
- The importance of following the program management fundamentals helps in keeping things on track and let the whole team view the status.
- Without proper testing and deployment strategy, a highly efficient development goal could get obsolete
- Budget allocation and resource allocation are continuous activity that must be carried out by the program manager from time to time.
- Timely escalations and alerts can help the team get back on track but in the absence of these alters and escalations, the whole team might miss the goal.
- Milestones and goals should be crystal clear and must be created such that they produce a meaningful output for the customer at the end of each milestone (Havila et..al, 2013).