The client is a national provider of utility location services. In some locations, damage still occurs to utility lines even after they have been located, in which case the investigation process begins. The client sends an investigator out to determine the root cause of the damage, whether it was the contractor or whether it was mismarked lines. If the cause is determined to be the locator’s fault, the claim process begins. It may be a simple claim, or it may end up in court, depending on the extent of the damage. Due to the expanding nature of the client’s business, a new system was required to track investigations and claims from start to finish.

Unfortunately, the initial attempt at a rewrite was a textbook case of how not to run a project. The consulting company brought in to do the work used a group of contractors who had little experience with ASP.NET, SQL Server, and the k2 blackpearl workflow software chosen to help manage the process flow. The client asked that the design use ASP.NET web forms and an existing layout, the consultants used a homegrown MVC and a poor attempt at bootstrap design. The subcontractor provided a QA analyst who had no experience in performing quality assurance. Besides that, the “scope” for the project consisted of a diagram outlining the process flow. Anything required to move the process along was deemed to be in scope, but the project was bid as a fixed-price job. The work they performed was untested and of substandard quality.

Solution

The solution, unfortunately, was to scrap the entire solution and start from scratch. During the redevelopment, it turned out that the business requirements for the system had never actually been documented or discussed with the client. The expensive workflow component, which was designed to automate a workflow, sat essentially unused because the business could not clearly define their workflow. Requests for investigation for a particular district might be handled by one investigator today but another one tomorrow. The only people who knew the route were the dispatchers, but there was no pattern they could agree to, whether it was a group of investigators for a particular district, a round-robin assignment, or any other scheme supported by the workflow software. As a result, the solution was to build a “companion” workflow system that allowed the users to manually choose who should receive the work package next. The software that was built would then inform the workflow software what to do, which essentially turned the workflow software into a recordkeeping system and nothing more.

The replacement solution was built using ASP.NET Web Forms, SQL Server 2008, and an existing style/layout provided by the client. The original solution provided by the consulting company, which represented only about 40 screens, consisted of over 2200 files. The replacement solution cut this software base down to only a few hundred files. The end result was a software solution that the client could then maintain themselves instead of a pie-in-the-sky design that was completely unsupported in the industry. The final product also had very easy ways to “detach” from the workflow software if the client decided that their work processes were not going to change enough to make full use of the workflow software.

This project ran from December 2012 - February 2014 as part of my full-time employment with a local consulting company.

Tools and Technologies

• Visual Studio 2013
• ASP.NET Web Forms
• C#
• k2 blackpearl