Looking at web technology it is easy to feel that great business value and user productivity can be gained from creating deep, complex integrations presented through elegant user interfaces. This could be the truth, but it is often far from it.
As I have written many times on Infotechaligned – the only thing that matters is the ultimate business value that an application is delivering. The most value can be gained from even the most mundane technical solution.
How does one define a great technical solution? The best technical solutions solve a business problem with the least amount of technical effort. This includes effort from a full lifecycle standpoint – design, development, implementation, education, operation, maintenance and decommissioning of the solution. A few years ago I worked with a company that demonstrated this point so clearly that I had to highlight it in this post.
This particular organization lends money to low income families at below market rates to aid them in home purchases. For a few years they had been using portal technology that from a development standpoint was focused on business users. This technology required little programming to allow them to further develop their extranet and intranet environments that connected their customers on the lending and purchasing sides of their business.
A need arose within the organization to provide executives with a summary of call activity from their sales team to judge the effectiveness of various calling campaigns.
The IT team spent time deliberating over what course of action to take to solve the business problem. It was decided that the executives could be best served via a dashboard that would roll up various pieces of performance data around these calls made by the sales team and surface the information via their existing intranet.
The following two options were arrived at assuming that the requirements gathering for the solution was already complete, irrespective of the technical solution
Extend their base CRM system to support tracking this data and develop an integration to aggregate and present the data. This solution would require the following development efforts
- Extend the data model of the base system to account for the new reporting needs
- Develop a presentation layer to gather the relevant information for the business users based on this data model
- Create a presentation layer to allow executives to view and sort the information
- Integrate the presentation layer into their intranet
- Complete a quality assurance cycle on the solution and resolve any issues found with the technological implementation
Use an out of the box – MS Access like – portal component that is already available to capture and present the information. This solution would require the following development effort
- Configure the data model and forms relevant for the data collection around the business needs
- Configure the presentation layer for the end users to expose the required reports
The above comparison might be deemed biased, but it is important to note that in the 2nd solution data would now be entered into two distinct systems by the sales team and the organization will not have complete control over the presentation format beyond a series of basic, caned reports.
After lengthy deliberation the IT team was strongly in favor of using the first solution due to it giving them full control and confining all sales team activity to the CRM system, but estimated the time to completion at around four months of effort. This effort would detract from having their developers work on core offerings within their extranet to drive business leads to the sales team. The development and QA time, not to mention possible adjustments that may be needed after an upgrade of the underlying system also added to the overall “cost” of the integration.
The first solution would require around 8 hours of effort to configure and 10 minutes from the sales team each week to summarize their call activity, which would be required regardless of the technical solution selected. It would be created on top of an out-of-the-box technology and require almost no quality assurance testing, but require the sales team to end their day outside of their CRM system and leverage the intranet for summation of their calls.
In a perfect world we would have the deep integration of the first solution, married with the ease of development within the second solution. Unfortunately that was not feasible and the business team was requesting a solution as soon as possible from IT.
Ultimately the IT team went with the second option. If more complex needs arose that the configuration based solution could not meet they would have to revisit the solution, but for now they were able to meet 100% of the business needs with this stop-gap effort in a very short time span. Given the limited effort and accuracy in addressing the problem, this had tremendous positive impact with the business.
This example of success is perhaps one of the most powerful, pragmatic solutions that I have come across in my enterprise software work. This is an extreme example, but hopefully there might be a space within your organization that allows you to provide this same level of success with minimal effort. Using simple, configuration-based approaches to development whenever possible is an outstanding way to provide value. They may at first seem too lightweight and due to their technical ease may be overlooked at first pass by a development staff, but never count them out for their ability to provide a big win for your business teams.