Blurring lines between protoype and development

Mother Brain

Hi folks,

Just wondering if anyone has run up against this before.

I'm developing a fairly reasonably complex web app for a client and before the the project I provided a proposal which outlined a two phase development approach. Phase 1 being the development of a semi interaction prototype demonstrating some limited transitions and interactions with the app. Phase 2 being a full on dev cycle once the required overall structure and data model for the app was pretty much agreed upon.

The phase costings were agreed and a 12 week prototype phase was begun. Now it is about 14 weeks in (mainly due to slow feedback), and in my mind I have satisfied the bulk of the terms of the proposal in this regard. There are several screens and transitions, limited database functionality etc.

The problem is that the client keeps asking for more and more functionality to be added to the "prototype" on the basis of being able to see how it will play out, however, I feel as though if I continue to develop the "prototype" to a point where it has almost all of the real functionality i'll be reducing the amount I can charge for the phase 2, or be essentially building the prototype into the full app.

My instinct tells me that I should just be firm with them and refuse after a point, but the problem is that this is my first / only big client and I would potentially be doing myself out of a hefty chunk of revenue.

Does anyone have any advice for how to proceed or how they handled a similar situation in the past? Be much obliged for any advice.

Sorry for the long post anyway!

Cheers

The Corinthian

Mother Brain wrote: »

Now it is about 14 weeks in (mainly due to slow feedback), and in my mind I have satisfied the bulk of the terms of the proposal in this regard. There are several screens and transitions, limited database functionality etc.

The problem is that the client keeps asking for more and more functionality to be added to the "prototype" on the basis of being able to see how it will play out, however, I feel as though if I continue to develop the "prototype" to a point where it has almost all of the real functionality i'll be reducing the amount I can charge for the phase 2, or be essentially building the prototype into the full app.

What did you agree, formally, to deliver? Did you not sign off on a technical spec - even a functional spec? There should be no "more functionality to be added" other than whatever was listed in the agreed spec.

Additionally, you claim that you've "satisfied the bulk of the terms of the proposal". What do you mean? That you've not actually delivered what you've promised? If so why are you allowing to be bogged down with change requests before delivering what you've been contracted to deliver?

Mother Brain

The Corinthian wrote: »

What did you agree, formally, to deliver? Did you not sign off on a technical spec - even a functional spec? There should be no "more functionality to be added" other than whatever was listed in the agreed spec.

Additionally, you claim that you've "satisfied the bulk of the terms of the proposal". What do you mean? That you've not actually delivered what you've promised? If so why are you allowing to be bogged down with change requests before delivering what you've been contracted to deliver?

Against my better judgement I was persuaded to rely on a much more vague definition than I would have preferred.

Here is the most relevant excerpt from the proposal:

This will involve both a “vertical slice” such that one example “screen” is brought to a near final level of graphical fidelity, emulating as closely as possible the final form of the site and a “horizontal slice” whereby many or all “screens” are structurally produced in a “wireframe” to provide a basis upon which to prototype of the application.

The main tasks in this phase of work are shown below.
Task 1: Scope requirements for web-interface "what do users need to be able to do".
Task 2: Establish application logic - “what operations must be carried out by the application to achieve this”.
Task 3: Develop a low fidelity prototype of the user interface.
Task 4: Prepare detailed and costed software tool development plan.

Deliverable: Demo of user interface – It is envisaged that the final prototype of the application should be pseudo interactive, demonstrating several transitions and screens within the application.

Since this is essentially my first client I didn't want to potentially get rejected for being too picky over the paperwork so I agreed to this. It was agreed that a complete spec would be drafted for phase 2 after phase 1 was complete so I went along, albeit reluctantly. I feel foolish enough for having second guessed myself and should have stuck to my guns more but I was desperate for the business. What I really need now is a way of managing this so as to limit damage or lost earnings as a result.

Graham

Did you put any sort of limits on the duration of this phase?

With such a 'fluid' spec your best bet may be to sit with the client and explain you've allowed X number of days for this phase and anything significantly above X is going to effect the overall cost.

You've already identified that this would have been better agreed in advance so I won't go there.

The Corinthian

Mother Brain wrote: »

Against my better judgement I was persuaded to rely on a much more vague definition than I would have preferred.

You negotiated a bad deal.

Unless you want to continue working for free indefinitely, implementing whatever your client thought of the night before, you have to draw a line.

Tell them it is unreasonable to expect open ended development of features. Tell them that you want to work with them but you know that if this continues you'll be out of pocket. Agree on a finite line at which you'll deliver the final prototype, with an option for paid change requests in the next phase. Finish the work and deliver.

Or, if they stand their ground, you'll walk away and give them nothing.

If it comes to the latter, it'll be a tough lesson, but you'll be better off than if you continue - those who try to squeeze a developer like this are typically the one's who'll try to stiff you for payment, BTW.

Mother Brain

Graham wrote: »

Did you put any sort of limits on the duration of this phase?

With such a 'fluid' spec your best bet may be to sit with the client and explain you've allowed X number of days for this phase and anything significantly above X is going to effect the overall cost.

You've already identified that this would have been better agreed in advance so I won't go there.

Yeah I knew it at the time as well. It was one of those real "I have a baaad feeling about this" moments! It was supposed to be a 12 week max time period but has dragged on an additional 2 weeks so far due to the client being slow to provide feedback.

Again, I hoped if I could make it through one project and establish a bit of credibility there I might have a stronger position in future and so on. Calculated risk gone awry, but a good lesson nonetheless.

I think I'd have to agree with both yourself and Corinthian. It might be in my best interest just to suck it up and move on if it becomes too ridiculous. I'm waiting on feedback from them and depending on how they respond I believe a 'talk' will have to be organised.

Thanks for the input though lads, much appreciated.

On a side note, any particular strategies you have for getting potential clients to sign a contract? Other than just being naturally silver tongued! (which I'm certainly not)

beauf

Welcome to scope creep. They probably are not even aware that they are doing it. The proposal seems to suggest it doesn't have to be functional. So you've exceeded your own brief if any of it is. If it were me I'd draw a line the sand. Essentials to version 1. Anything extra to version 2. Do a detailed timetable (Gantt chart etc) and costing for the development of version 1. That done you can horse trade what version 2 features to bring into version 1, but with a clear understanding in your own head, of what it will cost you and the client in terms of time, cost.

Mother Brain

beauf wrote: »

Welcome to scope creep. They probably are not even aware that they are doing it. The proposal seems to suggest it doesn't have to be functional. So you've exceeded your own brief if any of it is. If it were me I'd draw a line the sand. Essentials to version 1. Anything extra to version 2. Do a detailed timetable (Gantt chart etc) and costing for the development of version 1. That done you can horse trade what version 2 features to bring into version 1, but with a clear understanding in your own head, of what it will cost you and the client in terms of time, cost.

Cheers, great advice.

Yeah, annoyingly it's just vague enough to muddy the waters. I think I'm fairly satisfied in myself that I've met my obligations though so I think I'll simply have to make it clear as to what is covered and what isn't.

The Corinthian

Mother Brain wrote: »

On a side note, any particular strategies you have for getting potential clients to sign a contract? Other than just being naturally silver tongued! (which I'm certainly not)

Yeah, walk away if they refuse to sign one.

If a potential client does not want to sign a contract with you, especially anything that pins down what they can expect, then they're not doing so for your benefit and there's a good chance that they will take advantage of this down the line. You're better off walking away than taking them on, and unless you're willing to do this, they have no incentive to compromise with you.

As a rule of thumb, it makes sense for all parties to agree upon what will be delivered. If they're concerned that they may want to change things then let them know that you're open to changes as long as functionality is not affected during the contract, but if functionality does change, then you can address those changes in the next cycle of development, under a new contract or an extension of the present contract.

Looking for money up front is also not unusual. Some go for a 50-50 model (50% upon exchange of contracts, 50% upon delivery), personally I prefer a 40-40-20 model (40% upon exchange of contracts, 40% upon delivery, 20% upon the end of a 3 month debugging/grace period). This is particularly useful in a market, like in Ireland, where there's a tendency to not pay the final invoice.

The latter also raises another issue; bugs and changes. There are always bugs, no matter how good you are. However, you don't want to end up supporting a solution for the rest of your life either, especially as most of the reported bugs, after a certain period, will end up being due to other changes they've put in, in the meantime, that you've no control over. So you tell them that you'll fix all bugs and non functional changes for free for three months after delivery, after which it's a paid change request or part of a SLA.

But the bottom line is that, in Ireland, business is still treated as a horse trade. It's not seen as a mutual exchange of goods or services, but unfortunately still seen as one guy getting one over on the other. It's cultural, I'm afraid.

As such, while you should by all means be willing to bend the conditions of a contract to keep your customer happy, you still want to be in a position that you are choosing to do so, and not because they have you over a barrel. Because that is exactly what many Irish SME's will be looking to do.

beauf

I think you have to insist on staged payments, doesn't matter if you are working on your own or if its company on a large project. Stage payments stops people mucking around, and makes them trim all the fluff out of the requirements. It also makes the developer really focus on what's realistically achievable. I prefer to get a basic solid release over the line, with a reduced feature set. Then afterwards add features, build on a stable base. There's always huge pressure, from the client to cram as much in to the first release, and get as much bank for buck as possible in as short as time. But I think that's a mistake that comes from a lack of experience.

Mother Brain

Yeah I was adamant about staged payment from the get go as at least then the client has some form of investment in the work.

Agreed on 30-30-40% split with the first payment due when the work started, second 30% at the halfway mark and 40% remaining. This is where I'm at right now and i'm obviously keen to wrap up this phase and perhaps proceed onto phase 2. Either way though I will be looking for the remaining 40% as soon as possible.

I wish it wasn't the case that smaller businesses around seem to be so averse to signing a contract as if we had had one in place I would at least have some recourse in the event that they decide to tank it and walk away. It's annoying when you're bargaining from what I would consider a position of weakness in the first place though. I suppose that's just the business though. It's almost like you get punished for trying to be above board and do quality work, as there's always someone floating around who will do the same work for cheaper but not nearly to as high a standard as I would want to hold for myself.

The Corinthian

Mother Brain wrote: »

It's annoying when you're bargaining from what I would consider a position of weakness in the first place though. I suppose that's just the business though. It's almost like you get punished for trying to be above board and do quality work, as there's always someone floating around who will do the same work for cheaper but not nearly to as high a standard as I would want to hold for myself.

You're not really bargaining from a position of weakness though. Time and time again, most freelancers and dev firms will tell you that even if you're undercut this time round by some student, junior developer doing a nixer or the project is outsourced to some third-World toilet, there's a good chance that the potential client will come scratching at your door, in six months, when it all goes pair-shaped.

And it does go pair-shaped, the vast majority of the time, unless they're very, very lucky or are experienced in managing software projects (which they almost certainly won't be), if their primary and overriding criteria is price. Which means that if they've not pissed away their budget on the a cheap option that goes bad (the first real hurdle that, especially start-ups, fall down on), they'll still need to get it done and will remember you.

Ultimately, you need to view your work in cold economic terms. It's not simply a case of getting a paid a chunk of money in return for some work, but also whether your time is better spent perusing that chunk of money or another client whom you won't end up wasting hundreds of hours either in feature creep or chasing for payment.

In short, don't be afraid to walk away.

beauf

Its better to have one paying client, that want you, and there's no messing around. Than 10 who just keep messing you around.

Graham

+1 to both The Corinthian and beauf

Success has as much to do with the projects you decline as the projects you accept.

It's a hard lesson to learn, especially when you're starting out and you don't have much work in the pipeline. The confidence to say no generally starts after the first well-paid project for a decent customer. Only in hindsight do you realise you were so busy with badly paid work from mickey mouse operations that you probably missed all the good stuff.

Mother Brain

Cheers for all the replies. It's definitely advice i'll be taking in future anyway.

I've a skype call in the morning with them so i'm probably going to raise the issue then and basically draw a line in the sand.

Thanks again for the encouragement anyway folks. I'll get back on tomorrow to see how this little experiment pans out!

beauf

I think we are just confirming what's in the back of your head. It's worthwhile doing some biz analysis and project management reading. That's half the job working on your own. I only did it as a contractor for a short time and struggled with it. It's doing two or more jobs at the same time If I was to go back to it, I'd try my hardest not to work on my own, but in a small group. I much prefered that and I think it was much more productive.

Mother Brain

beauf wrote: »

I think we are just confirming what's in the back of your head.

It's worthwhile doing some biz analysis and project management reading. That's half the job working on your own. I only did it as a contractor for a short time and struggled with it. It's doing two or more jobs at the same time If I was to go back to it, I'd try my hardest not to work on my own, but in a small group. I much preferred that and I think it was much more productive.

Yeah I recently came out of a six month business planning course I took to help focus me up and highlight any shortcomings I had. The trouble is this kind of thing can't really teach the soft skills effectively enough (for me at least). Networking and negotiation, managing clients etc. It's certainly not my preferred area to have to deal with but it's all part of it I suppose. I'm trying to improve at any rate!

beauf

I meant in terms of running a development project. Not running a business. That's a different thing entirely.

Mother Brain

beauf wrote: »

I meant in terms of running a development project. Not running a business. That's a different thing entirely.

My mistake!

Had the talk with my clients anyway and they weren't too thrilled to say the least but I got them to agree to a fixed term for completion of the prototype. Invoice went out today so we'll see how that pans out.

Cheers for the replies anyway folks. I'll definitely be adopting some this advice in future!

gargargar

When you are starting out you often have to be more flexible than when you have established yourself. I find in these cases it makes sense to be honest with the client. They will know you are on your own. Explain that it was agreed to be 12 weeks and it is overrunning. Most people are reasonable, especially if they are happy with your work.

I used to a lot of consulting which sounded similar to your project i.e. prototype to full build with minimal specs. We didn't get contracts signed but we would email them a statement of work (few pages covering deliverables/exclusions etc). Payment of the first part was agreement. Worked for us.