Due to opportunities identified via external audit, my organization was looking to implement technology that would allow creation of classes, capturing enrollment as per the facilitators input and allow for post-class acknowledgement by the participants for an employee group without access to the organization’s internal learning management system (LMS). This is the largest group within the company, at roughly 160,000 employees needing access to the platform, and these employees historically have little to do with administrative technology in their current role so would need step-by-step direction and knowledgeable managers to support this transition.

A team was assembled to lead the project, comprised of university department management and the Business Transformation Institute (BTI) department who handles change management for the organization. The technology was piloted within seven different locations, both in the US and Canada, and was generally well received. These locations were given ‘white glove’ treatment, meaning they had specific subject matter experts (SMEs) assigned to their location to offer support through out the process. These SMEs provided Zoom training calls to all involved with the pilot, created job-aids based on their expertise with the tech, and further updated the job aids based on lessons learned and feedback from the pilot locations. Powerpoints with timelines and metrics to measure success were rolled out by the SMEs to set expectations early and were shared with the stakeholders (field management who were involved with the pilot).

The Project Management team called it a success, and then rolled out the platform across the entire network. The platform jumped from seven locations carefully supported and monitored by their designated SMEs to over 1000 locations with no onsite support. Instead of curated zoom calls scheduled around the pilot location’s availability explaining the why and when and how of the change, the network was offered a finite amount of zoom calls with no overview of attendance or communicated consequences should they be missed. Needless to say, the network roll out was not the success that was seen with the pilot. Locations were missing steps on job aids which caused technical issues with adding participants to classes, as well as closing classes; to work around this, field staff were just creating new classes instead of fixing the original issue. The large increase of classes to the platform created a significant lag to the system which caused the users to lose time and patience with the system in general. Once the buy-in from the organization suffered, it was significantly more challenging to get the network in line and compliant with the program and it created extra work for the university team who were now acting retroactively instead of proactively with the field staff.

I believe the project management team did a great job initially with the project itself – they identified the correct stakeholders, create a unique item to launch, and piloted the platform to success. Where I feel the failure occurred was in the operations as it seems that the team overseeing the implementation of the product met the requirements for project completion but there was no plan for ongoing operations. As noted by Watt (2014, p. 12), there are specific attributes that identify a project:

  • Projects are unique.
  • Projects are temporary in nature and have a definite beginning and ending date.
  • Projects are completed when the project goals are achieved or it’s determined the project is no longer viable.

Once the pilot was completed and deemed successful, there should have been a shift to operations and the ongoing, sustainability of the technology implementation. While it might seem that to perpetuate the success of the pilot it’s a simple duplication of the original process, in this case that wasn’t an option – no ‘white glove’ service due to resource availability – there should have been adjustments made to acknowledge and account for the differences. It seems a lot of work and planning went into the pilot but the same could not be said for the following network roll out.  Conway et al noted that “creating the successful product or service will require trying, failing, making changes and then trying again, often multiple times” (p. 24) which seems to have been missed in this roll out since there was no anticipation of any type of failure once the pilot succeeded. There was instead an assumption that even without a true duplication of effort and attention to the technology there would be a duplication of success.

If the company had instead treated the pilot as the project and post-pilot as operations and assigned separate teams to both, I believe many of the ensuing issues could have been anticipated, planned for, and possibly avoided all together.

References

Conway, R., Masters, J., & Thorold, J. (2017). From design thinking to systems change. How to invest in innovation for social impact. RSA Action and Research Centre. https://www.thersa.org/globalassets/pdfs/reports/rsa_from-design-thinking-to-system-change-report.pdf

Watt, A. (2014). Project management. BCcampus Open Education Pressbooks. https://dc.arcabc.ca/islandora/object/dc%3A51330/datastream/PDF/view