Quick and dirty projects are rarely quick but always messy

We've all been on them before. A salesman gets a request from a client to implement a "simple process", and the client books ten days work at a fixed cost which means you're obliged to deliver in that time. You go in, do the work to the minimum standard as that's all the ten days allows you to do on a project that should really have been twenty-plus days, and then leave. And that's when the trouble starts.

Because of the limited time frame, nobody bothered researching the requirements and creating a functional specification with specific deliverables and tests for suitability of purpose, and even more importantly, getting that functional specification signed off by both the client and the vendor. Now the project is being delivered on the basis of a few emails that went between the client and vendor which kinda said what they wanted it to do but didn't explain that when field X had a particular value then the process had a slightly different variation. And that the files aren't really fixed length but have optional fields at the end. And that this type of identifier needs to be translated to some other type of identifier.

So the solution delivered after ten days doesn't work properly because it doesn't do what the client needs it to. Sure, it does everything that was in those mails that went around, and it does a few other things that you found out on site, and it may even pass a few of those unit tests if you had time to write them. However that doesn't matter, because for the real world task it needs to do it isn't fit for purpose.

But who's responsible? You've delivered what you believe they asked for in the required time frame, so if they want any changes then they'll have to pay you more to go back in. But they don't think you've delivered what they asked for because, although they didn't write it down, they know how it should work and it doesn't so they want you to come back in and fix it for free. Cue a couple of weeks of corporate wrangling, and in the end the vendor may break down because they want more work from the client, or the client may break down because they want the solution to work.

So it's another week later and now the solution is working, the client wants to monitor it to make sure it keeps on working, and get some reports of what's going through the system. But because you barely had time to get the thing working in the first place you skimped on instrumentation and error handling, and you sure as hell didn't put in any reporting functionality.

They come back again and say the solution isn't fit for purpose because of this, and you point out that it didn't say in any of those emails that it had to be monitorable or have any reporting. The client responds with "well we assumed that was obviously a requirement as it is for all solutions". This is a valid point, but as it wasn't in any spec then it wasn't agreed to be delivered. So another couple of weeks of corporate wrangling later the vendor agrees to do the work, probably at a reduced rate as nobody at this stage can decide whose fault it is and everybody just wants to get the project over and done with.

Finally, another week later, the project is delivered, and it works like it needs to, and it can be monitored, and it has reporting. All the things that were known to be necessary at the start, which could have been written into a functional spec, delivered in four weeks, and made everybody very happy.

Instead you spent four weeks delivering it because that was what was really needed, and anther four weeks in corporate arguments about why the solution didn't work how it was expected to and who should fix it at what cost. As a result the project is well over the original timescale of two weeks, and well over the original budget. In addition, the project has left a bad aftertaste which has pretty much destroyed any relationship between the companies.

Still want to take that quick and dirty ten day project?