In software development, many of us are responsible for improving the day to day operations and corresponding efficiencies of our users. We are often asked to create a system to satisfy a current or future need. While properly designed software can create much value, designing a system where there is no prototype or existing, defined process in place is highly risky. I find that for brand new systems and/or first generation automation of a system or procedure, the following should be followed:
- Determine Value – Review the expected return for any and all requests and make sure those involved should clearly understand the value and goals of the project.
- Ask Questions – Nearly all of my posts and recommendations involve asking question after question. You can never have too much information and often it isn’t until you get knee deep into questions that the real intricacies of the project are revealed. This is especially true for procedures that are being newly automated or if we have an overwhelming uneasiness about the clarity of the project. In these cases, you should continue asking questions and not fall into the trap of relaying solely on the surface level information provided to you.
- Document and Agree to the Flow: Work with the end users to determine the flow of the system being developed. When automating and developing code to support a process, the cost of change is very costly, so agreement beforehand is always the best approach. Agree to the primary workflow before development begins is the best approach. Using an agile method after the initial workflow concepts will also help ensure future ideas and interaction will be properly defined throughout the project.
- Work with End Users on Developing a Prototype: This can be either a static prototype or a working prototype. Prototypes serve two functions: 1) document and get acceptance on interfaces before getting too far along with the design and 2) encourage the owners of the project and end users to develop the corresponding proper procedures, and documentation. Prototypes are usually iterative processes. You may even have the users build a semi-functional prototype within a tool they have available, to get a feel for what they truly need and how they will use the information.
- Determine Supporting Processes: While the core project generally is the focus, there are numerous ancillary activities that need to be planned and corresponding procedures to be developed. A software system by itself will not tell your users how to interact with it, what other systems that need to update, and the overall business rules, outside of system validation that prompts the user for various fields.
- Determine Supporting Needs: Once the supporting processes are defined, you must document and plan the activities surrounding the system rollout, including documentation, training and selling the respective users on the value of the system.
I often find by discussing things in an open, group setting, users are more apt to critically analyze the solution, requirements, justification and overall need. Start your discussions early and do not discount the importance of group discussion. Successful, organization-changing applications were not created in isolation.
Users too often think that a software system can satisfy all operational challenges. By following the bullets above, you can be better prepared to ask the necessary questions to determine the need, to get everyone thinking in terms of what organizational changes will be needed once the system is built and how the automated process will impact those involved.
Context diagrams can help you, and your customer, understand the full scope of the system and its supporting processes before you get too deep into design. Our detailed guideline can help with thorough requirements gathering procedures so you can be confident you've covered all the ground you can. As you get into prototyping, make sure you carefully document project alternatives and the choices made so you'll remember later what you decided this week, and why.