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 project can create delays in another, unrelated project.

Resource risk mitigation in Scrum 

In Scrum, a team remains together for the entire duration of the project. The Team has all the skills necessary to create finished functionality. Think ‘idea to done’, not ‘spec to test’. This is sometimes called a feature team.

Scrum Teams are cross-functional to minimize dependencies and ensure that the necessary skills are available in the Team when they are needed.