Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

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

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?

27 Replies

David Bergman
0
0
David Bergman Entrepreneur
CTO, Co-Founder of Stackray, Inc.
I have been on both sides of this (in-)equation, and it is quite likely that they express the exact duality of what you stated, i.e., that they are to blame for some of the delays but certainly not all, probably thinking that the specifications are too loose and changing - and some developers latch on to a simple change as a way out of taking responsibility.

I think what you presented is fair: share the pain of delays with them.

But more important is to sit down and reorganize immediate goals, often in terms of a venerable MVP. I would not be that afraid of letting somebody else look at the code for a few days, and see if he/she/they can actually present that MVP for you, while letting the existing team work on "the next version", if you happen to have confidence in them. Yes, relaying the info of letting somebody into the bedroom might be a bit painful, but if you paint it as trying to get a (possibly) sub par MVP out the door in X weeks while they work on "the real 1.0," it might be doable.

Let me know if you need help, tangibly, since I happen to be such a "lifesaver" tech guru, often in + fixing + out in 2-3 weeks. :-)
Mitchell Portnoy
3
1
Mitchell Portnoy Entrepreneur
Healthcare Information Executive
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.
Brian McConnell
0
0
Brian McConnell Entrepreneur
Head of Localization at Medium.com
If they are delivering decent work but not on time, it sounds like they are either not very good at cost/time estimation, or you are competing with other clients for their attention. Your instinct to complete the release with them is wise, switching vendors is almost certain to be a disaster. I would be very wary of doing anything that might cause them to pay less attention to you, such as delaying payments. Instead I would have a frank discussion with them about the need for them to take deadlines seriously, either by providing realistic schedules so you can plan accordingly or by delivering on time, if the cause is slippage due to other customers. Their continuance as a vendor is dependent on them shipping. I would recommend talking with them about your plans for version 2.0 and your excitement about getting past the first release (you don't need to bully them with a threat to find someone else, if they're at all smart, they know their underperforming and are at risk of losing the account). Also, it is important to be honest with yourself about whether part of the problem is "pilot error" (i.e. you). Software developers like precise, well thought out specifications that provide enough detail about required functionality without veering into micromanagement. Ask them if this is an issue. If it is, a good remedy is to have one of their developers with project management experience to work with you on your specs. If you're not a developer, it's likely you're omitting things that are "obvious". Having someone who knows development question you can help eliminate ambiguities, unspoken requirements, etc, all the stuff that can cause confusion and feature creep. Longer term, you definitely need to bring core dev/design in house. Outsourcing is great for peripheral tasks, like building an Android app around your existing web API, but being dependent on a third party for your core system/IP/etc puts you at risk. My $0.02
Douglas Tarr
2
0
Douglas Tarr Entrepreneur • Advisor
Entrepreneur and Software Architect
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.
George Song
1
0
George Song Entrepreneur
UX Designer and Web App Developer
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
1
0
David Bergman Entrepreneur
CTO, Co-Founder of Stackray, Inc.
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 :-)
Cullen Zandstra
0
0
Cullen Zandstra Entrepreneur • Advisor
CTO:FloQast
As a developer I can say that the problem is extremely common. I've worked at big and small companies, and almost invariably, projects take longer than expected. Programming is unfortunately not an exact science, and humans are innately terrible at estimating how long things will take to complete.

If they're doing solid work, I wouldn't recommend seeking out any kind of retribution for the delays. You have almost nothing to gain, and everything to lose. If the programmers feel disenfranchise while working on your project, they're not going to do a good job. They'll get it done as quickly and as dirty as possible just to get through it. Instead take whatever estimation they give you and double it to get some idea of how long it's actually going to take.

This link might help: http://coding.abel.nu/2012/06/programmer-time-translation-table/

good luck
Mitchell Portnoy
0
0
Mitchell Portnoy Entrepreneur
Healthcare Information Executive
True. But don't underestimate the motivation for more work in the future. Without leverage, which you don't have a lot of, it's always better to use enticements or at least the promise. Motivation works. Threatening non- or slow payment doesn't.. Good Luck!
Jonathan Vanasco
5
0
Jonathan Vanasco Entrepreneur • Advisor
Co-Founder at Aptise
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 and1 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.
Brian Milnes
1
0
Brian Milnes Entrepreneur
CIO and VP Business Dev at XBRLCloud
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/[removed to protect privacy]/ref=sr_1_7?ie=UTF8&qid=[removed to protect privacy]&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
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?