Business Re-think Part 2

In an earlier blog article I began outlining our new business strategy. That article talked about what we want. This will talk about how to get it.

The Sex Pistols sang: "Don't know want I want but I know how to get it..."

There is a lot of buzz around agile development practices, and I'm all for them. It's getting the client interested in them that seems to be the tricky part.

Here is a proposition: any time spent writing specs is time NOT spent developing, and hence it is time that is NOT getting a return on the client's investment. So (if we accept the proposition) the strategy is to minimise the amount of spec writing.

I've been down that route and it can end in tears. The problems are:

no specs = no idea what's being built for both client and developer
no specs = no limit to the scope
no specs = blown budget and time

The trick is to work out the *minimum* amount of specs that will mitigate the risk.

A quick aside: I was involved in a project recently that did not go quite to plan, and one of the main causes was the client had no idea of their business process. (They thought they did and we thought they did, but they really did not.)

Back to the main story: we're now doing a 3-part process for all new projects. The client pays up-front for the preparation of three documents, which is one day's work:

1) Project Proposal
2) Statement of Work
3) Cost Estimate

The Project Proposal contains the analysis of the business process and its aim is to make sure we all agree on what the project is about. Defining the business process up front has the effect of clarifying the client's understanding of what they do and how they do it, and how the solution will fit in and support their business. It specifies what is in the scope of the project and what is out of scope. This curtails a lot of confusion right up front.

The Statement of Work is a paper prototype of the proposed solution: mocked-up screen shots, print layouts, and a run-through of the database interacting with the business process. Creating this sorts out the data structure and the interface, and it forms the check list for the deliverables.

The Cost Estimate is the time and money to build the solution in the SoW. It clearly states that this is the first version of the solution and it's not the last, therefore changes to the project are not to be entertained at this point in time.

The time allocation is 3 hours to do the business analysis and 1 hour to prepare the Project proposal; then 3 hours to do the Statement of work and 1 hour for the Cost Estimate. Yes this is cutting it really fine but that's part of the discipline: this is the first stage of an iterative agile development process and we need to keep to short and quick. There is no time to debate for 15 minutes on whether to call the field "Surname" or "Last Name". Get it up and work it out later.

Similarly for the developers who build the database, the cost estimate will be tight so the scope and specs have to be followed closely. No cutting corners and no extra work.

Part of the success of this will be the use of a template to speed development. That's another story.

We have one client that has been through this methodology and another is coming up soon. SO far it's looking good.