I have been working in the IT field for 25 years. Creating small business applications is my specialty. During my past projects, I have mastered steps they allow building successful application (well, in most cases 😊). If you are in the field longer, you probably heard 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 bid does not mean much from the perspective of delivering product. It merely states there is a mutual intention to reach certain goal and we agreed upon certain (or rather somewhat uncertain) rules.
The goal in this step is to dive into user expectations. The assessment of user skills is one of the important outcomes, with an objective to design solution which fits to customer’s existing practices nicely.
Important part of this step is to educate user about pitfalls of custom software development process. We will most likely find several issues customer have not thought about yet. We will deal with those they are relevant to the software. For others, an alternative which does not need coding can be found (one example of such approach is exporting data to Excel for further handling).
The outcome of this step is either:
Decision not to continue.
Detailed requirements specification
The right to step-back is available for both sides: 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.
Customer gets a functional, tested version of the application.
Application now handles all steps and scenarios discussed during step 1. I ask customer to crash-test application. It is quite possible to find several bugs they need to be fixed.
Further, customer likely finds several issues he has not though about earlier.
Both, bugs and gaps in requirements are handled in the next step of the process.
Bugs are now fixed and functionality of the application is as expected.
Previous step could uncover gaps or misunderstandings in expectations. Fixing bugs is my responsibility. However, gaps in requirements are shared responsivity of both sides. I reserve right to ask for price increase in case estimated work effort significantly exceeds initial estimates.
Customer receives now final version of the application.
I ask customer to repeat whole testing as in the previous step.
The outcome here is acceptance of application by customer.
Customer now owns his new application and he is ready to start using it. My past projects taught me “nothing is ever perfect”. Customer will encounter certain issues during routine application use. We will discuss possible approaches until customer is fully satisfied with the application.
Any possible required code changes at this point are out of scope of the original agreement. As I mentioned earlier, there is usually an alternative how to handle specific scenarios without need to change code.
My last obligation to Customer is to create 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? Or you hire a new employee who will take over your agenda and he need a training?
I will charge hourly rate for such situations. We need to discuss specific terms as it might not be possible to fulfill your request immediately. In rare situations, it might not be even technically possible to successfully assist you. Such services are provided on best effort basis.
You might also need additional changes in program. I will be happy to assist you. Bear in mind though 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 are happy customers. I build my business on referrals so the previous sentence is not a cliché. Steps explained above might sound excessive for a small application. Let me remind you: only some 20% of IT projects deliver upon promise.
I can’t foresee all the obstacles in the project but my approach makes whole development process much more predictable a manageable. Issues identified during the process are handled promptly, before they become a showstopper.