Episode 24

Matching technology solutions to business problems is no easy task. Custom software development and purchasing off the shelf software are the two most common pathways for solving business problems with technology. With custom development, you get what you want (hopefully), but you pay for the development and future maintenance. With off the shelf software, you get (mostly) what you want, but share the development and maintenance costs through license fees with others that have similar problems. There is an additional variable at play when determining the best pathway for solution development. In this blog, we will explore how adapting processes can help get the most out of a software solution.

To help illustrate the idea, visualize your business problems as a round hole in a wooden chest and the potential software solution as a square peg. Unlike in the material world, the dimensions of the hole and peg change, reflecting the changing client expectations and business needs. When the peg is too large for the opening, the contact points represent solution features that are not needed. Extra features are common with off the shelf solutions that attempt to reach a diverse number of users. If the square peg drops in without issue, the remaining gaps represent the features that are required but not available in the selected solution.

wood block

For instance, digitizing a paper process will likely lead to difficulty in finding a solution with the right fit. If the square peg (solution) is too large, resources will be spent rounding out the peg through configuration, as the solution is larger than the problem requires. Likewise, if the peg (solution) is too small, resources will be spent filling the gaps with custom development. The tighter the fit, the better matched the solution is with the problem. So how do we build flexibility into the system?

System flexibility is gained by adapting processes to work best with the selected solution. Play-doh can be pressed or cut into any shape one desires. Common goals, from a user perspective, of a technology solution are to be robust and frictionless. However, meeting these goals has a price. The more engineering that is required to meet these goals the greater the resource cost, complexity, and learning requirements will be needed to fit the solution to the problem. It is far more effective to change processes upfront before going down the road of solution seeking.

For instance, within a hypothetical organization, job candidates are asked to fill out an application form detailing education, skills, and work history, then upload a resume document at the end. This time-consuming data entry process for candidates leads to top talent reneging, as the archaic hiring process is indicative of a stagnant corporate culture.

Let’s explore some process play-doh options to solve this problem. In this situation the problem is that job candidates are failing to complete the application. It was determined that if applicants could apply via resume upload only, completion rates would increase significantly. However, the data inputted into the existing HR solution is very important to current practices.

One solution would be to purchase off the shelf software to read the text on the applicants resume and perform the data entry. This may solve the problem, but the solution also comes with additional A.I. features for automated rankings, persona profiling, and role matching that are not desired as current hiring managers prefer a hands-on approach to ranking candidates. The additional features represent the extra edges of the square peg. The other solution is a document text reader; however, it lacks the ability to integrate with the current HR database. In order to function optimally, customized APIs need to be developed. This represents a peg that fits, but there are gaps that need to be filled in with custom development.

play doh

Now let’s look at process play-doh. The hiring managers were asked why candidate data was stored in a database, and they explained that this made searching for candidates for roles other than the one posted significantly easier. Every organization will be different but let’s say in this case we learn that the number of roles filled indirectly was less than 10%. In this situation one process change could be to completely remove the data entry step from the application process as direct applicants were likely to have their resumes screened by hand anyway, and losing out on the few indirect hires will likely not have a material impact. A process change removed the need for a peg (solution) entirely, however, we can see from this example that an examination and refactoring of processes can lead to a dramatic shift in solution requirements.

Understanding the exceptions of the organization’s workflows is critical. The 80-20 rule here is also a good guide for determining the importance of requirements. Another element is understanding how much the current solution and process is covering current needs. If the current state covers the majority needs (~80%), then it is best to look at processes first before considering refactoring an existing solution or acquiring a new one. Lastly, if possible adapting a process to the default experience of an off the shelf solution can dramatically reduce configuration and customization needs.