I like to call this second category Structural Risk, because it has to do with how a project is structured: the parts that make it up.  Again, to take the positive angle – each point below is listed in its non-risk-adding, positive side:

• The team has worked together before. The team itself is a known quantity, with the individual talents and personalities of each team member known to the group.  This knowledge allows team members to guide the project to leverage the various strengths and avoid the weaknesses of the individuals on the team, working together to achieve the highest level of productivity.  Also hopefully people like and respect each other.
• The team knows the technology. It is a technology that the team has worked with before – they know how to work with it rather than wind up fighting it.  They are unlikely to be surprised by strange quirks of the tech stack that creep up at the most inopportune times.
• The team knows the client. The team has worked with this client before, and therefore knows the business problems that intersect their space.  This way they will be less likely to make poor assumptions about how things are supposed to work.  Functional specs are great, but they don’t take the place of actual domain knowledge on the part of the team.
• The team has a methodology for staying on track. Without getting into the comparative merits of individual development methodologies, the main point is that the team has a way to prioritize, track progress, and correct problems early on.  A team that can’t tell that it’s off-course can’t correct.
• The team can effectively communicate to management, and vice-versa. The cliche is that management understands different levels of priority for requirements, but sees all cost of implementation as equal.  Developers see different costs of implementation, but imagine all requirements to be equally important.  Neither is true, of course, and there needs to be an effective channel for technical and business stakeholders to properly communicate with each other.  A Tech Lead can be an effective method here.

Note that none of this discusses the individual experience or quality of the members of the team.  This is structural.  Process and management – all about getting people to speak with each other, and work well together.

Again 1 point for each “yes” answer for your team, just like in part one.

5 points: A. Your team knows each other, the client and the means to success like the back of their hand.  You’ve probably already made the mistakes you are going to make, so you can count on solid execution from people.

4 points: B. Still solid.  B is as good as a team can get with a new client (and at least in agency work new clients are frequent).  B is structurally still a good risk, but can occasionally throw up a surprise or two.

3 points: C. Medium risk.  At this level there is at least some degree of immaturity in the team – it may reflect new hires, or the creation of a new team where there wasn’t one before.  The team is still working out the kinks in their process.

2 points: D. This is an immature team.  There are enough unknowns going on at this level that the team can easily trip over itself, adding significant risk to a project.  Watch out.

1 and below: F. The team is not ready for this project.  The structural problems will create a significant negative impact on the project, probably leading to some level of failure.

To be concluded in part 3, where we’ll look at qualitative risk, and how to combine all the risk factors together into a single model.

Some time ago, back when I knew absolutely nothing (unlike today, when I merely know next-to-nothing), I allowed a number of business ideas be crushed by the fear that, once big competitors entered the market, I would be instantly destroyed.

Since then I learned about [[Disruptive_Technology | disruption]] and how it can provide a competitive advantage to new entrants in a market where they have no investment in the status quo.  Still, the massive resources that larger companies can bring to a project can be daunting.

Fortunately, there is a built-in upper limit to how many people can effectively collaborate together.  It seems that somewhere between 5 to 10 people productivity seems to top out.  Past that point, it starts to become necessary to formalize communications, with the unfortunate side effect of slowing everything down.  Teams below this threshold are sometimes called “Two Pizza Teams” or “ten-groups“.  At this size it’s easy to get everyone on the same page, so the “productivity-per-resource” ratio is going to be the best at this size.

The cumulative effect of this “two pizza limit” is that there’s a natural productivity resistance point at a relatively small number of people.  Beyond this point productivity drops off, consuming more and more resources for less productivity gain.  This effectively means that the playing field is somewhat evened between large and small companies, even though a larger company can, in theory, throw many more resources behind a project.

So if you are a smaller company, but have a great, disruptive idea, and between 5 to 10 people to throw at it, you can swim with the sharks.  The nature of human collaboration will provide a degree of protection against much larger competitors with more resources.