How would you handle a skilled development firm that is consistently late to deliver?

Making change requests is like the black death to your project, not just a paper cut. Imagine building a building, you start with the idea to build a house, you draw up the architects plans and start building. A third of the way through, you decide to add on an extension, this is more work and your deadline has to go back. You then make changes to interior design, a new wall here, remove that one there.

Stop making changes!!!!

When you make a change, it affects every part of the whole and the cost and the deadlines.

We in development have a methodology called Agile... the team creates a backlog of all the bits required to make the project. We have 3 week sprints to complete a selected set of this backlog jobs. You seriously need to read up on this Agile Method in Software Development.

A poor quality finish? Has Microsoft Windows ever lived up to being a good quality finish?

Get it done and get it on the market as soon as possible.

And don't think for a second that you won't be paying for this product FOREVER... for the length of time that your business runs you will be paying these developers to continue to develop the product. Each year tech changes, new business requirements, your code becomes old and no one knows what or how it does what it does. You'll have new costs.

Mitchell is right too... so you can use this leverage to say that you might not hire them for the next go around... but do remember that they wrote the code and the code could be terrible to look at for a new or even their development team.

Technically you should have a CTO and /or a Product Manager.

Software is expensive, time consuming and a never ending money pit, the rewards to for getting it right are big but the costs to get there are equally big.

Enjoy.

Get a Technical Co-Founder ASAP.

This is a story told over and over again for years and decades now.  I've lived it from both sides.

You mention "change order" and talk about the product being finally "delivered" per a "deadline."  This tells me you are using some form of the waterfall method. If I were you I would ask the team to shift to agile. They probably know how but are using waterfall because they think it's what you want.

Here are some big changes you should expect:

- No sign-off of specs, no change orders, no fixed "deadline" for the whole project

- They should deliver working software to you within 2-3 weeks and then every 1-2 weeks after that, if not continuously

- Your specs will be vague, short, and changeable with no formal change process

- Expect to be high engaged with your dev team -- every dev can reach you on IM or phone -- expect several calls per day

- Expect to personally review and jigger priorities often -- maybe once per week

These are simply the markers of the agile method, which is very mature and SOP in most quarters for a long time now. Beg pardon if I sound condescending and you are well aware of agile, but if you're not there's massive amounts of material about it on the Interwebs.  IMO it matters little what flavor of agile you adopt: scrum vs kanban vs XP vs whatever.  But any way you go you will have more satisfying outcomes that with a waterfall method.

What you lose with agile is a sense of certainly and control at the start of the project. You lose the liberty yo check out of the process and let the sausage be made by the experts absent ongoing guidance from you. What you gain is visibility, insight and meaningful control and, in the end, better software faster.

Do you have a contract? What are its terms?

Anybody in the services business would prefer to work for clients that pay quickly rather than slowly.  You might try promising that you will pay them the day after the deliverable is met and passes acceptance testing, rather than the standard 30 or 60 days.  If they are a small shop and dealing with making bi-weekly or monthly payroll cash flow, it might motivate them to prioritize finishing your project.

I think much like any other relationship, you need to find out the root cause of the delay, and if there's anything *you* can do about it by making specific adjustments.

If you happen to be The Board, you can also buy a voice scrambler for $6.99 at K-Mart and pretend you're the hitherto unknown hard-ass Chairman :-)

Mike, The standard of software quality production is notoriously poor. Or as Weinberg put it "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization ". Research in the 1980s and 1990s at Carnegie Mellon Universities Software Engineering Institute produced software processes, such as https://en.wikipedia.org/wiki/Team_software_process, that can produce reliable software production to with in 10 to 15% of budget and/or time and about 80% reduced defect using statistical process control. This research was led by Watt's Humphrey https://en.wikipedia.org/wiki/Watts_Humphrey, the 'father of software quality'. However, such development teams are few and far between. Most software teams are taken with the current religion in software engineering of Agile software development. A tenant of Agile is that software engineers can not accurately estimate and thus should not (although some later agile processes are attempting to put estimation into their processes). All of which was rigorously shown to be nonsense in peer reviewed papers with hundreds of thousands of hours of study by the work of Humphrey at CMU SEI. * What we all do is estimate and budget for 30% in time and 50% in cost beyond what any* *team claims to be able to offer and expect more work on the fairly high defect rate of normal* *programmers.* As you work more with a team and they continue to work on similar projects you may be able to get a better estimator. Be careful asking them to add labor as they are likely to get some speed but poor cost/performance returns for this ala the Mythical Person Month ( https://en.wikipedia.org/wiki/The_Mythical_Man-Month). One of the advantages of agile (although long used in other processes such as Bary Beohm's spiral process) is to deliver product in tight little increments often called spirals or sprints. The early feedback helps you see how things are going, improve your designs, and helps keep software teams from going far off track. If you aren't getting nearly weekly deliverables from your team, you may find that very helpful. Also it lets you cut features to meet your time/quality/cost/functionality tradeoff that make sense for your product. A good book to give a business person a better understanding of high level management of the software process is http://www.amazon.com/Winning-Software-An-Executive-Strategy/dp/0201776391/ref=sr_1_7?ie=UTF8&qid=1367877559&sr=8-7&keywords=watts+humphrey . Good luck, Brian P.S. * And if I've blasphemed any Agile indoctrinated engineers religion, don't bother to flame **at me. Instead, s**end me a large scale quality research paper showing any claims you have that it* *works. **My last literature search found not a single quantitative paper

Does this ever sound familiar! You're in a tough spot and without a great deal of leverage, but there is always the the good cop (you) fictitious bad cop (invisible "Board of Director's) tactic. You continue to praise their work, discuss the promiser of the "next iteration of development" but advise that unless they can finish what they have on their plates right away, the "board" will not allow you to "re-hire" them for the next go-around (which of course is so promisingly lucrative). This usually works.

Penalizing the firm for software delays will probably backfire.  They'll probably either insist on hourly terms, pad their estimates, or refuse to work with you.   After all, they are paying their team and by your own standards (300% over) they will probably not get paid at all.