Skip to main content


Top Project Risk Number 3: Scope Risk

Will I get everything I asked for? Imagine it is Saturday, your spouse is about to go out somewhere with the car, and you need groceries. You ask him or her to stop at the grocery store on the way home. “Of course, send me the list!” You text the list of groceries for the week and then add, “For our guests tonight we need meat, wine, and cheese.” Your spouse returns at six that evening with everything but the meat, wine, and cheese. “How could you not bring tonight's dinner!?” “Oh, that was at the bottom of the list and I was running late, so I didn't get to it.” Obviously, getting everything would have been the best solution, but if you had to choose between ‘things for next week’ and ‘things for tonight’, which is more important? Which alternative gives you better options?

Time, budget and scope are the classic measures of success of a project. Is it on time and on budget? Did it deliver all the features? Of these three, scope is probably the least important. Being on time …
Recent posts

Top Project Risk Number 4: Market Risk

If we build it, will people use it or buy it?
Building a product that no-one wants is a great way to lose your entire investment.
“For our guests tonight we need meat, wine, and cheese.” Your spouse goes to the grocery store and gets all the ingredients for dinner. That evening... you have prepared a wonderful meal. Your guests arrive and see that the menu consists of meat and cheese: “We're vegetarians, and I have a milk allergy.” 
This is known as ‘technical success’. The developers did a great job, but the ‘business guys’ screwed up by not figuring out what the customer really needed.

How do you avoid creating “a solution looking for a problem?”
Market risk mitigation in Scrum  Scrum reduces market risk by encouraging collaboration between the stakeholders and the Scrum Team. Scrum requires a demonstration to stakeholders every sprint and makes the Product Owner responsible not just for staying within the budget, but also for ensuring that the sponsor's money is well spent…

Top Project Risk Number 5: Technical Risk

Can it really be done? I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth. When American President John F. Kennedy made this speech in 1961, did anyone know if it was possible to get a man to the moon? If you are going to build rockets you need a certain tolerance for explosions – and you will learn the importance of testing and when to be careful!
Technical risk mitigation in Scrum In Scrum, the Whole Team collaborates to identify the best step forward each sprint. This includes identifying and handling risks. The Team advises the Product Owner, who has the final say about deciding which backlog items come to the top of the backlog and into the sprint. Business value usually trumps technical issues, but the Product Owner should be an educated client and listen to the Team.

An insidious form of technical risk is the ‘Technical Debt’. Technical Debt is the consequence of po…

Top Project Risk Number 6: Social Risk

Can the people building the product collaborate effectively? Most projects are not rocket science. When I talk to people about the reasons for their most successful projects (or their biggest failures), they don’t usually talk about technical issues. Instead, they explain the importance of openness, trust, collaboration, and communication, effective decision making and clear leadership.

Social risk does not appear to be on the radar screen of many organizations as they shuffle ‘resources’ from one project to the next. This is surely a contributing factor to the relatively low performance, engagement and morale that are common in large organizations.
Social risk mitigation in Scrum  A Scrum Team is a small group of people, less than ten, who work together over a longer period of time. While team changes are possible, they happen infrequently. The group becomes and remains a team that knows, supports and trusts each other. Scrum Teams value courage, focus, commitment, respect, and open…

Top Project Risk Number 7: Dependencies, or Resource Risk

Will the people who are needed be available when they are needed?
Many organizations are structured around skillsets or technology platforms, e.g. analyst, developer, tester or front-end, middleware, back-end, database. Since the back-end folks can't do anything without a database upgrade, and the middleware folks can't do anything without the necessary back-end functionality, etc. you end up with a lot of dependencies, which need to be managed.

Let's say Mary (remember Mary? We met her yesterday), a middleware developer, is scheduled to work on Project A until the end of the month, and then move on to project B. What happens if her work on Project A takes longer than expected? Either she is not available for Project B, so that project gets delayed. Or she gets put on Project B anyway, in which case Project A suffers an even longer delay.

Component teams create dependencies because they are not capable of creating finished functionality by themselves. Delays in one projec…

Top Project Risk Number 8: Stakeholder Risk

Will the stakeholders change, or even just change their minds? Just before my team was scheduled to release the first version of the product, the client’s pilot customer changed their digital marketing manager, who was responsible for the product. We made the release, and he was shocked: “You have created a web-based media tool but don’t support the basic tags required to track readership! How could you?!”   What happens if new people assume the role of key stakeholders in the project? Are they aware of and bound by the decisions about purpose, priority, scope or funding level made by their predecessors?

Even without personnel changes, decisions about prioritization can change any time and have an impact on many projects.

Let's say Mary, a middleware developer, is scheduled to work on Project A until the end of the month, and then move on to project B.  What happens if Sam, a stakeholder of the middleware team, tells Mary's manager that Project C is now the top priority? “Hav…

Top Project Risk Number 9: Change Management Risk

Will changing requirements delay the project?    “We had been working on a new hardware-based product for six months. One day, the sponsor came in and announced a change in the requirements that invalidated all of our work. The change was so fundamental that we had to start over from scratch. We wasted six months of the team's effort and delayed our entry into the market by at least that long.”

The lost revenue probably had a bigger impact on the company's bottom line than the wasted capacity. This kind of decision can also be very hard on the morale of the Team.
Change management risk mitigation in Scrum  Scrum addresses the change management problem in several ways:
At the end of every sprint, there should be little or no work in progress. This is a low-cost opportunity to change direction if necessary.The Development Team designs the product and their engineering practices to make change as inexpensive as possible, because it can happen every sprint.The Product Owner's …