Before we start with this list, a quick summary of where they come from. Projects are tough when they have a high risk of screwing up. Risk comes in two major flavours: technical risk and market risk. Technical risk is linked to whether you’re capable of building what you’re building. Market risk is linked to whether you are actually building the right thing. It’s a useful dichotomy in IT and in many other places - to succeed, you’ve got to do it right, and you’ve also got to do the right thing. Now, you can break these two risks down in all sorts of interesting ways, but what I’ve tried to do here is to produce a list that will be useful to you no matter where you sit on the scale from hardcore bit-pusher to networker extraordinaire - whether you’re a techie or a business guy, basically. Here goes.

1. Technical Risk: number of features

Can you summarise what your application will do in a single sentence? Most likely you can (if you really can’t, you might want to rethink your application - it sounds like it’s really two or more applications). That sentence gives you your core application feature. But it doesn’t give a complete rendering of your vision. In order to build something real, you’re going to have to break it down into smaller, more concrete steps. You can drill down into these (your application requirements) as deeply as you want, but some sort of middle ground is where you should be aiming. You want that specification to take about half a page to a page, no more and no less.

At this level of detail, you’ll have a decent feature list, that you can put in bullet points. Here’s the clincher: every time you add one of these bullet points, you greatly increase the difficulty of the project. That’s because no feature stands alone. They all interact with each other, and those interactions increase the complexity, and with it the risk that something will go very wrong. At the extreme, if you add a feature that interacts with all the existing features, you’ve just doubled your technical risk. On the good side, this works both ways. The more features you can cut, the easier your project will be to deliver. One of the beauties of software (particularly online applications) is you can add features later, after version 1.0 has shipped and started either making some money or at least getting solid user feedback. Do so wherever you can. If your software is still worth shipping without feature X, be merciless and cut it out.

If after doing this exercise you feel that your project still has a lot of features, your project may be tough. If it meets some of the other points too, it probably is.

2. Market risk: user picky-ness

The more picky your users are, the higher the chance they’ll slaughter you when you take your product live. This picky-ness depends both on the type of users and on the number of users. If you’re aiming for millions of users, they qualify as picky, always. If you’re aiming for a dozen hedge fund managers, they are picky. If you’re aiming for a few thousand middle office users in a bank, they’re probably not that picky (though you may be led to think otherwise after yet another interminable requirements gathering meeting).

You can’t do much to cut this risk down on the outset, but it’s good to be aware of it, particularly since it’s often overlooked. Technical people, particularly, tend to focus on technical risk, and assume that if the functionality is easy to implement, the product’s a piece of cake. It’s not. Creating something millions of people will be willing to use takes a touch of genius, just like creating a brilliant piece of code.

What you can do once the project is rolling is put it in front of users as soon as you possibly can. If this is a major risk for your project, you absolutely have to use an iterative (probably agile) development process and get some users involved. If you can get them involved before it even starts, great. If you’re going for something very specialised, you might even consider giving some equity in exchange for a few of your target users on your board of directors.

3. Technical risk: complexity of features

Number of features is a big factor, but that doesn’t cover how complex they are. You might build a GTD todo list that has a zillion features, but none of them are really complex. Build a “straightforward” search engine with only a handful of features, though, and complexity goes sky-high.

If you’re a business guy, you’ll need a trusted techie for this. Don’t take it badly - it’s one of your qualities, to see things that are really hard or even impossible and try your best to shove them into existence (and then sell them!). But you need someone who knows what’s possible, and who can tell it to you straight.

If you have a really complex feature in your shopping basket, what you should do to reduce risk is build it first. Build it before you build anything else at all, because this feature is where a lot of the technical risk sits, and the sooner you’ve resolved it, the sooner you can move on and relax. Of course, if you have one (or more) of these features in your project, you earn yourself a tick on this criteria on the “tough project” checklist.

4. Market risk: strength of the competition

This is not about whether there are competitors at all. Having no competitors doesn’t make things easier - in fact, it makes things much harder for the marketing team, because they have to create a market by convincing people that they need this new thing, and making them understand how it fits into their existing needs. If you’ve got no competitors, your project is probably tough. Tick this box.

There are many existing markets that could use some improvement, though. The number of competitors doesn’t matter so much here, it’s the quality. Going head-to-head with Google or Apple in any of their core market, for instance, instantly earns you a tick in this box. Evaluate the competition (you did do a competitor analysis before getting started, right?). Chances are, most of them are just also-rans. Those shouldn’t bother you too much. What you’re looking for is, would any of them deserve to be called a Tiger, or a Shark, or some other kind of vicious animal. If yes, and if your stated goal is to fight these guys, your project deserves a tick in this box.

You can’t do much (.. legally) to reduce this risk. What you should do is be very aware of it and make sure your product does something radically better than the top competition. And keep monitoring them while your project is evolving, just in case they do something that changes the game. If they do, you need to act quickly to ensure that you don’t come out with an also-ran.

5. Technical risk: integration risk

A lot of the largest IT projects have been failures. The stage where they most commonly failed was integration. After building a bunch of components separately, people found, at the last, under-estimated minute, that they didn’t fit together. You should be prepared for that both within your project and outside of it.

Within your project, unless you’re building the next air traffic control system, that’s probably not a major issue, and you should deal with it very simply by forcing the project to deliver an integrated product throughout the development (using agile processes once again helps here). If it really is an issue (according to yourself or your technical guys), perhaps your feature list could use a bit of initial trimming (see point 1).

Outside of it, though, this is still important. The more external systems your software needs to integrate with, the greater the risk. By external systems I don’t mean TCP/IP or “the internet”. I mean things like: email processing, linking up to an existing legacy system, SMS integration, phone line integration, streaming technology. Each of these chunks of existing technology will cause you massive headaches, and you should consider every one of them to be as dangerous as a “complex” piece of functionality (as discussed in 3). The solution there is the same: cut them out if you can, and if you can’t, build them first.

Conclusion

These five points should help you gain a better idea of how tough your project is. If you’re building a sprawling application which does ten thousand things, is aimed at almost everyone, retrieves and reprocesses data from thirty external systems and has strong, well established competitors (the My Google homepage would qualify), your project is tough.

On the other hand, if you’re building an application which has just one feature (e.g. generate random passwords), will be imposed on your five thousand internal corporate users and will require use of cut and paste to work with existing apps, your project is not tough.

In short:

Toughness = Risk = Technical Risk + Market Risk
        = (Number of Features x Complexity of Features x Integration Risk) +
           (User Picky-ness x Strength of Competition)

In a later article, I’ll examine, in a bit more detail, the link between project toughness and the kind of developers you want to hire. In the meantime, thanks for reading. If you have any comments, examples, or suggestions for other criteria, please post them below!