Question

Before you leave for the weekend, could you make a list of all the possible risks for this service department system project? I'd like to think about our risks over the weekend and discuss with you on Monday.

Answer 1

Risk 1: Inherent Schedule Flaws

Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule.

Solution: Get the team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders.

Agile Practice: On agile projects, the team is heavily involved in planning and estimating through activities such as XP's planning game and Wideband Delphi workshops. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, true progress is hard to hide and quickly revealed, giving feedback to the stakeholders.

Risk 2: Schedule Risk:

The project schedule gets slip when project tasks and schedule release risks are not addressed properly. Schedule risks mainly affect a project and finally on the company economy and may lead to project failure.

Schedules often slip due to the following reasons:

• Wrong time estimation
• Resources are not tracked properly. All resources like staff, systems, skills of individuals, etc.
• Failure to identify complex functionalities and time required to develop those functionalities.
• Unexpected project scope expansions.

Risk 3:  Programmatic Risks:

These are the external risks beyond the operational limits. These are all uncertain risks that are outside the control of the program. These external events can be:

• Running out of the fund.
• Market development
• Changing customer product strategy and priority
• Government rule changes.

Risk 4: Specification Breakdown

When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.

Solution: Use a dedicated Product Manager to make critical trade-off decisions.

Agile Practice: Agile projects utilize the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion.

Risk 5: Poor Productivity

Given long project timelines, the sense of urgency to work in earnest is often absent resulting in time lost in early project stages that can never be regained.

Solution: Short iterations, right people on the team, coaching, and team development.

Agile Practice: Agile methods recognize Parkinson's Law and the Student Syndrome apply to software projects. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly here before starting work." By having short iterations, work is time-boxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on the team, coaching, and team development, but these are core leadership roles applicable to both agile and traditional projects.

Monitor and Mitigate:

To be effective, software risk monitoring has to be integrated with most project activities. Essentially, this means frequent checking during project meetings and critical events.

Monitoring includes:

• Publish project status reports and include risk management issues
• Revise risk plans according to any major changes in the project schedule
• Review and reprioritize risks, eliminating those with the lowest probability
• Brainstorm on potentially new risks after changes to project schedule or scope

upvote pls...