Many project risk managers view risk management as the identification and mitigation of potential events that could affect the likelihood of a project’s success. This view is flawed, as the greatest risk to a project success is not some event that might occur, but rather simply having poor processes and practices for collaboration, project management, discovery, development, or delivery.
At the beginning of an initiative, there are many risks associated with getting the requirements right, obtaining active user involvement and adoption, and enabling business change to achieve successful business outcomes. However, most risk management practices are focused internally on project resources, project activities, and project deliverables. Risk management practices must change from the current process of focusing internally within the project to an external focus on the business and the users.
There are two aspects to software risk: Context and Process. Both of these areas are explained below.
Context Risk
Understanding the context for risk is critically important. In understanding risk, it is important to gain an understanding of both the organizational and strategic context. Gaining this understanding requires a thorough review of the environment in which an organization exists and operates. It is important to take into account your organization’s specific objectives and capabilities, as well as external factors, such as the changing legal environment and shifting social standards. Establishing context provides the framework for the risk management process. Context risks can be defined in three broad categories: Project, Business Change, and User Adoption, which are explored in the following paragraphs.
Project
Project context is where risk management has traditionally concentrated. It is generally focused on the work to deliver a successful project. In gaining an understanding of project context, it is important to look at, among others:
- Project resources and skills
- Budget and time constraints
- Solution scope
- Project management methods and tools
- Development lifecycle (e.g., agile, plan-driven, or other)
- Requirements development and management practices
Business Change
Understanding the amount and extent of business change is best done though identifying the impacts to the areas listed below. Understanding how the project will impact these areas can make a big difference in delivering better outcomes.
- Stakeholders
- Business processes
- IT services and technology
- Enterprise data
- Governance and business rules
User Adoption
If an IT project does not reach a successful critical mass in terms of user adoption, then the organization is exposed on several fronts. First, the ROI is adversely impacted and maybe even negative. Also, time to value will be considerably longer as the team struggles to adjust workflow and software features to accommodate user needs. Value may be further eroded by the disruptions and productivity losses that ensue. In these instances, IT’s reputation is negatively impacted, as the project is seen as dragging over time and not satisfying the needs of users.
User adoption risk is perhaps the greatest risk in delivering value from an IT Project. User adoption needs to be considered from the start of project. Projects that accumulate too much user adoption risk should be modified or cancelled if their chances of failure are too high. Too often, user adoption is addressed as “change management” only before deployment.
In gaining an understanding of user adoption risk, it is important to look at:
- Who the users are,
- What tasks and activities the users perform, and
- What problems and needs does the solution address?
Process Risk
Using well-defined proven practices for project management, business analysis, and development significantly reduces project risk. For example, agile methods are now considered an effective method leading to project success. Agile methods are effective for the following processes:
- Project management
- Communications and collaboration
- Discovery
- Development
- Delivery and deployment
There are two essential practices that should be part of every project. The first is breaking the project into smaller components that can be delivered independently, and the second is reducing and managing solution scope.
Simply breaking a project into smaller components that can be managed and delivered separately significantly improves the success of a project. It is important not to interpret breaking projects down into a series of smaller projects. This does not mean defining a large project into milestones, phases, critical paths, and activities. Rather, it means planning a series of projects each with its relevant milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project.
According to the Standish Group, 64% of software features developed and implemented are rarely or never used. Identifying and eliminating features that provide little or no business value before they are developed can have a significant impact on value delivery and achieving successful results at a much lower cost.
A new breed of tools is beginning to emerge that enable the key concepts identified in the Standish Group Report to be achieved. One leading example is Enfocus Requirements Suite™, a Software as a Service product from Enfocus Solutions Inc. This tool allows features to be defined and validated independently and then delivered as series of small projects (bundles). The benefits of applying these two techniques using a tool such as Enfocus Requirements Suite™ quickly become evident when the organization starts to receive value earlier and projects success rates soar.
[cta id=”7658″]