Every organization managing projects is liable to face risks. It is a well-known fact that major risk elements are always involved in every phase of a project development and execution. Risks can be broadly classified into two major categories – predictable and unpredictable. Most of the project management teams remain prepared to address only the predictable risks, but often fail to address the unpredictable ones during ALM Implementation. Nevertheless, these unknown risks have a critical impact on the schedule, cost and delivery of the project.
It is understandable that not all risks can be defined and managed in time. Project managers try to prepare Risk Management Plan for ALM by efficiently elaborating the requirements and then execute them. This is to ensure that most of the risks are predicted and controllable measures could be taken to prevent project failure. .
Requirements management for ALM is quite a challenging task for most of the organizations. Teams managing requirements have to face a lot of questions on a daily basis such as –
- Are the customers’ requirements properly understood and prioritized?
- Is the Project Planning being properly estimated with respect to schedule and cost?
- How often rework is done by the development team due to the lack of clear understanding of the requirements?
- Are the requested changes properly accommodated and impacts are analyzed and propagated to the correct levels?
Fig: Risk Management Process for ALM in Kovair
The fact is that gathering and managing requirements efficiently is an absolute critical factor in developing all kinds of software applications and systems. Requirements are the basis of what needs to be produced that are requested by the customers and developed by the software development organizations. Many believe that requirements are actually the primary source of most of the project risks and defects. According to the researches done, a major percentage of rework effort is spent on rectifying the requirements related issues and the least is spent on fixing the code related defects.
Researchers have found that the cost to fix a defect increases if it is allowed to propagate through the software cycle. Moreover, surveys indicate that a post-production defect takes much longer time to fix with respect to the one being found in any of the pre-production stages.
Business Analyst Role in Risk Mitigation during ALM Implementation
In many instances, analysts start a project without having a defined set of requirements from the customer. Absence of such requirements specification documents can be highly risky for the project team as they remain confused about what is to be done and when to start the project related activities.
Here I will discuss some of the business cases that lead the project towards risk and how an analyst can play an important role in mitigating the risk by taking proper corrective actions.
1. Unavailability of Requirements Management Plan during ALM Implementation
The analysts must derive smaller plans for Requirements Management like Requirements Traceability, Requirements Impact Analysis and Propagation and Requirement Deliverables.
2. Changes in Baselined Requirements in implementation phase, after Sign off
Customers often send requests during the implementation phase to change even the baselined requirements and that too after the Business Requirements have been signed off. However, not all change requests corresponding to the requirements in the baseline need to be included. Every change has to be placed to the Change Review Board for approval. After understanding and identifying the risks, if any, in implementing the change requests; those are to be taken forward for implementation in the current or future releases. Analysts can use a model to assess the risks and be ready to answer the degree of impact for the change.
3. Stakeholders are unable to communicate their actual needs
It is difficult for an analyst to be present in all the project meetings that are being held simultaneously by different stakeholders belonging to different groups. So the analyst should assign specific users who would be responsible for each of the elicitations and act as coordinator between the customer representatives and the project engineering team. The users would interpret the customers’ actual needs and convert those to functional requirements to the project team. If a proper documentation is not received from the customer, then this would lead to further confusion. The analyst would also escalate it as a project risk, if it resides as an issue during the project.
4. Contract and Scope Undefined for the Project
Once the project is formally declared to be started, the first step for the analyst would be to focus on reviewing the requirements and define the boundary scope. In the second step, the analyst should clarify the original understandings and set the customer expectations, if there were any changes being requested through the Change Management procedure.
5. No Defined Prioritizations for Requested Enhancements
If you as an analyst are coordinating a project implementation, you should first pay attention to what the client needs now. Most of the clients are unable to define their priorities correctly and often seek for what they ‘want’ rather than what they actually ‘need’. This may risk the project to a great extent.
An analyst has a very important role to play in this situation. Through regular meetings, he or she needs to negotiate with the client to define the priority list and segregate their requirements into various categories like Urgent, Very High, High, Medium and Low.This would help to set the customer expectation on one hand and the engineering team to deliver the items as per the priority on the other.
Project risks mostly occur due to unidentified risks during the Requirements gathering, analysis and planning phases. These can be mitigated if the analysts identify these early, and preventive measures are taken promptly.
Risk Management for ALM in Kovair
Kovair’s risk management solution simplifies the process of identifying, evaluating, managing, prioritizing and mitigating risks by allowing cataloging and responding to risks from a centralized repository. Its mouse click configuration allows organizations to configure specific project or business solutions as per defined risk mitigation strategies.
Kovair also helps automate all the phases of reviewing and monitoring risks on a regular basis and then continuously updates the risk plans. Kovair’s task based workflow automation reduces manual intervention in risk identification and monitoring, thus optimizes resources without compromising on risk management efficiency. Click here to learn more about risk management techniques in Kovair.