When you are starting a custom software project, it is critical that you get buy-in from key people within your organization. To get that buy-in (and to have a successful project), you will need to gather input from your team. You will want their input about what area of the company can most benefit from the new tool and what specifically should be done within that area. You will then need to prioritize that input and decide what to tackle first. This post will suggest some best practices for doing these things.
Be Open and Responsive to Input
When you ask for your team’s input on what the scope of the project should include, it is important that you are truly open to their thoughts. Do not reject any ideas, at least initially. The best ideas could come from the most junior employee.
Being dismissive of an employee’s idea can cause other employees to clam up. Remember, your employees are likely more “in the weeds” than you are. They might have key insights you haven’t thought of. Their ideas could make the software project and your company more successful. (Want a helpful tool for getting your team’s input on your development project? Download our “Custom Software Planning Survey” PDF / Word / Google Form.)
Of course, not every idea your team suggests will be good or within budget. Still, capture it and thank the employee for their contribution. Consider holding an ideation workshop to rapidly collect input. During the workshop, you can simply collect ideas on sticky notes. Alternatively, you can collect input using a simple survey tool such as a Google Form.
Perhaps a suggestion is good but isn’t enough of a business priority to make it into the initial phase of the project. That’s fine. You can save it for a later iteration of the software.
Deciding on the Initial Scope
You will need to decide on the initial scope of your custom software project. You should not try to address every challenge and opportunity in your company– at least not at the same time. Custom business tools work best when they are created using an iterative process. A small early version is more likely to succeed and keeps costs under control. It also minimizes organizational disruption. Most importantly, it allows you to capitalize on lessons learned along the way.
Once your team learns that you are starting a development project, various department leaders might advocate for why their department needs a new custom workflow. And they might all be right. But, again, you can’t solve all the organization’s challenges at once.
So, be open to input about where the project should begin and what parts of your organization could use custom software. But after you’ve gathered input, create the business case for what area will be in the initial scope of the project. Then clearly communicate the what and why of that decision to your team.
Deciding What Specific Tasks the Initial Scope Should Include
So, you’ve gathered input from all your stakeholders and have decided what area of the company the project will tackle first. The next step is to identify your priorities within that initial scope. Remember that this is an iterative process and you’ll have opportunities for “nice to haves” over time. In fact, you’ll learn with each rollout and can apply that knowledge to the next phase.
Start with the features that will deliver the quickest, biggest return. Here are some questions to discuss with your team:
A. “Where can we get some quick wins?”
These are features that people will readily adopt (because it makes their jobs easier) and will deliver a good ROI. Focus your energy on improving functionality rather than trying to change everything at once. Choose to fix the processes that waste time and cause you to miss opportunities.
B. “Which processes are already working well?”
If a process is working well, you may decide to leave it alone. This saves money and avoids unnecessary business disruptions. Instead, consider integrations that could maintain “business as usual” while still meeting your other objectives.
C. “Which processes are completely broken?”
You’ll discover some processes that no longer make sense. Maybe it has been done the same way for 20 years. Or maybe the person who designed the process left years ago, and employees have been creating workarounds ever since. There’s no point in creating automation for a broken process. Instead, meet with the people who perform that process and create a workflow that makes sense.
Be Sure to Observe How the Work is Really Done
Busy employees tend to find workarounds for inefficient processes. The real workflow could be very different from the official documented process (if there is one). It is essential to learn how employees complete tasks. It is also critical that you understand why they do them that way. If you don’t understand what processes your employees are actually using and why, you may end up automating a process that they stopped using years ago.
Start Collecting Feedback Now!
Figuring out what to include in your custom software project does not need to be hard. The truth is that your team probably ALREADY has some great ideas that can propel your company forward. You simply need to gather those great ideas and decide which ones to act on first.
Ready to get your team’s input on your new business tool? Great! Download our “Custom Software Planning Survey.”
