Skip to main content

Top Ten Product Development Risks That Can Kill Your Project

Every project has some degree of risk. Every project is a leap of faith. Risk identification and mitigation start long before the contracts are signed. Some of these risks can be mitigated or aggravated through the contract. What are these risks, how does Scrum mitigate them, and how do they play into the contract?

This series of articles will look at the top 10 risks of product development and how you can mitigate those risks in Scrum,

Most risks occur when you have to make a decision based on incomplete information. You make an assumption, take a decision, spend the money and hope for the best. Sometime later the facts will emerge. This is called validation. If your assumptions were correct, then you get the return or other benefits you hoped for. If not, your time has been wasted and your money is lost.

How big is the risk? A securities trader would explain that it depends on how much money is at stake and the duration of your exposure. Exposure is the period of time between making an assumption and getting validation, that is, learning whether your assumption was correct or not. In projects, the amount of money at risk increases linearly over time as costs accumulate.

A traditional project management approach to handling risks is ‘Expected Monetary Value’ (EMV) . A risk is something bad that could happen. What is the financial impact if it does happen? What is the likelihood of it happening? The product of these two items is the EMV.

For example, if a car is destroyed in an accident, the impact is the cost to replace the car. What is the likelihood of an accident? If this is 2%, then the EMV is 2% of the cost of the car.

All of the risks in this series can cause the project to fail outright or go way over budget. Adding them up, the amount at risk can substantially exceed the initial project budget.

In general, to reduce risk, deal with it. Mitigate it. Prevent it. This chapter will tell you how. Be proactive. Get validation faster. Look for validation of key assumptions before committing serious money.

If you want to get the whole list right away, you can get my book "Ten Agile Contracts: Getting beyond fixed-price, fixed-scope."

I am releasing one article per day for the next two weeks. Tomorrow, we'll start with the Also Rans, 5 risks that didn't make the top 10 (but can kill your project too).


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…