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.

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.

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.

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.

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

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

Avi Tevet Founder of Fitlogr

May 6th, 2013

Sounds like there's a combination of poor communication and, from primarily the dev shop, poor ability to predict how much customer-requested work can be done in a particular time frame.

So here's what I would recommend:

* They need to create a running list of all outstanding issues, and each one needs to be justified and prioritized. It will include all work from you and all internal, technical thiings they need to do. Ideally they will provide a time estimate with each one. Try to get them to write the tasks in such a way that they take a "short" amount of time, generally less than 1 week. Tasks like "create the user profile pages" are so broad that they will essentially never be complete. Instead, the tasks should be things like "design the user avatar upload page," "implement the user avatar upload page," "identify all user preferences," "design the user preferences page," etc.

* Get demonstrations from them weekly, at a fixed day/time (ex: 9am Wed). They will present the current Work In Progress and you will provide feedback on what you think. Keep in mind that most meetings, you will see a lot of unfinished work. It's like meeting with a contractor redoing your deck - day 1 you see the demo, day 2 you see the foundation, day 3 you see the joists, and so on.

You will start to see trends emerge. Maybe they are adding in work that is not on the list - get them to notify you so that you can prioritize with them. Maybe your change orders get broken into 1.5 months of tasks - you need to determine when you want the change. Maybe they consistently underestimate the amount of time it takes to do the tasks - ask them to learn from the difference, because underestimating effort is not doing either of you any good. Maybe all of your requests are always top priority and interrupt all Work In Progress - you need to work with them to prioritize *all work* whether it's from you or them.

If you hit a predictable development pace, you can probably scale the meetings back to bi- or tri-weekly. But, you should never allow un-discussed or badly prioritized work to creep into a release.