Making it Happen- from Idea to Implementation and Beyond

Making it Happen- from Idea to Implementation and Beyond

David A. Melton
Plexis Group, LLC
8136 Castleton Rd, Indianapolis, IN 46250 U.S.A.

Abstract
In the early stages of developing our Internet-based GIS-enabled road maintenance management application, the specific needs of one user drove our development process. As the project evolved from a client-specific solution to become “eroads”, an application targeted for a wider audience, our design methodology had to shift as well; it became necessary to infer the potential needs of the broader user community from the specific needs of the user for whom the application was initially developed. This inferential, inductive approach can be effective if it is informed by a clear understanding of the data, workflows, and functional needs of the users at all stages of the project. However, this understanding can also lead to the formation of clientspecific biases that may adversely affect product development. As developers attempt to refine the functionality of the product within the new development paradigm, “scope creep” may also occur. Members of the development team should be aware of these potential hazards at all stages of the project. Early recognition of these detrimental influences is essential for timely mitigation. With vigilance, their impact on the project can be minimized.

Project History
White County, Indiana has been one of Plexis Group’s GIS clients for many years. Several years ago, the county decided to migrate their in-house Genamap GIS to an Internet solution hosted and maintained by Plexis Group. In August of 2000, we met with the county highway department to discuss replacing their existing road maintenance tracking software with an application that could be used in conjunction with the county’s new Internet GIS. The county highway department had been using an application called “Roads” to track their road maintenance activities. This application was developed and distributed by the Highway Extension Research Project for Indiana Counties and Cities (HERPICC) at the Purdue University School of Civil Engineering. Now informally called the Indiana Local Technology Assistance Program (LTAP), this program provides technical assistance and training to highway, road, and street departments in Indiana. The latest version of this software was distributed in 1997. Since then, LTAP has discontinued support of the program.

White County was generally satisfied with Roads, but they identified several areas where the application did not meet their needs. The Roads application is built on a DOS-based FoxPro database. Because of the structure of the database, the Roads application did not let the user summarize data for more than one month at a time. For their year-end reports, our client had to create twelve monthly reports and add the totals manually. Our client also needed a better way to estimate the cost of materials in their inventory, especially the gravel and sand in their stockpiles. White County asked us to develop an application that corrected these deficiencies while duplicating the essential functionality of their existing maintenance management system. White County also wanted to link their road maintenance information to the GIS, capitalizing on the spatial nature of their data for future analysis.

Having identified our client’s needs, we began working on a solution in February of 2001. Our first step was to perform a complete functional review of the Roads application, to define the basic functionality we had to duplicate. We also evaluated CarteGraph’s PAVEMENTview and Government Finance Consultants’ CHARTS software, similar solutions from which we hoped to gather ideas for our application. We are fortunate to have a former highway supervisor as a member of our development team. His input was extremely helpful at this stage, as we evaluated which features of these other applications should be included in our own.

To construct a prototype application, we began by importing the road sections, materials, activities, equipment, and employee data tables from Roads into an Access database. Next, we created a data structure for storing work records, linking to the supporting tables whenever possible. We then established the relationships among the tables that would enable us to replicate the functionality of the Roads application. This database prototype was migrated to SQL server, and a Cold Fusion application was developed for data entry, reporting, and modification of the supporting tables. In addition to creating reports similar to those available in Roads, we developed several additional reports suggested by our former highway supervisor.

In response to our client’s request, we also developed a module for tracking material inventory, purchases, and stockpiles. Previously, our client estimated the costs of these materials. The county had no way to determine how much material from each supplier might be in a given stockpile, so they used the mean price from all their suppliers, assuming that the amount of material from each supplier was approximately equal. If this assumption were not correct, or if the prices from two suppliers differed slightly, the county’s estimated cost for the material in that tockpile could be quite inaccurate. Our module avoids this problem by calculating the weighted average cost of materials in the inventory, based on the bid price and amount of material purchased or placed in the stockpiles. This weighted average cost is applied to materials as they are used for maintenance activities. We also created reports showing a historical log of materials purchased and a summary of materials in the current inventory. These reports can also be used to show the unused balance on annual contracts for specific materials. This additional feature was not intended in the original design of the module, but it was discovered during testing.

The prototype application was demonstrated to our client in April of 2001. Based on the results of this demonstration, we modified the user interface so that the entire data entry form would be visible without having to scroll the display. We also reformatted several of the reports to calculate subtotals and totals where appropriate. In August of 2001, we demonstrated our application to the LTAP staff. They provided useful feedback, suggesting minor changes that would make the application more appropriate for city street departments as well as county highway departments. During this period, we also modified the labor cost calculations to automatically assign the appropriate pay rates, instead of requiring the user to pick a pay rate for each activity.

In October of 2001, we prepared our client’s employee and equipment data for final delivery. We also redefined their road sections, activities, and materials tables to correct inaccuracies and omissions. During an on-site product evaluation using the White County Highway Department’s hardware and wireless Internet connection, we discovered that the speed of our application was prohibitively slow. The users also complained that the proposed interface was inconvenient and that our proposed data entry workflow was inefficient. A complete redesign of the user interface was necessary to correct these deficiencies. Our client also requested that we use the sick time and vacation time entries in the work records to calculate the remaining sick time and vacation time balances for each employee. These changes were made, and version 1 of the application was delivered for the client’s use starting in January 2002.

Before we finished with version 1, we had already begun planning for version 2 and beyond. Future versions may include a more robust interface with our Internet GIS application, and modules for equipment maintenance, parts inventory, budget forecasting, and maintenance of bridges, culverts, and signs.

Development Methodology
Some time in the middle of our development process, the decision was made to develop White County’s road maintenance management application more fully in hope that it could be marketed to other clients, under the name “eroads”. In the beginning of the project, we focused on White County’s specific needs. As our emphasis shifted from a single client to the broader user community, our development team had to shift our thinking from the specific back to the general in order to make sure that eroads would be appropriate for a wide variety of users. Our approach was still need-based, but now the design team would ask “is this need specific to White County, or is it shared by the larger user community?”

Our need-based approach lets the functional requirements of the users guide the design at all stages, by focusing on processes: how are the data gathered, input, stored, retrieved, manipulated, and output to meet the needs of the users? If the relationships among these processes are clearly understood by the development team, the resulting application will seem organic to existing workflows. This approach works extremely well for specific solutions, but several challenges are faced when applying this method to the development of a product that will appeal to a wide audience. Not all users will have the same functional needs; the processes that evolve to meet those needs may differ; and the results desired from those processes will vary. Given these differences, our design team had to pay careful attention to needs that could be identified as common to the majority of prospective users. Once again, having an experienced highway supervisor on our team proved to be an invaluable asset as we strove to identify these essential elements.

Client-Specific Biases
Because our design methodology shifted in mid-project, we had to deal with the legacy of our early deductive approach throughout the rest of the development process. This challenge gave us an opportunity to evaluate how our early assumptions affected later stages of the process. We found that most of the problems we encountered as we tried to generalize eroads for wider distribution could be traced to a circumstance specific to White County. These client-specific biases influenced early design choices that became inappropriate when our project focus shifted to a wider audience. An example will illustrate the peril of letting client-specific biases persist through the development process.

In our prototype application, we defined two related tables to contain employee data. The first table contained the employee’s ID number, name, hire date, sick time balance, and vacation time balance. The second table contained each employee’s regular and overtime pay rates. The records in the second table were related to the first table using the employee’s ID number. The tables were initially structured this way so that during data entry, our client could select the appropriate pay rate from a drop-down list on the user interface.

When our development focus shifted to a wider audience, we decided that eroads should calculate the appropriate pay rate for each activity based on the type of work being performed, the employee’s length of employment (longevity), and the total hours worked by an employee in each week. In most highway departments, each work category is assigned a corresponding base pay rate. For example, a truck driver’s base pay might be $12 per hour, while an equipment operator’s base rate may be $17, and a laborer’s base rate may only be $10. Employees tend to perform one type of work most of the time, so each is assigned a default work category. If an employee works more than half a day in a category with a higher base rate, the employee is customarily paid the higher rate for the entire day. Hourly longevity rates are commonly added to these base rates as well. The employee’s regular pay rate is determined by adding the base rate for their work category to their longevity rate. The employee’s overtime rate is 1.5 times their regular pay rate. We decided that eroads should calculate these rates “on the fly” and apply the overtime rate to any hours worked in excess of 40 per week. In complying with this decision, our programmer had to restructure several of our data tables, re-code how pay rates are assigned, and modify the form that allows users to enter and edit employee information.

Our prototype offered a limited solution to a specific need, within specific constraints; we gave our client a way to pick a known value from a limited list of possible values. In our prototype, if all the equipment operators were given a $1.00 raise, the user would have to scroll through the list of employees and change the base rate and overtime rate for each employee who regularly worked as an equipment operator. Our revisions greatly simplified this process. Now the only change that is required to give all the equipment operators a $1.00 raise is to edit the default base rate associated with the “operator” work category. If we had addressed the broader underlying functional need, instead of focusing on the specific need of one user, we would have avoided the costs and delays associated with the redesign. Eliminating this client-specific bias resulted in a more elegant solution, which will be more appropriate to a broader user community.

Coping with the unforeseen consequences of our previous, deductive approach gave us an appreciation for the soundness of the needs-based method. Each time we let our design process be guided by anything other than the functional needs of the users, we encountered problems. In reviewing an early version of our user interface, we discovered one such deviation. Instead of letting the users’ workflows dictate the most appropriate layout for the user interface, we based the layout on our data structure. We store the daily work data in several tables, related through the employee’s ID number and the date the work is performed. The first version of our user interface was developed around this data structure, so it consisted of several distinct sub-forms with a “submit” button in each one. In the first sub-form, we required the user to pick an employee, work category, and date, and enter the total hours worked. The user was then presented with a three more sub-forms for entering work performed, equipment used, and/or materials delivered. This user interface and the workflow it dictated were slow and inconvenient. Each time one of the “submit” buttons was clicked, the data were written to the table associated with that section of the form, then the entire web page had to be refreshed. When we demonstrated the application over the client’s wireless Internet connection we discovered that each reloading of the web page took between 12 and 30 seconds. At this rate, entering one employee’s daily work could take up to five minutes as the user waited for the web page to reload multiple times. When we redesigned the user interface to conform to the data entry workflow instead of basing it on our data structure, the time required to enter one employee’s daily work was reduced from five minutes to less than one minute. All daily work information for an employee is now entered on a single form, with one line for each activity, showing the work location, the equipment used in that activity, and the materials delivered. After all the information is entered correctly, the user clicks one “submit” button. The data are still stored in several tables, but now the application breaks down the information in the form and sends the data to the proper tables. The same data entry form is used to edit existing records in the database. The data are queried back into the form, edited, and then re-saved in the appropriate tables. Figure 1 illustrates both versions of the user interface. The version on the left was dictated by the data structure, the redesigned version on the right works in synergy with the data entry workflow.

Figure 1.
In another example of bias affecting our application design, we let our own opinion take precedence over the users’ functional needs. We also let our own programming constraints dictate functionality and user workflows rather than searching for a creative way to overcome our limitations. When we developed the prototype user interface for data entry, we thought it would be a good idea to include drop-down lists for most of the fields. We reasoned that most users would prefer drop-down lists with text descriptions like “snow removal” or “unleaded fuel” rather than numeric codes. One of White County’s initial complaints was that they had to refer to a printed list of codes when they couldn’t remember the number for a seldom-used activity or material. These drop-down lists caused more problems than they solved, greatly increasing the time it took for the web page to reload after the user clicked one of the “submit” buttons. Each time Cold Fusion repackaged the data and user interface to send them in HTML format, each of the drop-down lists had to be rebuilt from the database. Additionally, Cold Fusion would not allow a user to enter text in a field if a drop-down list was created for that field. The user had to scroll through the list to find the item they wanted, and then click on it. We rectified these deficiencies as part of the redesign described above, and as illustrated in Figure 1. Instead of providing a drop-down list for each field, we made each column heading in the new user interface into a link that opens a separate pop-up browser window. This window contains a scrollable list of the possible values for that field. When the user picks one of the items in the list, the pop-up window closes, and the corresponding numeric code is inserted in the data entry form at the current cursor position. If the user already knows the numeric code, it can be entered directly on the form as well. These changes not only allow users to enter data much more efficiently, the changes also greatly reduce the time required for the page to reload after data are submitted. We initially thought that drop-down lists would make data entry more intuitive and user-friendly. In making this decision, we let our own opinions and programming constraints dictate functionality. This decision imposed arbitrary restrictions on the users, attempting to make them conform rather than creatively finding a solution that addressed their functional needs.

Scope Creep
In pursuing an inductive approach to application design, it is easy to fall prey to scope creep. In order to define the scope of the project, the development team must first discover the expectations of the clients, a wish list of everything the users want the application to do. Budgetary and scheduling limitations usually preclude the development of all the desired functionality, so the client’s expectations should be grouped into three categories, things that must be done, things that should be done, and things that could be done if time and budget permit. Careful negotiation with the client should ensure that not all the expectations end up in the "must do" category. Ideally, the three lists of expectations should be about equal in size. Several problems may occur during the negotiation process. The client may not be able to effectively or completely define their expectations. The client’s expectations may also appear to be contradictory. Both may indicate a lack of understanding on the part of the client. This lack of understanding could cause problems later in development, as the client gains a clearer understanding of what is possible. This understanding may lead to the discovery of new expectations, or the discovery that the client’s initial expectations are no longer relevant. Both discoveries could have a detrimental effect on the project. Collaboration between the client and the development team is crucial. If users are involved at all stages of system development, it will be more likely that they will accept the results.

From the three categorized lists of expectations, the development team will determine the essential requirements for the application. It is not always necessary to implement all the requirements in the first release of the application. A more reasonable development strategy is to satisfy the “must do” expectations and a reasonable number of the items in the “should do” list. Deciding which of the “should do” expectations to include in the initial release requires application of the “80/20” rule. The development team should focus their efforts on the 20 percent of the “should do” list that will provide 80 percent of the value. The remainder of the items in the “should do” list, along with the list of “could do” expectations will form a basis for future versions of the application.

During the development of eroads, we allowed a significant amount of scope creep. Our client’s initial expectations were such that they were met relatively easily. White County’s primary complaint with LTAP’s Roads software was its inability to generate reports for more than one month at a time. They also wanted to be able to integrate their maintenance data with the county’s GIS. As long as we provided a solution that met these expectations while duplicating the essential functionality of their existing maintenance management system, any additional functionality we could provide would be “icing on the cake”.

Our most common source of scope creep was the former highway supervisor on our development team. His years of experience led him to suggest many additional functions beyond White County’s immediate needs. His input was beneficial because it helped us see beyond the needs of one client. This helped to make eroads more appropriate for the wider user community, but it left our development team with the difficult task of deciding which functions were worthy of inclusion in the initial release of eroads, and which should wait for future versions.

Several of our former highway supervisor’s suggestions were implemented in the first version of eroads. He was the first to suggest that entering sick and vacation time in the daily work records should automatically deduct that time from the balances in the employee’s record. He also proposed that each material should have a default cost associated with it. This default cost automatically appears in the data entry form when new purchases are recorded, unless the user overrides the cost. We also added a field to the road sections table to identify the county commissioner district for each road, allowing maintenance data to be summarized at this level for reporting to the commissioners. Initially, we defined a limited number of reports, showing material inventories, daily work summaries for employees, and the maintenance activities and materials delivered for a particular road section on a given date or over a specified date range. To this initial list, our former supervisor suggested that we add summary reports for material use, maintenance activities, and equipment use. Rather than being tied to a specific activity, location, employee, or date, these reports let the user analyze and summarize large subsets of the data to discover general trends, an assist in budgeting or maintenance forecasting.

Our other team members suggested revisions as well. Our programmer suggested that we include filters on the user interface for maintaining the supporting data tables, so that the users could perform maintenance on a subset of the data without having to scroll through the entire table. One of our project managers was instrumental in convincing the rest of the development team that eroads should automatically calculate the appropriate pay rate to assign to a work activity. Our GIS consultant suggested which reports would be most beneficial to link with GIS data. He also suggested that the material reports should group similar materials together, and calculate subtotals for quantities and costs.

Not all the ideas suggested were included in the first release of eroads. We decided that a future module would be developed to manage equipment maintenance records. In the first version of eroads, users can assign labor costs and equipment costs to road maintenance activities, but there is no way to assign a cost for the equipment used in these activities. The equipment maintenance module will include parts inventory, maintenance scheduling, and hourly operational cost calculations. Future modules will also be developed for managing bridge, culvert, and sign maintenance and inventory.

New ideas such as these are part of the development process. A limited amount of scope creep may be beneficial. The value of a proposed change should be carefully evaluated before changes to the project’s scope are allowed. More is not always better; sometimes it’s just more. The key to mitigating the negative effects of scope creep is to remember that change is inevitable as members of the team develop and implement solutions to the client’s needs.

What we Learned
An inferential, inductive approach to application development can be effective if it is informed by a clear understanding of the data, workflows, and functional needs of the users. In generalizing an application developed to meet a specific user’s functional needs, the design team must infer the needs common to the majority of prospective users. Careful attention to the interrelation of data collection, input, storage, retrieval, manipulation, and output processes will result in an application that is in harmony with existing workflows. Ignoring the inter-relation of these processes will impose arbitrary restrictions on the users as they try to conform to inefficient workflows in order to compensate for an inappropriate database structure or other programming constraints. Shifting project scope from a single user to a broader audience can offer a chance to study how early assumptions affect the outcome of the project. Client-specific biases may dictate early design choices that are inappropriate for the larger user community. Collaboration between the client and the development team is important at all stages of the development process, but it is crucial in the initial stages, as the client’s expectations are being discovered and refined. Eliminating client-specific biases and reducing the negative effects of scope creep will result in a more elegant solution, which will appeal to a broader user community.