I have been working in the IT field for 25 years. Developing small business applications is my specialty. I have mastered steps that allow for successful application-building (well, in most cases 😉). If you are in the field longer, you probably heard the saying: “only some 20% of the IT projects deliver upon project promises”.
My concept of developing software tries to identify uncertainties or gaps in expectations early and respond to them accordingly.
Well, step 0. Winning a bid does not mean much in delivering a successful product. It merely states there is a mutual intention to reach a particular goal, and we agreed upon certain (or rather somewhat uncertain) rules.
The goal of this step is to dive into user expectations. The assessment of user skills is one of the critical outcomes, intending to design a solution that fits the customer's existing practices nicely.
An essential part of this step is to educate the user about the pitfalls of a custom software development process. We will most likely find several issues customers have not thought about yet. We will deal with these relevant to the software. For others, an alternative that does not need coding can be found (one example of such an approach is exporting data to Excel for further handling).
The outcome of this step is either:
The decision not to continue.
Detailed requirements specification
The right to retreat is available for both sides: the customer and myself.
Well, it seems we successfully got through the initial obstacles. Ideally, we have agreed upon specific scenarios this new software needs to handle. Some Excel or text files highlighting those scenarios are typical outcomes here.
The customer gets a functional, tested version of the application.
The application now handles all steps and scenarios discussed during step 1. I ask the customer to crash-test our application. It is quite possible to find several bugs that need to be dealt with.
Further, the customer likely finds several issues he has not thought about earlier.
Both bugs and gaps in requirements are handled in the next step of the process.
Bugs are now fixed, and the application functionality is as expected.
The previous step could uncover gaps or misunderstandings in expectations. Fixing bugs is my responsibility. However, gaps in requirements are the shared responsivity of both sides. If the estimated work effort significantly exceeds the initial estimates, I reserve the right to ask for a price increase.
The customer now receives the final version of the application. I ask the customer to repeat the whole testing as in the previous step. The outcome here is acceptance of the application by the customer.
Bugs are now fixed, and the application's functionality is as expected.
The customer now owns his new application, and he is ready to start using it. My past projects taught me that “nothing is ever perfect.” Customers often encounter unforeseen hiccups in routine application use. We will discuss possible approaches until the customer is delighted with the application.
At this point, any possible changes are out of the scope of the original agreement. One notable reason for this approach is that code change is costly.
Changing code is not the only option, however. There is usually an alternative to handling specific scenarios, as I mentioned earlier.
My last obligation to the customer is to create a user manual. Online training for additional users is possible.
Well, you are my happy customer now. But what if your computer crashes and your data are corrupted? You can also hire a new employee who will take over your agenda, and he needs training.
In such situations, I will charge an hourly rate. We need to discuss specific terms as it might not be possible to fulfill your request immediately. It might not even be technically doable to assist you in some situations. Such services are provided on a best-effort basis.
You might also need additional program changes. I will be happy to assist you with your request. Remember that extensions or alterations of the existing code are more time-consuming than initial code development. We might need to go through a code testing cycle, similar to initial code development.
My goal is happy customers. I build my business on referrals, so the previous sentence is not a cliché. The steps explained above might sound excessive for a small application. Let me remind you: only some 20% of IT projects deliver upon a promise.
I can't foresee all the obstacles in the project. However, my approach makes the whole development process much more predictable a manageable. Issues identified during the process are handled promptly before becoming a showstopper.