Modeling Risk (Part 3): Quality

The plot so far:  there are specific things that cause project’s to fail, beyond the abilities of seemingly competent people to control.  These forces aren’t random, they are specific patterns and antipatterns that create accumulating risk that bears down on projects like debt.

In Part 1 we discussed client driven risk – the problems that clients bring to the table and how they affect the project.  In Part 2 we discussed structural risk – risk that originates with the composition of the team working on the project.

The third and list type of risk I call Qualitative Risk.  This is a kind of risk that is affected by the quality of the tools and people executing the project.  Everything counts, everything matters.  Quality affects the project.

There is a school of thought in business that would dearly like to factor quality out of the equation.  Businesses that trade in commoditized markets, competing on price, basically operate on the supposition that there is a standard level of quality and that it is not a distinguishing characteristic.  The movement towards off-shoring software development included an attempt to factor out quality.  Command-and-control programming languages like Java and .NET are attempts to engineer developer quality out of the equation – at least partially.

Quality, however, matters.  The web development framework you choose will affect the project, positively or negatively.  The skills of the developers you hire will affect the project.  It is not just subjective, some of these things are actually better than others.

I break Quality factors down into 3 main pillars: Team, Tech and Support.

Team: How strong is the team?  My feeling is there should be at least 1 really good senior developer for every 3 medium or junior developers on staff.  In addition, it is good to have at least a couple of honest-to-goodness rock stars around – the people who can be thrown against any technical challenge and still land on their feet.  The bar should be set at a level where the team can be counted on to astonish you on at least a semi-regular basis.

Tech: How good is the tech on which you’re building this thing?  Does it provide features that you need?  Does it provide a means of accelerating custom development, in case you need to go outside those features?  How often is time spent using the technology solving actual business problems, as opposed to just servicing the demanded ceremonies of the technology?  When is the technology enabling you, and when are you fighting it?

Support: The infrastructure: managerial, administrative, legal, HR etc., that surrounds the team – how much is it helping?  Is HR effective in finding new talent?  How about support from IT?  Is it straightforward to get ticket systems, continuous integration servers, new virtual servers etc. set up?  Or does every request take forever, with the development team resorting to circumventing the company infrastructure?  Does management back and support the development team, or are they selling them up the river?

Each of these pillars is deep and complicated, so grading them is a little abstract.  However if you set an aggregate grade for each pillar and take the average you’ll get a sense of the qualitative risk associated with the project.  Again, starting about the C grade and intensifying as you drop below that, you can easily get to a level of unacceptable risk.

In the next and final installment of this series – we’ll look at putting all the various risk factors, client-driven, structural and qualitative, into an overall risk profile.