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.

Natural Development

In 1859, Charles Darwin set out his theory of evolution by natural selection as an explanation for adaptation and speciation. He defined natural selection as the “principle by which each slight variation [of a trait], if useful, is preserved”.

My take on natural selection in software is that with each subsequent update, the functions that are most useful should be preserved and those that aren’t should either be dropped, or improved if they show promise. This method will quickly produce effective systems that are tailored for their specific requirements. With each successive update, the system becomes more aligned with it’s intended use, even if that changes from time to time.

To achieve this result there needs to be a few things first.

• Regular updates of the software
• Measurable feedback on the changes
• Clear objectives of what you want to achieve

These roughly translate into offspring, fitness and drive; Each generation (update) of the system needs to be evaluated (feedback) for fitness against the objectives (drive).

Software development has already formalised this process (in 2001), calling it Agile Software Development. The fundamentals are here and I’ve been doing it for a long time.

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.