Everything We Do at Spud Can Be Explained Within Four Phases: Define. Design. Develop. Deliver.
Requirements engineering is a multi-faceted process, driven by a close analysis of your business and its systems. This is where we come up with the formula to ensure your project’s success well into the future.
Once we know what you’re looking for in your project, we design the supporting flow diagrams, wireframes and Design Specification documents to get the project going. The flow chart would be the current business flow. Then, we take it from there and change the flow chart to be what the software flow will be. It is a two-step process of learning how you currently operate your business, taking notes of how things need to be changed and updating the flow diagram of how the new business process will work utilizing the software.
Once we get sign-off on that, we go into the wireframes. This is actually where we design the software screens, what the program will look like and how it will flow. For example, you click “here”, that screen appears, you click “there”, that screen disappears, etc. Data entry forms, tables, image/document upload pages, reports, etc., are all created in wireframes. Once we get sign-off on that, we write the Design Specification. This is what you will sign off on before we start writing code. This is the most important process because this will guide everything from the database structure to how the program will work, as well as our entire understanding of the project. If something is not in the Design Specification, then it is not part of the project. We want to make sure that we’ve included everything we can.
Once you’ve signed off on the Design Specifications we begin development – from internal kickoff meetings to timelines, release schedules and client sign-off, we’ve got everything covered to bring your project to life, including plans for enhancements you might have down the road.
Development begins with an internal kick-off meeting where we sit down with our leads and go over the entire process. This is usually a 4 or 5-hour meeting with 4 to 5 people in it. We make sure we think through all possible scenarios and that everything is covered. If for some reason, something comes up that we need client approval for, we go back to the client and get that approval. During that meeting, we define the timeline and the release schedule. We usually break down a project, depending on size, anywhere from 3 to 9 releases. The timeline and release schedule will spell out when and what the client will be seeing in each of the releases.
After each release, we will receive sign-off. It is during the sign-off process of each release that there may be change requests. This is, unfortunately, not uncommon. What usually happens is that once the client is actually using the software, they think of things they would like the software to also do. This is not something that has been missed in the Design Specification; this is an enhancement that they feel would make the software that much better.
With change requests, we have a few options. Earlier in the process, a change request may be able to be addressed at no additional cost, due to it being something that, by incorporating it, effectively changes something else and is a wash regarding the labor involved to do it. It could also be something that could be done at the end of the project. Or, it can wait until after we’ve gone live and we just put it on a list of things to do “down the road”. However, if there is a change request that has to be done right away and is something that has already been coded (and has to be undone and redone), or if it is something completely new that is not part of the original project scope, we provide an additional proposal to make that change.
The delivery is usually done as releases. A typical project has 9 releases. Each release has specific functionality and enables you to see the software take shape. As each release is completed, we get sign-off from the client.
When the entire project is in the QA environment and we’ve received sign-off from you, that is when we go to our final phase, which is “Deliver”. That is when we push everything to production. Now, production can be in our environment, it could be onsite in your environment, or it could be in the cloud or at one of your hosted facilities. Whatever it takes, we put it in those environments. This is something that has been defined in the early stages of the process so there shouldn’t be any surprises. What we like to do is actually have the production environment setup at the early stages so when we do go live, it is just copying the files up and things are working instead of having to work out the kinks later with internal IT or some third-party hosting provider.
After we’ve delivered the final product, we like to schedule a “Lessons Learned” meeting with our clients. Prior to that, we first have an internal “Lessons Learned” meeting where we sit down and write up what went well with the project and what could have been done better, as well as what we are going to do differently in the future. We then meet with the client and go over the “Lessons Learned” with them. We provide them with our insights, as well as obtain feedback from them. We discuss any remaining open items, including any change request or enhancement after the project was completed. Finally, we define if those should be completed now or later and what we need to do to make those additional changes happen.
Does Your Company Need a Better Process?
Contact Spud Software for a free 1-hour exploratory meeting and let’s see if we are the right fit for your needs. We’ve been providing the systems and solutions that take Michigan businesses to the next level.