Involve the client

I was talking to one of my developers a few days ago, about how I like to demonstrate completion of The Design Phase.

Having a face to face discussion about the project’s design is a good way to start, but having an interactive presentation (model) to help them “feel” their product is orders of magnitude better. When it’s interactive the client is engaged with the product early and is able to experience their product prior to development. This way I can quickly and simply prove that I was listening when they were telling me what they wanted (during the Requirements Phase).

And with a model of version (n) in front of them, the client can begin to think clearly about version (n+1).

Because everyone in this industry knows; A requirements document is never a perfect description of what the client wants, it’s the best version this time around.

Documenting for Outsourced Development

I love the idea of outsourcing development. It forces you to evolve your business processes and it’s entirely in line with the code re-use paradigm found in programming:

[Try to] write re-useable code.

When you are outsourcing your development (especially when you go off-shore) this becomes:

[Try to] write re-useable documentation.

You can no longer have a casual conversation at the coffee machine* with Fred the Coder about what it was you actually meant when you said, “The system needs to save the booking”. The document must stand by itself, it needs to be portable, it needs to be re-usable.

The document creator has to provide a Rosetta Stone for the project: A record of the non-technical description provided by the client and a cohesive translation into the technical description for the development team. When questions are asked by either group, those answers should be noted and incorporated into the (next) version of the document. Even after sigining off on a final version.

If you can provide the perfect Rosetta Stone, then you will only have minimal interaction with the development team which reduces the management overheads. Badly written documentation results in far too much live translation and that leads to missed dead-lines and budget blow-outs.

*or PS3 or Kitchenette etc.

Post-Implementation Review

After the Initial Specification; Development; Testing and first Live Deployment (Implementation) many companies forget the next step.

Post-Implementation Review.

This can be as short as a five minute meeting to pat everyone on the back for a job well done. The point is this; Is the business happy with the results?

Once the process has been live tested there will be new insight into how things work:

• Were the various steps actually performed in the expected way?
• What was different?
• Did the differences have an impact on the overall process?
• Is it worth trying to improve the results?

IS IT WORTH IMPROVING THE PROCESS?

If there are legitimate complaints about the process, then it needs to be changed and the development cycle starts again. If those complaints aren’t worth resolving then the people involved need to be notified of the decision. That way, when the process is run again, everyone knows what to expect and the process will proceed as smoothly as possible (because you’ll know what areas are going to cause issues and the people involved can adjust their expectations of the outcome). This is how good business processes are developed.

If the outcome isn’t what you expected you have two choices: Change the Process or Change your Expectations.