Feb
20
2009

Domain exploration – really

The last few week have been quite exhilirating! Two weeks of really exploring a domain, getting to know a new client’s business and language. I have always liked going through such a phase and one does not always get the chance to do something like that for two whole weeks at the client’s site.

Preparation ( including writing big parts of its proposal), execution and wrap-up of this domain modelling phase took longer than those two weeks, of course and included a lot of help of colleagues. A big investment for a still uncertain project, even while it might be worth it. Luckily, the client was prepared to pay us for performing this modelling phase. This made it possible to do it the right way, with a session to determine the vision, domain modelling sessions, interviewing users of the legacy system we will be replacing, while taping it on camera. Playing a scaled up version of the planning game and explaining results during a final presentation. And we documented our findings in four documents, presenting vision, requirements, architecture and planning & process.  Of course, it should not stop there! But our client will weigh our proposal against that of a competitor, so we will have to be patient for a little while longer. But everything seems to be going right.

We made an agile proposal for the project. It contains a summation of costs for the whole project, within certain bandwidths. This is something you really can’t do without, a client needs to see if starting the project is going to even have the possibility of being worth it. Of course, working in an agile way, you cannot detail everything. Better said, you don’t want to, because it would only cost time and money and does not help the project in any way. Because while developing, things will inevitably change. You want them to.

It can be a challenge estimating an agile project. But somehow a client needs to know something to base his decision on to start it. I think the key is staying honest. Explaining where and why you cannot be completely certain, what is going to drive the costs up and down, what are the possible safety measures you can take to meet certain commitments you are prepared to make, like meeting a certain deadline. If you start out being dishonest, the project will never have a fair chance, in my opinion. And the client will not have had a fair chance to weight the costs, risks and quality of your proposal. Inevitably, this will become clear during implementation or production. It is already rather hard delivering a bduf/waterfall project that holds up during a certain acceptance phase that turns out to be a big mess under the hood during the production phase. Doing it again and again, like in an agile project, is near to impossible.

Written by Rick | Tags: , , |

No Comments - Leave a comment »

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud