Thursday, October 13, 2016

Top list of Software Development Life Cycle Risks | David Tzemach

What is Software Risk?

Risk is the potential of loss. This potential is based on both the probability of occurrence (uncertain and undesirable outcomes that may lead to a major problem at any given point in the software development life cycle) and the impact on the business/project and software (combination of time delay, Financial loss, reduce in performance, loss of reputation etc.).תוצאת תמונה עבור ‪Software Risk‬‏

General causes of Risks

There are multiple reasons of project failures, sometimes the cause of the failures are located in the business level and some time on a specific stage of the SDLC. I created this list that has more than 150 real life examples that you can include in your own RM process, the list is divided into few simple categorize that make it more readable for you. 

Stakeholders Related Risks

  • Allowing the stakeholders to dominate the project.
  • Failure to engage the company stakeholders.
  • Failure to understand the response of the stakeholders in case of failed projects.
  • Failure to understand the stakeholder’s expectations.
  • Team members that afraid to take decision because some stakeholders maybe decline it.
  • The Customer changed requirements that may lead to stakeholder’s conflicts.

Business Related Risks

  • Does the project match the company culture?
  • Failure to create an effective communication between the resources that involved in the project (Departments, individuals, Etc.).
  • How the current project will affect the company future “Road-Map”?
  • How the current project will affect the company reputation?
  • How the current project will affect the company revenues?
  • How the project affects the historical/Future sides of the company?
  • How this project affects other projects that spread throughout the business?
  • Software that fails to answer the customer expectations.
  • The product will fail to be “sold” following the expectations?
  • The project will fail to meet the actual needs of the organization?
  • The Software will fail to be delivered on time.
  • Unstable company environment.
  • What amount of other customers will use the current developed technology?
  • What are the extra costs will be, if the software will be failed to be delivered on time?
  • What is the ROI for the company regarding this project?

Project Timelines related Risks

  • An external source(Stockholder, sales person, client Etc.) that pushes that team member to make unrealistic commitments about the project timelines
  • Delays on one task that affecting the total timelines of the project.
  • Expectations that promised by the management and cannot accomplish during the project timelines.
  • Failure to understand the complexity of the project.
  • Failure to understand the project risks.
  • Failure to understand the set of skills that needed to accomplish the project targets.
  • In order to secure a contract with the company customers, the project timelines are cut, in a way that affecting the software quality.
  • Managers that failed to prioritize the daily/weekly/Etc. Tasks.
  • Personals that involved in the process need longer time than expected to learn unfamiliar environments, technology Etc.
  • Schedules that build based on resource that not available.
  • Schedules that built on “Best case”.
  • Specific Project aspects that failed to be concluded in the project timelines.
  • Teams that behind the schedule and hope to catch it without reporting on time.
  • Testing and development activities that dependent on external resources.
  • The analysis that is done to create the timelines are poorly documented.
  • The resources that involve in the project, are not familiar with the project timelines.
  • Tight timelines that affecting the resource productivity.
  • Timelines Estimations that delivered without a solid information.
  • Unexpected tasks that raised during the project.

Team related Risks

  • Lack of positive and negative feedbacks.
  • Problematic team members are failed to be excluded from the project.
  • Team is built with unclear hierarchy.
  • Team members are failed to work together as one unit.
  • Team members that are not experienced enough.
  • Team members that are not qualified enough to handle the project complexity.
  • Team members that failed to understand the company business case.
  • Team members that failed to understand the user “use” cases while designing and executing their tests.
  • Team members that failed to understand the user expectations.
  • Team members that failed to understand the user story.
  • Team members that failed to understand their responsibilities.
  • Team members that failed to understand their role in the team.
  • Team members that ignore or failed to understand the design documentation.
  • Team members that ignore the project process.
  • Team members that resistance to work based on the requirements.
  • Team members that work more hours that they should because other team members failed to perform their job.
  • Team members with Lack of commitment.
  • Team members with Lack of motivation.
  • Team members with Low team spirit that affects the team performance.
  • Team members with negative attitude towards the project goals.
  • The team failed to contain a specialist to support the technical difficulties that may raise during the project.
  • The team is built based on unqualified persons for the job.
  • There are insufficient resources in the team to handle the project tasks within the current timelines.

Environmental related Risks

  • Architectures that designed with a lack of flexibility that will be needed for different SDLC levels.
  • Designed architectures that are impossible to implement during the project timelines/costs.
  • Dev/QA team members are not familiar with the tools that used in the project.
  • Development and testing Environments that designed for the project, but not relevant to the actual needs.
  • QA\Dev teams that don’t have an appropriate hardware/Tools Etc., to accomplish the development and testing requirements.

Budget related Risks

  • Additional expansions due to new requirements/changed requirements.
  • Costs that related to meet the release deadlines.
  • Failure to forecast the cost estimations.
  • Improper estimations of the needed budget.
  • Project delays that may consume more money than originally expected.
  • The costs of External service providers.
  • The costs of internal employee’s.
  • The costs of the software’s that involved in the Management/reporting/ development/testing process.
  • Unexpected Budget cuts.


Planning and design related risks

  • Different developing teams that start their developments individually (each team is responsible for single component) without the basic thinking of the overall developing architecture (the classic example is failure of integration of those individuals).
  • Choosing the first available solution without considering if other solutions have better met the project goals.
  • Failures that related to a corrupted process implementation.
  • A Highly complex, software architecture that delivered as single process inset a small chunks that easier to process.
  • Lack of project planning that cause development and testing duplications.
  • Lack of project planning that cause development and testing gaps.
  • Lack to design an appropriate methodology to handle the project complexity.
  • Planning is considered as the project owner responsibility, although it’s should be a team activity.
  • Planning that ignoring critical project parts.
  • Planning that made by people that doesn’t have the experience.
  • Poor project design that affecting the entire project (Timelines, costs Etc.).
  • Poor project design that affecting the technical aspects of the software (Developing, Testing and maintenance).
  • Teams that move into the next project phase without completing the previous stage.
  • Unclear responsibilities for the resources that involved in the project.
  • Underutilized resources that affecting specific areas in the software.

Resource allocation and hiring related Risks

  • Contactors/Permanent workers leave the project in the middle.
  • Failure to allocate the best available people for the project.
  • Failure to hire the correct propels.
  • Hiring of new resource is taken longer than expected.
  • Insufficient resources to accomplish the project timelines.
  • Part time employees.
  • People that got assignments but not capable to handle them.
  • Persons that have specific skills cannot be found and recruited in time.
  • Resources that not tracked properly.
  • Resources that participates on multiple projects.
  • Resources that shared between multiple projects.
  • The company best workers are not available for the project.
  • Underutilization of the resources involved in the process.

Customer related Risks

  • A customer that changed the requirements all the time.
  • A customer that failed to deliver a detailed requirement.
  • A customer that failed to understand that deadlines are dynamic and may be changed during the SDLC process.
  • A customer that failed to understand the complexity of the project.
  • A customer that finds bugs
  • A customer that has ambiguous requirements.
  • A customer that has unrealistic expectations.
  • A customer that uses the software in a different way than expected.
  • Customer that we know that we had prior problems on other projects.
  • Customers that interrupt the SDLC process.
  • Customers that will not buy the software, although the software delivered in time and based on the asked requirements.
  • Promises that made to customers that the software will eliminate their problems without a real proof.
  • The customer declines the software due to low quality.

Requirements related Risks

  • Ambiguous and insufficient requirements.
  • Key requirements are poorly documented.
  • Requirements that demands new methods in the Dev/testing process.
  • Requirements that demands new testing methodologies.
  • Requirements that demands new testing types.
  • Requirements that doesn’t reviews by the project resources, this may lead to different expectations and wrong design.

Technical and technology related Risks

  • 3rd party applications that failed to provide the expected solution.
  • 3rd party applications that used without an expert that can answer the open questions.
  • Badly chosen auto tools that failed to support the project needs.
  • Components that build by external vendors.
  • Components that built with unreliable technology.
  • Components that built with unstable technology.
  • Customer requirements that demands new technology development.
  • Customer requirements that demands older code modification that involved in the current SDLC process.
  • A Development that based on a new technology that unfamiliar to the engineering.
  • Insufficient methods and tools for software analysis.
  • Is there any customer specific hardware/software that needs a special development?
  • Lack of understanding of the chosen technology.
  • Lack of understanding in the coding language that need to be used in the coding stage.
  • Lack of understanding of the testing tools that used in the testing process.
  • Multiple technologies that need to be combined to handle the customer expectations.
  • New technologies that used in the current project.
  • Software that poorly documented.
  • A Technology that used and hard to maintain.
  • The software should support new operating systems that have never been supported before.
  • What are the testing tools (if any) that used in the testing process?

Daily activities related Risks

  • Activities that abandoned from the project scope.
  • Conflicts between team members.
  • Failure to create a valid mechanism that can track and implement the customer newly added requirements (failure to establish such mechanism will lead to failure in handling the requirements that leads to the growth of the project scope).
  • Failure to prioritize the project activities.
  • Lack of formal technical reviews (Code design).
  • Lack of formal technical reviews (Project requirements and specifications).
  • Lack of formal technical reviews (Testing process).
  • Management and project owners that disregard important meetings.
  • Missing or poor documentation that leads to a poor description of the project requirements.
  • Multiple “Change-Requests” that documented poorly and against the original requirements.
  • Project changes that failed to be addressed to the project resources.
  • Stakeholders and management conflicts may cause project distractions.
  • The amount of documented reports take too much time.
  • Too much formality that results slower progress.
  • Under/overhead communication between the project resources.

Project Management related Risks

  • Management and project owners that disregards the project daily status.
  • Management and project owners that disregards the project process.
  • Management decisions that reduce the employee’s commitment.
  • Management decisions that reduce the employee’s motivation.
  • Management politics that cause any interruptions.
  • Management that doesn’t believe in the project.
  • Management that failed to handle resources that perform below the expectations.
  • Management that failed to have good relationships.
  • Management that failed to say “No” when they know that they cannot deliver the expected quality during the specified timelines.
  • Management that failed to understand the project complexity.
  • Management with lack of confidence.
  • Managers that deliver poor project planning.
  • Managers that doesn’t have enough experience to lead large scale projects.
  • Managers that failed to create an efficient team structure.
  • Managers that failed to handle the project pressure.
  • Managers that failed to make an appropriate “Risk” analysis.
  • Managers that failed to manage the golden criteria(Timelines, Quality and Costs)
  • Managers that failed to prioritize the employs tasks.
  • Managers that failed to provide new timelines when needed.
  • Managers that failed to think ahead about potential problems.
  • Managers that works based on assumptions and not by the true facts.
  • Mangers that failed to provide a clear and solid mile stones.
  • Organizational management changes during the project.
  • Owner that use an intensive “Micro-Management” that affect the development and testing performance.
  • Owners that failed to create an appropriate training program.

No comments:

Post a Comment

My Presentations