Start With The End

Building anything with software is hard, often frustrating, or is for me anyway. As it (program, website, whatever) does not exist and in the end is just zeros and ones well organized, it (the software project) can move, change, shift, endlessly.

Call it feature creep, defined by searchCIO.com as:

a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren't originally planned and resulting risk to product quality or schedule. Feature creep may be driven by a client's growing "wish list" or by developers themselves as they see opportunity for improving the product.

Every time, I repeat, every time I worked with software developers, on client project teams I led or projects of my own, I suffered from, fought and, truth be told, caused feature creep. The ability to add this or tweak that is just too dang tempting to pass up.

What brings this on? The new website for this blog! What will it contain? Look like? How will video be treated? Photos? Templates? Webinars? What features will it have? Lots of unknowns for just this little project. How to decide the site design writ large then (the more important) how to control the process?

Start with strong leadership, Dick and the senior IT team he's assembled. Yet neither will be involved daily on such a small project, so the question remains: how to keep the project on the rails? Define the end before you start the job.

Received a document yesterday, a website development model, the "this is what we expect website projects to prepare before starting coding, and how we expect ."

We humans do what our managers (spouses, officials) pay attention to, what they reward us for doing and punish us for not doing. A necessary inital step though is measurement, for how else would the manager know what we've done/not done?

"What gets measured gets done," five simple words (from Tom Peters ... I think) that I have repeated ad nauseum (or at least ad headache) to clients. Yet before measuring one must know what the goal or end or objective is. Vastly simplified (yet still correct) the steps are:

Set Objective (the desired end)
Decide how/where/when/what to measure
Explain objectives and metrics to responsible person(s)
Measure
Analyze
Adjust
Repeat

This document goes a long way to achieving the software objective/specifications; it explains in detail what the site should look like, colors, fonts, layouts, and what features it should have, and the steps to follow to alter the specs. Once all parties sign off on it Dick and Acme now have a way to measure what gets done.

This is a kindergarten class in performance management, but hey, we all started in kindergarten. And heck, Robert Fulghum thinks kindergarten lessons are all one really needs to know. Maybe, but I still plan lots more on measurement (a squishy target I admit, but still one my future actions can be measured against).