Skip to main content


Top Project Risk Number 2: Time and Budget Risk

“Will it be ready for Christmas?”  Just about every client I ever met has wanted to know the answer to this question. Will it be delivered in the time frame and budget that were promised?

Time and budget are very closely related. While there are other factors, cost usually depends mostly on the number of people involved and on the length of the project.
Time and budget risk mitigation in Scrum You can deliver to a deadline with Scrum or other agile frameworks. A fixed price is easy to achieve if you limit the time on the project but leave the scope open and definable in the project.

Scrum mitigates time and budget risks by breaking down functionality into small pieces, implementing must-have features before nice-to-haves, and having a shippable version available at least once per sprint.

In Scrum, the Product Owner has the option at the end of every sprint to deliver, to continue funding and developing, to deliver and continue developing, or even to abandon the project.

Phased develo…
Recent posts

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 …

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…