Solve Small Problems and Tackle the Big One

Part of the art/science of programming is taking a big problem and breaking it down into smaller problems. The idea being that on their own the smaller problems are far easier to solve, and in doing so you then find that the big problem has also been resolved. It's a technique I use regularly, breaking a project down into its base functionality and then working on and testing those functions until the whole project has been written.

It's a technique which is equally useful at the project scoping/planning phase. It is very easy to come up with a project vision which is very wide ranging affecting, many different aspects of a business. These are the kinds of project that can all too easily fail, either through an inadequate budget, time, technology or human skills not being up to the projects ambition.

When envisaging, scoping or planning a project it's worth taking a step back and breaking it down into the smaller problem areas. Questions such as, which components are fundamental to the project? Which are 'nice to have'? Which need to be written first? Can then be asked, non-essential components can be rejected or postponed, and hopefully an iterative project plan will emerge. A plan which breaks the project into various phases with functionality being deployed at the end of each phase.

This should result in the business getting access to core new functionality more quickly while at the same time making the transition to the new system less challenging for the users and business as a whole. It may also mean that budgets can be managed more easily with development being spread out to ease the impact on cashflow. Another important advantage is that feedback from earlier phases that have been deployed can influence the development of succeeding phases, perhaps a dialog isn't user friendlly enough or a business process has changed as more efficient processes are identified.