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.

Okay, no one buys that exactly, but there is a certain amount of seeming randomness in software or web development that makes developers and managers both very, very nervous when entering new endeavors.  Everyone knows from past experience that even with the best of intentions, things seem to occasionally go terribly wrong.

I’d like to suggest that things happen for a reason, however.  In the case of software development projects, there are specific patterns and phenomena that drive projects towards success or failure, and that learning to recognize those patterns can lead one to manage them much better.

In fact I would take that one step further, and say that these patterns can actually be modeled, and together form a bit of a magic 8-ball on what’s likely to happen with the project.

Clients

Many software development projects have clients involved, and for many of them the problems start right there.  Clients present an extremely powerful influence over projects, because if they are not happy, there is no business.  Clients do not always act in their own best interests however, or the best interests for the project.  Therein lies the rub.

I’ve identified a specific set of criteria that identifies good clients.  Clients with these attributes are good, those without them are bad.  Howe much risk a client brings to a project depends on how many items on this list they rate.

• Strong decision maker: Is there someone (much preferably an individual person) who can make decisions in the client organization?  Or is there a distributed set of stakeholders, all with different agendas, values and visions about what the product should be?
• Reasonably Insensitive to Price: Does the client appreciate the value of what they’re getting?  Or do they just want to slash, slash, slash prices and get the cheapest possible version of their site?  Do they argue over every last nickle and dime?
• Technology Agnostic: Tech matters.  Anyone who says differently is ignorant or lying.  The choices of hosting, frameworks, platforms, products etc all compound and add or remove risk from the project.  Good clients are ones that allow and encourage the best tools for the jobs to be used.  Bad clients come in the door with corporate technology mandates that have nothing to do with the specific interests of the project.
• On a Reasonable Deadline, but Flexible on Scope: Projects need schedules in order to happen, but the uncertainty baked into programming demands that something in the classic project management triangle flex, and the best thing to flex is scope.  When there is a clearly prioritized set of features on the table, the upcoming release may or may not have certain features, or they may be implemented at a number of different levels of complexity.  Hard features of limited business or user value should be jettisoned.
• Savvy: Good clients know their own business, the Internet and so forth.  Clients that require teaching on every last point that intersects the project slows things down, and opens the door for them to make bad decisions.  A client that is reasonably well educated on their space and how it relates to the project will be much less off than others.

Grading

For your client, award 1 point for each of the above criteria.

5 points: A. Run, don’t walk and get this client’s business.  They are extremely rare and can be the basis of an excellent partnership in which you can do great things.

4 points: B. A good, run of the mill client.  Will occasionally do something bothersome, but well within the parameters of something that can be managed for success.

3 points: C. Fair.  This is starting to get into the range where client risk can adversely affect the project.  If it is combined from risk from other factors, failure can occur.  Nonetheless it is possible to succeed with a C client.

2 points: D. Not good.  This is a high-risk client, and this kind of work should only be taken on if painstaking steps are taken to protect the team from bad influences and decisions made by the client.  A large amount of time will be spent on keeping this client under control, and preventing them from damaging the project.  It better be worth it.

1 and below: F. This client brings disaster with them.  It is almost impossible to succeed with this kind of client, and it usually isn’t worth it.  They will be a never-ending source of problems, and will compel bad decisions that will most likely derail the project.  Avoid.

Continued in part 2, when we’ll look at some of the other risk factors that bear on a project.

UPDATE: Okay, so I covered some of this before, but this is part of the model, so its sort of from the opposite tack.

Over time I have identified 5 factors that clients bring to the table, that directly affect the outcome of a web project.  These factors can accumulate and ultimately swing the fate of a project from success to failure or vice-versa.

Here they are:

Don’t Be Overly Price Sensitive

Guess what?  Agencies are expensive.  If you want to build a website on the cheap, you probably don’t want to deal with an agency, you want to keep the project in-house as much as possible, and outsource the rest to individual contractors.  Quality can suffer this way, because you are now the web project manager (and presumably you have something else to do), but it theoretically can be cheaper.  Trying to pinch pennies with an agency can cause compromises in the quality or scope of your project that can be hard to predict.

Be Flexible on Features

Clients who want to control every last feature can lose sight of the main goal: getting a working web site that meets their business goals launched. In my experience, the best projects are ones with strict deadlines, but with some flexibility in scope.  Over the course of production, hard decisions may need to be made about whether features should be included in the upcoming release.  Generally speaking, being flexible on features, but sticking to the established release schedule, is the right decision almost every time.

Be Decisive

Clients who are indecisive, or who have decision-by-committee issues, bring risk to web agency projects.  The best projects are ones where there is a single project owner on the client’s side, who is empowered to make decisions and grant approvals about the web site.  The ability to provide clear, timely feedback and direction to the web agency is essential.  On the other hand, a client that waffles, takes forever to make approvals, or sends mixed signals to the agency just makes everything harder.

Trust and Defer

Trust the web agency, they know the web, that’s what you’re paying them for.  If you don’t feel like you can trust them, then you shouldn’t hire them in the first place.  In order for an agency to operate efficiently, it needs a certain amount of autonomy and independence from the client.  Only then can it employ its internal best practices, and do the best job it can.  Micromanaging an agency actually removes value for the client.

Be Savvy

Understand the web.  Understand your own business.  Understand how web agencies work, if possible.  The more sophisticated you are, the better the project will run.  In the past I’ve known clients who have asked for web sites, who never actually use the Internet themselves.  How could they make informed decisions about their own web site, if they spend no time on the web?  By taking the time to educate yourself about the environment in which your project lives, you’ll be stacking the odds in your favor.

There it is – clients that get all of these items right are a pleasure to work with, and they tend to get fantastic results from the agencies they use.  At the other end of the scale, clients that come down on the wrong side of all of these points can create situations that can be difficult or impossible for agencies to rescue.  By mastering these factors as a client, you’ll be doing the most you can to ensure the success of your project.