We’re tired of doing Project Rescue services for the wrong reason.

“Project Rescue” is a service we provide. We take over software projects started by another vendor that have gone off the rails for various reasons. We typically reset the requirements, restart development and finish the project.

There are many valid reasons to turn a project over to a software vendor like Spieker Point. But this blog post is talking about the #1 wrong reason we get pulled into Project Rescue projects:

  • The vendor isn’t a professional software development firm and are in way over their head.

From our experience, this is how it commonly happens:

  • The vendor typically builds static web sites. They’re not a software development company.
  • The customer has had them do their web site, or has seen some of their work on other web sites.
  • The customer may not understand the difference in complexity between a static web site and a web application. The vendor doesn’t fully understand the difference either.
  • The vendor doesn’t know where to draw the line and say “no – we’re not trained for that”; knowing little or nothing about how software applications are secured from attacks when they’re out on the internet.

I’ve been an expert witness on a number of failed software projects that have gone to court. I find it remarkable how much money is spent on legal costs by customers and vendors; and often the vendors don’t learn from the case – I see them out there doing it again.

Properly secured, well planned, efficient, extendable (as browsers and your needs change), well maintained software takes formal education and years of training to properly architect and execute.

In the same way that having a 13mm wrench doesn’t give the untrained kid next-door the know-how to repair your Audi RS6, having access to a database and software language doesn’t give the ability to develop a normalized database for a secure web application.

Ask Yourself the following before you embark on a software project with a vendor:

  1. What kind of formal education does the team have in software development?
  2. What experience does the team have with similar projects (functionality and size)?
  3. Ask for company references.
  4. What is the tool chain that will be used for the project – and why?
  5. How modern is the tool chain? If it is ancient, and you can’t find job postings for it, run.
  6. Who will own the intellectual property on the developed software? If it is your competitive advantage, YOU should own the secret sauce, and expect to pay a premium for it.
  7. If part of the project is a base product for a license fee (like Spieker Point’s DECK), can it be held in escrow if the vendor goes under? This shouldn’t be a big deal for the vendor – but you’ll pay a yearly fee for it.

You wouldn’t buy a building or a company vehicle from a vendor that hasn’t proven themselves as experts in delivering the end product. Software should be seen as the same type of investment. It isn’t something to trust in untrained hands.