You know the old saying, “Life is a journey, not a destination?” Well designing a piece of custom software is all about the journey, too. Some customers, in trying to be helpful, come to us with detailed design documents that were created before the project started. Although we appreciate the effort, more often than not, it doesn’t help as much as many of our clients think it will. Why? Because the biggest value we bring to the table is our process in working with customers to create these custom software design documents.
It’s an iterative process, in which we travel from high-level information gathering to detailed requirement documentation and back – collaborating with you and your team from the start, asking questions and challenging your answers in order to thoroughly understand your business needs.
So what should you spend your time on to prepare for a custom software design project? Here are some dos and don’ts that will save you time and money and get your software project off to a great start.
Some Dos for Your Custom Software Project
Write a single document with the following items:
- A summary of your company
- What is your industry, size and geographical location?
- Who are your customers, products and services?
- What sets you apart from your competitors?
- Your business challenges and goals
- The users of your new system
- Who will be using the new system (job description)?
- What are their challenges?
- What tasks do you see them performing in the new system?
- Create a high level process flows of:
- Your current process
- Your future state vision
- Create a few screen mockups (a.k.a. “wireframes,” “prototypes”) to help us visualize your application and any reports you may need Providing this summary information allows us to quickly understand your company and its goals, and your employees and their goals. This information informs the rest of the process and reduces the risk of misunderstanding.
Some Don’ts for Your Custom Software Project
Don’t provide anything too detailed, such as:
- Complex process flows
- Detailed requirements
- Entity relationship diagrams (ERDs)
- Class diagrams
- UML diagrams
Paradoxically, providing us with detailed documentation increases the risk of misunderstanding because:
- We don’t hear and digest the information first-hand
- It’s too detailed for the early phases of the design process
- It’s not detailed enough for us to build the software from
- It can be biased as people internal to your organization are oftentimes too close to the problem
Let’s be clear: we highly recommend that you spend time thinking about and preparing for a custom software project. This preparation may take weeks or even months, depending on the complexity of your business. But we advocate focusing your energy in the right place and let the documentation emerge during a collaborative design process.
We hope you find this advice useful. We look forward to collaborating with you on your next custom software development project!