Having completed two Plone-based projects yesterday I now want to take some time and reflect how these two projects went down and what I’ve learned during their course – not so much on a technical level but more from a management perspective.

Both projects differ quite from each other technically. One is basically just a “skin job” for a site using standard ATCT objects and a non-customized version of the Plone Tableless skin for editors, while the other is based on a multipage UML-diagram and requires customized editing interfaces and workflows).

Both fulfill their specification – but neither are finished. In my – for the time being ;-) – humble opinion I now think that it’s basically futile to try to release a 1.0 version of a site because you can’t create a polished interface without customer feedback. And – at least in my experience – most clients find it hard to provide specific and valuable feedback on beta stages of a site. I found that I’m doing nobody a favor when submitting half-finished inbetween-versions of a product for customer review. In the end I just confuse him (or her) and waste everybody’s time.

In these two specific cases we’ve now all happily arrived at 1.0 and are now (just as happily) taking ‘em for a ride and are collecting a wish-list of improvements that will turn them (hopefully!) into really cool sites. The key point here – and my lesson to take home – is to communicate this approach to the client from the start. As a developer you not only have to manage ressources and time but – perhaps first and foremost – expectations – i.e. tell the client clearly that the “1.0” will be a “rough diamond” – valuable but not necessarily pretty, yet.

In conclusion, here’s my proposed “life cycle” of a plone project:

1. initial consulting (What is Plone? Is it the right tool for the job? free)
2. specification (based on hourly rate and thus variable – but small in scope. Under no circumstances complete this step without having read Joel Spolsky’s Article Painless Software Scheduling first!)
3. implementation of 1.0 (the largest part of the work but based on the specification and thus fixed price and fixed date)
4. specifying, what’s still missing based on the real experience with the 1.0 – version (most work in this part done by client – no charge here, either, but no fixed time frame)
5. cleaning up to 1.1 (based on the findings in step 4 – fixed price and, again, fixed date)

I think this represents a fair trade-off between offering realistic compensation for the developer on the one side and budget security for the client on the other side. Because there are always technical uncertainties involved in any project that could endanger its success and in my view it falls into the developer’s responsibility to protect the client from these (i.e. if I have to spend some extra time during phase 3 wrestling ArchGenXML or learning how to write test cases that shouldn’t raise the cost of the project – especially since the client has absolutely no influence over this part anyway – the client needs to be protected from the developer, so to speak.

Not so with steps 2 and 4, though: here it is almost entirely up to the client to dictate the terms and thus the price. Here it’s the other way around: the developer needs to be protected from the client ;-) (by using an hourly fee in step 2 and by creating a second specification for step 5.)

Now I know for a fact, that meanwhile some of the more seasoned Plone and Zope developers happen to read this blog, too and I’d specifically like to ask you to share your opinion and/or experiences on this subject.

I’m sure we all can profit from being able to deliver slick Plone sites on time and within budget ;-)