Let us start with the basics. The purpose of writing software is to transform a manual process into a digital one, or to replace an inefficient system with a solution that delivers improved functionality. The bottom line is business process improvement. That can mean lower staffing costs because data does not need to be manually entered into multiple systems. It can mean better operational visibility for improved decision making. It can mean implementing efficiencies that would be too difficult or cumbersome to do any other way.
Once you have decided to undertake a business process transformation project you are faced with 2 choices: buy or build. Do you buy an off-the-shelf (OTS) software product or do you develop your own custom solution? The advantage of OTS is that it is cheap and you can have it right now. The disadvantage of OTS is that it is almost never a perfect fit for your business, and often it is not even close. The advantage of a custom solution is that it is a perfect fit for your business, the disadvantage is that it tends to be expensive and there are typically long lead times to get it into production. It is true that some OTS vendors offer custom development services, in order to close the sale, but most just want to sell you what they already 'have in the can'. Companies that buy OTS just learn to live with the limitations. I am not going to say anything more about OTS, the rest of this blog assumes that you have considered OTS and decided to explore custom software development.
Every custom software development project goes through the following stages;
Requirements Document
Architecture
Design
Quote & authorization to proceed
Schedule work & Estimated delivery dates
Programming
QA (testing)
User Acceptance Testing
Documentation / Help / Training / Support
Release
Change Management
Maintenance Releases
If you want a successful outcome you must execute these steps in order and not skip any.
The Requirements Document. This document describes in complete detail what the new business process is supposed to do and is created by a Business Analyst. Every detail, no matter how small, must be captured in this document. Typically the BA would start by analyzing the existing process and building out from there. This involves interviewing everybody connected to the project and getting them to describe in complete detail what they do currently and how they would like the new process to work. As a general rule the BA will allocate 2 - 3 hours to talk to each person connected with the project and then 6 - 8 hours to write up their findings. So if there are 10 people connected with this project you should budget 110 hours of time.
Architecture. Architecture refers to the environment in which the application operates in. Is it a Windows app? A web app? Will it run on a company server or in the Cloud? Does it need to connect to any databases, and where do they reside? Will users be accessing the app from outside the company LAN? If so, you will be creating a web app. If it will only be run inside the company LAN then it can be either a web app or a Windows app. Architecture also includes considerations about programming languages and databases. If you are writing a Windows app the programming environment will probably be .Net. If you are writing a web app there are probably 50 languages to choose from but they all do essentially the same thing because they all have to support HTML and JavaScript. Likewise with relational databases, there are 6 - 8 to choose from and they all do essentially the same thing. Proper consideration of architecture should uncover potential problems that can have a significant impact on the design. For example; as of this writing you can not give a web service sufficient permissions to call an Office library, meaning that your website can no longer create Word documents and Excel spreadsheets. If creating Word documents or Excel spreadsheets is central to the operation of the application you are creating then you will need to do this from within a Windows app.
Create the Design document. The design document represents the instructions to the programmers. It contains complete process flow information, and all UI components represented through layouts, mock ups and wireframes. All pages and every object on each page must have detailed instructions for each property and behavior. To create the design document you will need to engage the services of a Systems Analyst to work with the Business Analyst. The job of the SA is to manage the technical aspects of the instructions in the design document. Also, unless you have a top notch database person on the programming team, the SA should be qualified to step in and provide advice on any database design questions. Once the design is complete you must get upper level operations management to sign off on it. Having operations agree that the design is complete and correct will save you from having to deal with any misunderstandings later in the project. This is critical if you are operating in a client / consultant relationship, but it is a good idea anyway. Time estimates to create the design document depend on the complexity of the project.
Quote & authorization to proceed. Once you have the design document complete and signed off it can go to the programmers for a quote and delivery estimate. If you are dealing with staff programmers the quote will come back as some number of hours and an estimated delivery date. Depending on the complexity of the project the programmers will need 2 - 4 weeks to pull this information together. If you are dealing with external programmers the salesman on your account will be your point of contact. Be sure to get a total dollar quotation and a hard delivery date. If you decide to go with external programmers you will have to negotiate contract terms which should include milestones, progress payments, ownership of and transfer of the source code, what happens if they can't finish the project, what penalties will be imposed if they miss the delivery date, some warrantee period (4 to 6 months) at the end of the engagement where they will fix bugs for free, etc. Your legal department will be able to help with the details. Understand that during the warrantee period the vendor will argue that some of the bugs you report are not bugs but rather enhancements, and are billable. After the warrantee period all bug fixes and enhancements will be billable.
Once the conditions of the engagement are agreed to the quote can go to management for authorization to proceed.
Schedule work & Estimated delivery dates. Once management has agreed to proceed with the project you can schedule the work and lock in the delivery dates.
Programming. Once the programming gets underway you will want regularly scheduled reviews to make sure that the project remains on track. If you are dealing with external programmers be sure a current version of the source code is transferred to your organization after each progress payment. It would also be good idea to have the vendor send someone over to your offices to compile that source on one of your computers and demonstrate that it does execute the most current version.
QA (testing). As the software development passes the half way mark the testing can begin. By this time there should be several sections of the application that are complete. For small to medium projects 1 QA person should be enough. For larger projects you may need several. It is QA's responsibility not only to find bugs, but to catalogue them and track their resolution. QA is also responsible for ensuring compliance with design. Depending on the size of the project, testing can continue for several months after the programmers have completed their work. There usually comes a point in most software development projects where management decides that the benefits of going to production with this product, as is, outweigh any benefit of delaying the release so the last obscure bugs can be fixed.
User Acceptance Testing. As the QA process nears the end you will want to bring in the operations people for UAT. In an ideal world your operations people would be engaged with the QA process from the beginning, but that doesn't always happen. UAT provides them with an opportunity to review the application prior to release. This stage shouldn't result in any surprises, but sometimes it does and you should be prepared for that. Most often UAT uncovers a mismatch between the way the software behaves and an operational requirement. This will usually have to be fixed before the software is suitable for release.
Documentation / Help / Training / Support. These 4 items tend to get overlooked in the rush to get the new software finished and into production but they are important. Users will appreciate having formal documentation, it gives your work a polished look. User documentation becomes particularly important if you are planning to sell the software to 3rd parties. For the same reason, on-help is valuable. Proper documentation and on-line help lessens the burden on support because your users have other sources to get answers to their questions.
Your users are not going to instinctively know how to use the new software so you will have to run training classes. One particularly effective technique is to record a 'live' training session and post that video so that others can watch it when they have time. You need to have a plan for training and this plan needs to be communicated to operations well in advance of the release.
The support function is essential. You must provide your users with someone to call when they have questions or want to report a bug. Fortunately you will already have subject matter experts available - your QA people. The QA and support skill sets are nearly the same, the major difference is customer service skills, but for many QA people working in support is a natural transition.
Release. This stage should be anticlimactic. If everyone in operations is properly trained and supported the transition from the old process to the new software should be a non-event. You will have had a stable build running on your production server for several weeks now. In consultation with operations, pick a date and switch everybody over.
Change Management. No matter how careful you are with the preceding steps, once the software enters production you will have to deal with enhancement requests, typically a lot of them. This is because it is impossible for users to imagine all the different ways software might be able to help them as long as it is just an abstract concept on a whiteboard. Once the new application is in production users start thinking about all the ways it can be changed to improve the business process. Enhancement requests must be treated like they are mini software development projects. They must properly designed, costed, approved and catalogued. This is because they cost money, either staff programming time or, in the case of external programmers, invoices from the vendor. Eventually management will ask you why the project costs are spiraling out of control. You want to be able to point to all the enhancement requests as the reason for this and in order to do that you need all of it properly documented to support your position.
Maintenance Releases. As bug fixes and enhancements are implemented you will want to get those changes into the hands of your users. Once a build becomes a candidate for an update it must be rigorously tested and no further changes can be made to it. In consultation with operations, pick a date, usually a Monday, and use the preceding weekend to update the production site. Be prepared to revert back to the previous release should a serious problem arise.
In Summary. You can follow the steps listed above and still not get a good result. But if you don't follow a structure that includes these concepts it guarantees that you won't get a good result. This isn't the only framework for managing a software development project. There are other approaches to managing this problem but they all, in some fashion, capture the ideas discussed above. Also, keep in mind that you can not skip a step. For example, if things are getting behind schedule there is often a temptation to cut corners in QA. This is a mistake because if you release a product to production that has not been properly tested then every time your users run into a bug they will become increasingly unhappy and this will reflect poorly on you. It is better to wait and release something that works properly.
Final Thoughts. Continuously monitor the project's progress and deal with any problems that arise. Small problems, left unattended, will turn into big problems and big problems are harder to fix. If you find an issue that is going to negatively impact the delivery date, tell everybody up and down the chain right away. Waiting until the end of the project to tell upper management that the software is not ready might get you fired.
댓글