When I was a recruiter for an IT staffing firm, I would always wonder why IT firms would reach out to our office with a hiring manager in need of a contract software developer for one of their projects. These hiring managers were either Project Managers, Program Managers, or Release Managers, that had a group of software engineers that rolled out new software for their company. Our staffing agency sought out for these types of projects, and would find contract workers for these hiring managers on their SDLC projects. There is always a need for contract workers, especially for technology companies that run multiple projects. When reviewing project management topics, risk management seems to be a likely area where project manager’s account for staffing needs.
My curiosity lead to me to an article on how project managers account for risks in their SDLC projects. The article addresses risk management as a general approach for all project’s, and below are steps for project managers to follow:
1. Risk identification
2. Negative impacts
3. Prioritizing risks
4. Risk management or risk treatment
5. Auditing the risk management plan
The article states that firms can either have a full-time Risk Officer, or the responsibility be delegated to the project manager. It seems in my experience, the latter is true, where the project manager takes the lead on the risk management plan. Hence, why the contingency plan of needing additional human capital to fulfill the project included a staffing agency. However, the article addresses the importance of having a risk management plan based on the phases of the SDLC. Let’s briefly discuss what these phrases look like, and how a risk management plan is incorporated into each step.
There are five stages in a software development life cycle, and the stages include; inception, design, implementation, maintenance, and audit or disposal. For each of these steps, the article suggests what should be done to develop the risk management plan. In the inception phase, the engineers talk through some the risks associated with the software. The second step is the design phase, where the engineers take the risk into account, and how their software will support or manage the risks associated. Generally, these include a set of checklists that the engineers address when designing their software. The next stage is implementation, and in this stage, there are tests conducted to test where the software can pass the associated risks. The third stage, the article stresses the importance of ensuring the risks are passed, before going live. The fourth stage includes maintenance of the software, and problems generally occur in this stage. These problems are where the engineers debug the issues, and maintain the system to run as designed. The risk management plan takes into account that there will be problems with the system, and understands that if the system needs to be changed or altered, the risk plan accounts for alterations of the system. The final stage is auditing the system or disposing it, where the risk management plan refines the system.
When reviewing how the risk management plan fits into a software lifecycle, I understand why Project Managers can utilize contingency workers for their projects. When reviewing stages 3 and 4, these areas are likely where the project manager accounts in their risk management plan to have contractors mitigate the risk.These stages account for issues arising, and based on my experience as a recruiter, the hiring manager knew who to reach out to fulfill their staffing needs.
Has anyone worked with a staffing firm to mitigate risks in their projects?
2 thoughts on “Risk Management Plan for Software Development Life Cycle”
This is interesting take on the importance of having dedicated risk management professionals, whether labeled as risk officers or project managers. In the professional services realm, our clients are almost always targeting risk identification and response expertise throughout our engagements. In fact, many of our consultants take an extra step of obtaining professional risk management certifications. Overall, I think it’s important to have that on-sight expertise, regardless of form.
Thank you for the response, Al! It’s interesting to hear how firms handle project professionals, and adding another level of risk professionals make sense. Interesting indeed!