My predeterminations were far from reality and taught me to never discount the full scope of technology conversions.
My task seemed straightforward: Lead my team in replacing an outdated learning request system using new technology. On the surface, it appeared transitioning systems would be easy, and that's how I approached it.
But the reality was that it wasn't a short conversion from one database to a new platform. Instead, it was a major development project that included adding functionality and complexity, reporting, and data elements. The project I anticipated taking a few weeks ended up taking more than six months. From that experience, I learned to never underestimate a conversion project and assume it will be simple.
Making the switch
The company was moving all request systems to the new platform. That meant my talent development team's learning request system was also moving.
The current system followed a demand-driven approach—employees submitted learning requests for development projects as their needs arose. They could request new learning development, revisions or maintenance, or general support.
After we received a request, we would reach out to the requestor and conduct an intake meeting and front-end needs analysis to validate the request. That initial contact was generally within 72 hours of the individual submitting the request.
The new system was an out-of-the-box solution, and my team wasn't the first in the company to transition to it. That led me to believe the switch would be an easy conversion.
I couldn't have been more wrong, and I should have approached the change as if my team and I were building a new solution. My initial thought was to convert the existing intake process, using the same questions and fields from the originating system, into the new one. That would be quick and done with.
However, as my team and I progressed into the development and learned about the new software, we discovered that it offered many functions we didn't have with the older system. For example, the new system could automatically pull in information from the active directory, saving time for both the requestor and my team. The system also uses an automated email workflow to alert the manager of new requests.
Given those new insights and abilities, my team and I decided it was worthwhile to expand and grow the project. We added considerable functionality to the system.
But that came at the cost of extending our development timeframe. I significantly underestimated how much time we would need to identify our needs and complete the programming.
We also faced learning the new technology and processes; managing the change; and collaborating with requestors and the business. We ultimately were forced to launch without sufficient documentation and training for our end users.
Because it was a replacement, we didn't have as many shortcomings as could be expected. But we did lack training and documentation at launch; still, end users and instructional designers were able to overcome that. The team learned on the go as we started receiving learning requests and processing them.
Lessons gained
My team and I learned practical lessons related to the specifics of changing systems. For example, I now know that a solid design is always required when developing a new system. The better I outline the design, the faster and more accurate the system build will be.
I also found that a strong partnership between the learning team, end users, and the development team is important to ensure all voices are heard and design considerations understood.
Multiple touch points between all users and the talent development team was necessary to succeed in the system build and launch. We continue those touch points now as we expand our knowledge of the system's abilities and improve its functions.
However, I also learned personal lessons as a leader through all of this. I cannot assume that I know what a project will entail with only surface-level details. I need to ensure I've asked questions and gathered the full scope of a project. That includes uncovering the abilities and limitations of both the system and the team developing it at the onset to avoid misunderstanding system capabilities at launch.
While the new platform offered me and my team the ability to modify and customize aspects of the system, there were limitations. That required us to adjust the workflows and processes to best use the system.
As the leader of this project, I learned to seek input from everyone on the team. Having everyone comment on both the system and process was an important lesson.
I started on this project myself along with a programmer, but I should have embraced bringing my entire team into the work from day one. That would have not only helped me identify scope issues but also enabled me to delegate certain aspects of the project to the team closest to the work.
Because as an organization and team we believe in agility and continuous improvement, I thought the approach of incremental design and development would give us the flexibility to develop on the fly.
For projects other than technology, that approach may be suitable, but I should have been more aware the ramifications given the type of project we were attempting. Going forward, I intend to start every project regardless of size, scope, or content with full team input from the beginning.
Future aims
The process of getting to the system launch had many shifts, changes, and struggles. But the new learning request system has proven successful. We now have a one-stop system for the entire company to request needed learning-related services.
For future projects, I will first fully understand the scope and then I will slow the development process. Because my team and I were under a time constraint, we rushed the development. It would have been better if we had more time to build out the system in preview, do more in-depth user acceptance testing, and develop comprehensive documentation.
We could have also used the time during a slower rollout to identify potential issues that have arisen post-launch. Building and launching a system without that identification process opens opportunities for glitches for all users.
My biggest takeaway is to not underestimate the size and scope of any project. What may appear to be straight-forward often has many hidden factors and sidetracks. As the leader, I let my direction take the project down a path I was comfortable with, but that didn't make it right for the team. For the future, having as many inputs as possible will help me avoid issues similar to what I encountered.
Read more from CTDO magazine: Essential talent development content for C-suite leaders.
