What To Expect When Buying Software Consulting Services

Preface

I've had the idea of writing a book whose intended audience is the customers of software consulting companies; put another way, a book that my clients should read. The reason for this is that I after having worked in software consulting for nearly 20 years, I find time and time again, my clients themselves are often the greatest hurdles to their own success. There are many reasons for this. This book strives to capture some of these reasons for the purpose of avoiding a failure or at least some of the many pitfalls of this experience.

Any human endeavor is fraught with challenges, and this book is not an attempt to place blame on anyone in particular, but rather it is an attempt to help the customers of software consultants to be more sucessfull in software application development and implementation by providing them insight into both sides of the story which is often very, very difficult to do in the context of an ongoing project.

Business Models/Agreements

Fixed Bid

Time and Material with Deliverables

Time and Material

• Embedded Expert

Process Approach

Waterfall

Agile

Challenges

Requirements: Client Thinks They Know What They Need

Requirements: Client Doesn't Know What They Need

I have found that both in life and in software projects, indecision has is more devastating to project schedules, dollars and quality than a less than perfect decision. Why? Poor decisions can be a tool to understand mistakes and then correct them - often in less time than waiting for some magic aha moment that will give you the right answer. While one naturally wants to avoid making mistakes, sometimes a mistake must be made in order to make progress. Without progress, days on the project calendar disappear, budets dwindle, project stakeholders nerves wear thin and politics kick in. It takes everyone involved to a bad place that has everything to do with negative emotions and little to do with solving problems. Timebox yourself then make that big decision. Now you can manage the decision as a risk while the project moves forward.

Design: Client Not Knowing/Understanding Their Own Business Process and Rules

Quality Assurance: People don't know how to report a defect

On smaller projects, you will often find that the resources executing manual test proceedures and documenting defects are business stakeholders or resources who do not have a background in software development processes. Even more surprising is even resources that do have a software developement background do not know how to report a defect in such a way that it results in the highest effeciency - and least amount of time and therefore lowest cost - in correcting the defect. Less than optimal defect reporting will resulting in the defect being a placeholder for a non-trivial amount of effort to understand what the problems is. This means time and effort spend in emails, phone call and other such communications to understand what the issue is about so that the developer can find and correct the problem. Below is a receipt that should push toward the optmimal route. Miss any elements in the receipt and I'll bet you a dollar that your defect will take more time and cost you more money to fix. Don't be lazy either, regardless of why the defect report is incomplete, it will still cost you more time and money.

Receipe for reporting a Defect

Various defect tracking tools have different "fields" or "properties" and workflow, but the important elements are largely independent of any of these aspects of defect reporting and tracking. In order to efficiently resolve a defect, a defect report must contain the following elements:

1. Unique Id and a Meaningful Name 1 . The outcome expected
2. The steps to reproduce the problem
3. Expected outcome
4. The actual outcome

Defect Reporting Anti-Patterns

• Two bugs in a single defect report (anti-pattern)
• Requirement as a defect