Why do some software / web projects run off the rails so badly? Are we just incompetent? Is it that the very practice of programming is so incredibly difficult that it defies any attempt to manage it? Perhaps software development is just an inherently terrible idea, and we should leave it up to Microsoft to handle, and focus on other things, such as selecting the best clip-art for our PowerPoint slides.
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.
