SOA projects are not "special" and mystically better than non-SOA and you need to know when to kill them off and the three books above will give you some good indicators. But some very obvious ones are
- Project has slipped 50% on its timescales, and you aren't even developing yet
- You are using early access software and you don't have a link to the dev team
- Most projects failed under the old process and it hasn't been changed
- There was no additional time added for learning new technologies
- The vendor cackled when selling you the product
- You've included several brand new products, and its taking much longer to integrate than expected
In many ways you should be more often looking to kill of new SOA projects as they will have new technologies, new process requirements, new governance requirements and the odds are you'll get it wrong (particularly if you don't get outside help).
If you really want SOA to succeed then you have to look to fix the basics first, this means understanding the business services, the right process and governance model and putting in place the right training to make sure it all works.
SOA isn't magic pixie dust to be added to projects to make them succeed, technology based SOA in particular suffers from the challenges that any technology driven exercise does, namely it rarely delivers what the business wants.
Kill early, kill often. I've seen far to many projects fail at year 2 that had been known as failures since week 1.