Paxton Patterson - Admin LCMS


Over the last few years, the education industry has seen a dramatic movement in the area of content standards, testing standards, and technology standards. A number of organizations such as the Institute of Electrical and Electronics Engineers (IEEE), the Instructional Management System (IMS) Global Learning Consortium, and the Aviation Industry CBT Committee (AICC) are actively engaged in creating industry-wide education technology standards. Additionally, Federal and State Governments, and Local School Districts are actively engaged in mandating laws which outline education testing standards for all national, state and district educational institutions. As the education industry moves into the 21st century, so too has the technology infrastructures of the schools evolved. The technical expertise and sophisticated technology environments that were once only available to the private sector are now becoming commonplace in today's schools and learning institutions.

In the past, the EduSystems product line continued to stay ahead of the competition by providing superior educational content and dependable lab equipment. One product offering which initially set the company apart from its competitors was the ECMS or Electronic Classroom Management System. Sophisticated for its time, the Visual Basic application (which runs on the Microsoft Windows operating system) allows instructors the ability to schedule, grade, and manage students and class programs from the instructor's desk. This innovative product allowed Paxton/Patterson to retain a competitive advantage over the competition for several years.

However, over the last three years Paxton/Patterson has experienced increased demand for technology based services. Paxton/Patterson's competition; while still having less sophisticated content has gained market share by supplementing their content and equipment with quantity instead of quality, thereby flooding the market with new technology based features and services. This in effect, has created a features "arms" race between competing training companies. As one company provides new features, such as instant messaging or distributed courseware, another company will follow suit and technically "one up" the competition by adding new features and services of similar functionality. This cycle of "one upping" has resulted in haphazardly developed product lines which rely on mismatched, five year old technologies, and application designs that were not intended to do what the competitor is currently offering. In most cases the competitors' product lines do not appear to have the infrastructure to support the education industry for the long term.


The solution was to develop a learning content management system using open internet-based technologies that would provide the flexibility and sophistication to meet the demands of the client's requirements and feature requests while being robust enough to scale to meet the level of concurrent users forecasted.

The design and development was separated into nine stages:

Stage one
The first stage focused on auditing the existing systems and content. The strategy team reviewed the existing system architecture, data model, and content structure to learn from the short-comings of the current design while providing a point of discussion for gathering requirements for the new system.

Stage two
The second stage focused on identifying the scope and features requested for the system. The team conducted an exhaustive competitive analysis while working with the clients we also collected list of features and requirements from both the client and a select set of customers. Based on the information provided I organized and grouped the requirements into similar subjects and needs.

Stage Three
The third stage focused on designing and documenting the design of the system services, physical architecture, and technology selection. During the stage we prototyped the core of the application infrastructure. The core services of the system were separated into four subjects. Curriculum structure, testing questions, assessment rubrics, and standard definitions. The four subjects needed to be defined and a coordination between the four needed to be devised. In order to accomplish this I had my team analyze the curriculum content structure for all 40 curriculum models for structure. We then researched the testing types that would be the most viable for routine testing and produced several prototype testing routines to verify our assumptions. The standard definition research was more time consuming that initially thought. I spend a month and a half researching federal, state, and district level standards to model a data structure that would be flexible enough to allow all levels of standards to be equally designed and inputted into a system. The last section was assessment, we conducted long discussions on the terminology and nature of assessments and what components quantified an assessment. The result was a flexible assessment setup and management service to define assessment rubrics and measure scales that could be associated to curriculum content, student evaluations, and testing questions. The assessments were then associated to standards definitions to provide a means to infer that students were exposed to concepts and educational material that embodied the spirit of the standard definitions.

Stage four
With lessons learned from the initial prototype; I worked with the client to formalize the feature sets they requested and estimated the length of time that would be required to design and document the requested systems. The management team then worked on defining a rough timeline for the design and development phases required to build the product. We estimated roughly 18 to 24 months to design, build, and test the system for delivery to customers in a 2003-2004 timeframe.

Stage five
This stage focused on content conversion and new content documentation. The training material was developed using Macromedia Authorware and our team was charged with devising a way to integrate the Authorware content into a web-based content management system. The solution was to augment the existing authorware content to send state back to the primary class management services on the webserver. This would provide state of where within the content the end-user is and require the web-server to direct the end client on every page load. The design is very similar to the AICC-SCORM standard with the exception I decided not to use XML to transport state and application data. We decided to instead utilize a series of URL-based variable strings and meta-tag (XML like) tags to send instructions to the end-user client.

Stage six
This stage focused on the design and development of client applications. The first client was developed using a J++ client-server system for presenting authorware content on local end-user computers that connected to web-enabled services hosted by the client management web-server. The second client was a Palm pilot tool for asynchronous assessment of student activities. The system was designed into three parts, the first provided the end client interface on the palm, the second was a conversion interface for synchronizing the palm to the class management server, and the third was the web-based data adapter that consumed and produced XML data streams.

Stage seven
This stage focused on formal system development, we had over 13 developers and management staff working full time on the development of the systems for the LCMS system. The development took over a year and a half to produce the first beta system.

Stage eight
This stage focused on content and service testing, we reviewed the system functions, data integrity, and content structure. Once the first beta of the system was developed we worked with 3rd party experts to enter standards definitions and content timelines, questions, and screens. We then conducted classroom simulation tests to identify bugs and data corruption.

Stage nine
The final stage focused on consolidating the system and developing installation procedures, documentation, and setup development. The last phase was the most rushed of all nine and because of the push to get the product into customer's hands we inevitably had to produce fixes for installation, content structure, and system services.


In the end the final system provided the following services:

  1. Curriculum
  2. Testing
  3. Standard
  4. Assessment
  5. Rubrics
  6. Activities
  7. Grading
  8. Scheduling
  9. Reporting
  10. Journals
  11. Attendance
  12. Chalkboard
  13. Messaging
  14. Locker
  15. Remote Viewer
  16. Class Management
  17. Help
  18. Student Management
  19. Instructor Management
  20. Media Management
  21. Document Management
  22. Tracking Management
  23. Service Management
  24. Registration Management
  25. Data Export
  26. Data Import
  27. Course Browser
  28. Course Router
  29. User Management
  30. Security Management
  31. System Information
  32. System Configuration
  33. Theme Management
  34. Menu Management
  35. PDA Management


Robert's Thoughts

Although this project has very challenging to define and develop because of the shear size and complexity required the most challenging aspect of the project was political, not technical. During the design and development of the system our primary supporter the Technology Director left the company and was replaced by management staff that were less technically inclined. Also the client was very argumentative and because the client's company was a sister company (owned by the same parent company) they had more access to project information and status then what would be appropriate in a client relationship. The strife generated by the client not understanding technology or the development process was compounded with a clear view of the challenges developing a system such as this from scratch entails. The last thing a development team needs is a client jumping up and down screeming about how important a system is while they attempt to build it and work through bugs.

Furthermore, the client was very vocal to constantly push for more features for less or no money, even up to the day of the launch of the product to their customers. The one area of the project that was poorly managed and executed was client management through and through. This problem was evident throughout the development of the system. The client would push and push for more flexibility in the data design and feature sets. They wanted their customers to have the ability to modify everything within the system. Because of this the level of complexity became enormous and in order to track and manage all of the customization and setup features the data structure became very dynamic. Five times over the design and development of various key systems I warned the client that providing the level of flexibility requested undermine stability and ultimately reduce the likelihood of easy updating and bug fixing of key content and system functions.

As a result, when the systems were deployed to over 100 customer locations the client wanted to issue content pack updates and corrections. But because of the nature of the flexibility of the system such a request required a very sophisticated system to provide updates and patches to the content structure. A system which was put off until phase 2 of the system development (slated for a year later). Unfortunately the client was proned to having "selective memory" and attempted to strong arm my employer to build the system for free and in a three month timeline (the system was estimated to take about six to nine months to build). The result of the argument ended our relationship with our sister company for better or worse.

So what did I learn? I learned that from the very begining you must manage your client relationship no matter the political relationship which brought your companies together. Setting clear rules of engagement and ensuring clear boundaries are defined that are consistently reinforced through integrity and honor will ensure a long and fruitful business relationship.

Project Files: 

Project Images: