- Autonomy: A relatively small group must have complete control of the essential parameters and resources of the project. By parameters I mean things like scope, specification, etc. By resources I mean people, cash budget, access to external knowledge, and the like.
- Competent designers: Those software engineers who design the project (which for software means choosing the general schemes for doing things like state update, persistence, portability, deployment, etc) must know what they're doing. They don't have to be inspired, they just need to come up with designs that are neither inadequate nor too complex for the task at hand.
- Care: The person or people who are ultimately responsible for the product must sit in front of the software and test it, personally, for weeks on end, as it nears release. No matter how good the specification, planning, formal testing, etc, they will find an enormous stream of bugs that you will be glad to have fixed before release.
If you don't have these things your project will for sure fail. If you lack #1, then in theory you just have to go though a simple process to get the additional decisions or resources you need. The problem is that the process in place in most organisations for getting these things is atrociously bad at dealing with uncertainty. Basically "The Organisation" will give you a decision or a budget if you explain exactly what course of action or equipment is needed. Of course you don't know that, so you will lose months fighting through this process, as well as most of your motivation.
If you lack #2, you are probably screwed. Either you have engineers able to produce software designs that steer between the naively inadequate and the hopelessly overburdened, or you vanish into one of these pits. Often both! There's not much to do in that case but throw away the code, train or replace your engineers, and start again. If you discover this in the first few months of the project, well, you'll only be a few months late.
Whether you can do without #3 bears some discussion. I think the efficient, effective, and overall preferred way to make a high quality product is to do #3 (as well as formal testing for purely technical bugs). There is an alternative, which is to specify every aspect of behaviour in minute detail and have an army of professional testers test it by following a script, without much of an understanding of how the customer would approach the product. Well, that would kind of work too, if you have the budget, but you'd end up with something like Visio or Outlook. Yes it would work, yes it would survive long enough that you can fix the problems in the next version, but actually it would please nobody. In my opinion you need a caring eye to produce a customer-pleasing product. You can produce a customer-satisfying product mechanistically, but that's a failure in my view.
Now, if you do have these three things, your project will probably succeed, substantially, in some way or another. It would be nice to have more things in your favour, like a realistic schedule, but it's not essential - if your schedule is unrealistic but you have complete control of the project you adjust something (the schedule, the scope, or resources) to make it fit. It would be nice to have a product in mind that's technically feasible, but if your designers are competent they'll dismiss the infeasible thing and replace it with something sound. It would also be nice to have a spec for a saleable product, but actually if you don't the person who cares that the product is good will fix that for you. You get the idea.