Thursday, November 12, 2009

Keys to a Successful Development Project

I was reading an article about startups recently and the author claimed that success was not due to one big thing, but a lot of little things. We had a business coach a few years back that said the same thing – when we reach the level of success we’re aiming for we won’t be able to look back and put our finger on one thing, but instead, we’ll see it was many little things contributing and working together.


It got me thinking – is that true of software projects as well? Probably. This may be one of those universal laws like the Pareto principal (aka the 80-20 rule), that seems to apply to everything.


Is there one thing, one big key that will make a project successful? If I had to pick only one, I would say it would be the team, but is that enough? I don’t think so. Even the greatest team can’t be successful with a lousy idea, bad requirements or no funding. Sure they may be able to get something out the door, but will it sell in the marketplace? Will it really meet a need? Probably not.


Ok, so I guess we’ve established that I don’t believe in “silver bullets”. So back to the original premise – what are all those little things? Well certainly the team, but what about tools, processes, appropriate budgets, management support, a great idea, customer need, stellar marketing, support, sales, etc……


It really does take a village!

Monday, November 2, 2009

What does a software developer need to begin design?

Too many projects begin without even a hint of a written understanding about what is to be built. Unfortunately many of us have been there and lived through the pain of redesign and project slippage. At the other end of the spectrum some write suffocatingly detailed Requirements Documents. Masterpieces of literature that developers and managers don’t actually understand if they read it all! As in the case of no written requirements, the project usually ends up in the same predicament --- redesign, rework and missed opportunity.

In my experience developing embedded systems or software applications the big picture requirements must be spelled out. They should contain at a minimum the following: performance goals, safety factors, Human-Machine Interaction, testability, external interfaces, deployment, and target cost for hardware designs.

Defining the products requirements does not have to take a very long time. I find that in most cases this phase should take on average 2 - 4 weeks working collaboratively with the major stake holders.

The important point to keep in mind is that the requirements document must be be in a form that is easily understood by the technical team as well as non-technical management. Keep it as jargon free as possible. Define all terms.

INCLUDE PICTURES!

For example, an excellent way to define the user interface level independent of the actual technology used are pictures. It is more effective to draw a screen or touch panel then to try to describe it. Even more effective, use a rapid prototype application to create a demonstration of application. This is the most effective way to create a common vision between developer and manager of the look and feel of the resultant product. Be sure to include one or more block diagrams to illustrate the system and interfaces.

The next time you start a project please don’t settle for 10 bullets on a napkin!