Consultancy Approach

"Helping software teams deliver solutions quicker" represents the main benefit of using my services to improve your software development efforts.

Software development is a difficult job; there are many ways for it to fail to live up to expectations: late deliveries (the most common), delivering the wrong solution (next in line), and the ultimate failure, not delivering anything at all. Despite your protests, the latter happens much more frequently that we like to admit. Such failures are rarely to do with technology although in our fast moving industry it can be the 'march of death' for projects that take too long. Lengthy timescales also cause teams to deliver the wrong solution. It's wrong because the needs of the stakeholders (customers or purchasers) have changed in the meantime and these changes are not reflected in the final solution. Their business also changes and in many segments of industry it changes as quick as the technology! Finally, most projects are usually late. There can be a number of reasons for this: unrealistic estimates, excessive 'safety' padding, over-ambitious plans, changes in staff, wrong skill-set, multi-tasking to name but a few.

Take the example of excessive 'safety' margins added to task estimates. Most developers and their team leaders add a form of safety buffer to their basic estimate. Say a developer estimates that the job will take 7 days, he or she will round it up to 10 days. This safety margin covers any problems that they may encounter (Murphy's law) and gives them a negotiating stance when the demand comes for a shorter timescale. Now a number of things happens: 1. the developer adds safety margins to every task, 2. the team leader adds more safety to the group of tasks, and 3. the project manager adds even more margin to the final plan. This can result in an increase of over 200% on the basic estimates.

But still these projects come in late despite this safety margin, whether it was squeezed or not! One example for the over-run is called the student syndrome. As a student there is a tendency to put off a task until the last minute: deadlining. If the developer estimated 7 days but the plan shows 10 days, they often put off starting the tasking knowing they have 'plenty' of time to do it. They may even delay the task for 5 days and plan to work that little bit extra. But Murphy strikes, and instead of plenty of time, they find they needed that safety margin. They are now late. Add up all these late bits and the project is always going to be late.

Every project and development team will have a different problem that needs to be resolved. This is why I list the areas of expertise that may be employed in helping your development teams deliver solutions quicker.