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

Mike Stewart Business Development ★ Market Development ★ Technology Commercialization ★ Business Law

May 6th, 2013

I am reliant on my development firm. I am a business guy; they are the developers and designers. The project is 90+% complete, but every deadline has been extended by weeks, sometimes months. Overall, the total time for completion of this project has been delayed by 300%, some of which can be attributed to me and my change orders, but certainly not all of it.

I want my product delivered ASAP, but I am weary of suffering a poor quality finish. The firm does good work, and the day is too late to change developers. The time and cost for getting new developers up to speed would outweigh any benefit. So in my mind, I've got to work with these guys and to make the best of it.

My tactic thusfar has been to praise their good work, but point out the delay, and point out each time a deadline is missed. This tactic is beginning to fail on the last leg of the work. I need a fresh approach. The delays are costing me money. I have thought about witholding amounts from final payment for each additional day that the project is delivered late beyond a "final date".

What would you do?

Mitchell Portnoy Healthcare Information Executive

May 6th, 2013

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.

Douglas Tarr Entrepreneur and Software Architect

May 6th, 2013

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.

Here's a trick that I've learned over many years of dev management - triple any estimate you get from developers that you don't know intimately and trust. Then, take the new estimate and see if it is acceptable to you. If not, keep cutting scope until you get a project that meets your original deadline.

Additionally, have regular (daily or weekly) checkins with the team to see if there are any risks or issues that you can address. It's better to address them earlier than later, as the costs are lower. Most "agile" shops will follow this kind of methodology, with a whole host of processes to aid it.

Also, start talking to another firm about taking over some small section of the project. This will give you some leverage and help you understand if the problem is with the original firm.

Jonathan Vanasco

May 6th, 2013

Get a Technical Co-Founder ASAP.

Forget about what potential investors think, your operational capacity is being dictated to you - not the other way around.

I once inherited a corporate project that was being outsourced. A well respected agency was on retainer for a large monthly fee that covered 2 Junior Devs, 1 Senior Dev, 1 Engineering manager and 1 QA / Customer Relations manager. They were courteous... but standard work was always delayed , overages always occurred , and a lot of seemingly repetitive work was required.

When I looked under the hood at the source code, I was astonished. It was very clear that only 1 junior developer was working on it FT , assisted by less than 1 junior developer PT. There was never an engineering manager or senior dev on the project. Aside from grossly understaffing their work, the quality was abhorrent. Mistakes weren't just random, they were grossly amateur. They also had one repetitive task that they kept on billing for, insisting that something had to be done manually due to the nature of the application. They billed 2hrs for each of these tasks ( which I timed at 5 minutes to do code , test , merge into source control and deploy ), and billed them out 4 times a week for over a year. It took me 90 minutes to turn that repetitive task into an option on the admin console. I ended up writing a scathing letter to that company and firing them, their CEO and CTO looked at my analysis and passionately apologized. They honestly had no idea, but it was too late.

I don't mean to suggest that your vendor is doing anything questionable or insincere. They could be 100% honest - delays happen. But they could be taking the wrong approach to solving specific problems , they might not be able to prioritize things as well as they should, or they might have some really junior people working on the project. You might be paying for Senior level people, and they might think that the devs are senior, but they could be coding at an entry level capacity. This happens more often than you'd think.

Whether they're the best developers in the world, or simply a bad team, without a technical partner to audit their work, manage their velocity and priorities on a daily basis, and bridge the gap between your needs and their interpretations... you've got a recipe for a lot of frustration.

That being said, the best way to get stuff done is motivation. Dangle a maintenance contract, perks for finishing by a certain date, recommendations , etc. Whatever you do, don't withhold payments or get ornery with them - you'll only shoot yourself in the foot.

Tim Scott

May 6th, 2013

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.

Peter Baltaxe Consultant, product leader, serial entrepreneur

May 6th, 2013

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.

Jon Cooper Chief Technology Officer at Colchis Capital Management

May 6th, 2013

Do you have a contract? What are its terms?

IMO the only way to deal with outsourced development is to use an agile process and to get invoiced on a time and materials basis, i.e. you pay $X per person per time interval and they do whatever you ask. Even when "outsourced" contracts have positive outcomes they are late, over budget, and result in crap ass codebases that need to be nuked from orbit and then rewritten. The secret is that you don't "outsource" your product. It's your product. You hire developers and work with them to build a product. That means talking to them on a daily basis.

If you need agile process coaching there are many resources; I could help and so could others on this thread.

In terms of where you're at with this project, I would approach from the perspective of triage. Get someone competent to do a code review and let you know the state of affairs "under the hood," as it were. But also, get someone competent to talk to you about your spec, timelines and deliverable pacing. It may be that you're on crack and the development shop just doesn't know how to tell you that.

David Bergman CTO, Co-Founder of Stackray, Inc.

May 6th, 2013

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 :-)

George Song UX Designer and Web App Developer

May 6th, 2013

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.

I think being punitive would just strain the relationship further.

I would honestly consider switching development firms. Speaking as a partner in a development firm, we've always kept our clients in the loop and we've delivered on time almost in all instances. In cases where there are delays for whatever reason, the clients are never surprised.

Again, just like any dysfunctional relationship, expecting change without the hard work is unrealistic.

Brian Milnes CIO and VP Business Dev at XBRLCloud

May 6th, 2013

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

Stephen Peters Looking for the next challenge and opportunity

May 6th, 2013

I ran my own web development shop for 12 years and I made plenty of mistakes along the way and learned more than a few things the hard way. There's lots of ways a project can get behind schedule. Assuming scope creep and slow review from the client aren't the problem here then the next two biggies are 1) lack of man power - they're overscheduled and don't have enough people to get things done on time and 2) they've screwed up the budget on their end and they're hiding it. I suggest finding the most senior person there the person who will be the most upset by a late or non-payment and hammer out some promises with some painful consequences for not meeting those promises. If they are short manpower, that means they're working on other people's projects instead of yours. Why? Perhaps the squeaky wheel effect, other customers may be complaining more. Possibly they underbid your project and now they have to work double-hard on other projects to keep the lights on while they struggle to finish yours. Another factor in priorities is a difference in how much different projects pay. Some of the hardest lessons I learned was that when we offered someone a "special deal" they would end up getting less than stellar service because we'd have to be off working on the better paying projects first because of the laws of bank account physics. (This is a bitter lesson. You think you're doing a friend a favor, when in fact, they'll leave feeling burned.) Also some times a company can have great engineers and poor project management. Regardless, there's a reason why they are slow to deliver and if they want a check you deserve answers. You many need to jump in and demand a micro-management level of detail on how they are going to meet your deliverables. Just make sure they know they are seeing money until you get your milestones delivered. There you have it, Web Developer Confidential in all it's gritty glory. - Steve