Project - Software Development - Residential Product Configurator
Following the successful launch of the Commercial Configurator in the world-wide marketplace, the company decided to enter the residential door market and needed another Configurator to help customers engineer garage door solutions for end-customers, and maintain and replenish inventory.I had already established a rapid, easy to use, and well-tuned development and communications environment, which was to be used for this development. Executive Management assigned another project manager to this development while I was assigned to other duties. I was asked to intervene when it was noticed that the project was behind schedule and that the team could not combine the modules or database elements together. In my review I noted:
- The team thought it would be best for the company to provide an Internet based (web based) Engineering Product Configurator and ordering system as this would reduce costs associated with software distribution.
- But the customers often visited remote locations lacking Internet availability.
- The team assumed the customers could delay quoting until they returned to the office or that they would purchase Internet sticks for their sales staff to communicate with.
- But the customers did not want to extend their quoting times or raise the overall cost to quote - rejecting the presented prototype.
- It became obvious that the program should have been developed as an application, but the Project Leader was unaware that the chosen web-based model could not be simply ported to an application, leaving the team unsure as to how to solve this problem.
- The development team had decided they would only meet when it was time to integrate their modules together - no development meetings had been scheduled.
- The team had met to discuss overall functionality of the application, but had not translated this into a detailed and described model.
- The team had individually established and detailed the program's internal architecture, but had not met as a group to combine them.
- Each team member had been meeting with Engineering individually.
- But the products were still under development and the specifications were under constant revision.
- The engineering department was not providing change notices.
- Thus, each team member had been provided different specifications and product options, making it impossible to combine them in code.
- The team had not continued to use the established standards, such as: names of global variables, how to implement item selection and item tracking systems, coloring, wording, screen placements, database design, and GUI interface styles.
- The team had difficulties combining the screens together, and could not agree on the use of a single interface style. Both had used custom coded navigation methods rather than simple hyper-links or buttons.
- Engineering was not properly or fully testing the application as it was difficult and time consuming for them to test using the provided interfaces
- developing a new USE Case, securing approvals, and establishing regular development and engineering meetings
- altering the deployment of the web-based Configurator for deployment on client computers
- time constraints limited my ability to change the application from being web-based to a stand-alone windows application
- I opted to use an email transport to export orders (bypassing firewalls, etc.)
- introducing a custom anti-piracy protection system
- the product lacked any anti-piracy protection and it was noticed that the industry lacked offerings
- I approached the anti-piracy security provider we used for the Commercial Configurator and asked them to modify their solution for use in a web-based application
- their final product even used the same interfaces, allowing us the ability to track customer deployments and set pricing models in the same way as the commercial Configurator
- ensuring applicable standards were agreed upon and used throughout the application
- leveling the product and engineering details between the developers and the engineering team
- streamlining procedures used to test engineering routines
- creating new deployment procedures, as customers needed to deploy the application on Microsoft IIS servers but would be accessing the website only on that computer or across their local network
- was the first multi-user interface provided by the company - all of the other Configurators were single user only (but provided import / export features)
- generated priced engineered solutions that met end-customer expectations
- had a quotation module
- enabled customers to maintain their inventory
- provided an ability to place orders that could include items on Quotes and Bills of Materials
- order fulfillment was handled via a unique email system - when an order was placed by the customer:
- the software generated an email which was sent to an incoming email box
- an order processor application was created that processed these emails into a database
- the customer service team could use the order processor program to select an order, review it on screen, make any adjustments necessary, and then submit them into the ERP
- provided an ability to schedule installations
- used the same anti-piracy application as had been used for the commercial Configurator, making it easy for us to track deployments and unlock advanced or custom features