One of my first jobs had me in the role of a project management module expert for a new system we were installing. This was a big step for me since it got me out of being an IT Helpdesk Tech and into business systems analysis (something I find a lot more interesting). This project would impact how 2,000+ people did their jobs across 6 locations, but the challenge I had was that I didn’t know much about project management, or this new system….
The Setup
This turned out to be a great opportunity to learn both by experience and by training. Since we were already using a version of this system we had environments available for me to play in, and, even better, we had other folks on my team who were familiar with the system and underlying concepts. Having both of these isn’t always the case, so I got lucky (sometimes system implementations involve a team entirely new to the system, which makes for one rather steep learning curve) . It was still a lot of work to make time in the system and to get to know everyone, but it really helped improve my learning curve.
First Things First
The first thing I did was get access to a sandbox version of the new system so I could play around. This helped me build up the basics, e.g. where buttons were, what they did, what our current setup looked like. The other thing I did was get my hands on the manual (a digital copy anyways). This helped inform my wanderings by giving me some underlying context into what those buttons were intended for, as well as background on the architecture and setup of the system.
Manuals can be a great resource, but many systems are incredibly complex, resulting in incredibly large manuals. My recommendation here would be to focus on specific areas to investigate (e.g. whatever area you’re responsible for) to build up familiarity with them. Sometimes it is fun to randomly explore, but I find this can lead to areas that you may never use, or end up being more confusing than useful.
In short, hands on gave me the “how do I do X”, while the manual gave me the “what this does and how to do it”. The last piece, the “why are we doing this?” came later.
Baby Steps
Going from zero experience in the system to something more than zero was a bit painful. Not only did I not know what it COULD do, I didn’t even have the basics. So I put in time (to use a gaming term, I did a lot of grinding). I tried adding simple things over and over. I read the same page of the manual multiple times and then tried doing those things to see if it really did that (a great way to check your own documentation!). Eventually I got to a point where I felt like I could open the system without hurting myself, which was good. At this stage, however, I was almost effectively useless to the team. Sure, I knew there were some buttons, and what some screens looked like, but I couldn’t translate that into helping the business solve anything.
This was by far the most challenging aspect of it all. Why did finance care how the GL is setup? Was it important that we used a specific numerical sequence for project numbers? Which data field was used to identify the project owner? The questions were endless, and each time I found one answer, more questions popped up.
Not only was I very new with the system, I was almost entirely new with the business and with project management as well. I needed help.
Help!
Luckily for me, my project team contained a representative from most areas of the business (Accounting, Accounts Receivable, Project Management, Purchasing, etc). This made it fairly easy to find someone to help me understand the basics, and even better, they were on the same project, which made it incredibly easy to connect and get some of their time. In addition to getting formal background on what everyone did (I have zero background with Finance, for example), I also got to see how they were planning on using the system. This helped me better understand how my area would interact with theirs (e.g. if a purchase order is placed on a project how does that impact inventory? What about the general ledger? Hours worked?). These learnings helped me further round out my understanding of the system, and more importantly, the “why” behind how it operates.
I also got help from other employees who happened to use the system. This was another bit of luck as not every implementation I work on has this setup (although you can generally get help from the system vendor). These folks were able to provide me more background on historic use, which is honestly a bit of a double edged sword. Implementing (or re-implementing) a system is intended to improve operations, not simply continue with the status quo. Understanding how something works is critical to improving it, however, you must be careful to not simply copy/paste that into the next iteration.
Connecting with other technical folks helped as well. For example, I originally believed reporting was a built-in module of our system. After a lot of (poor) guess work, I found out it was mainly handled using MS SQL. Data was loaded into our data warehouse by (what I eventually learned) were CRON jobs, after which it could be used by our data analysts. Being able to sit down and talk with our data engineer and analysts made this process both much shorter and more enjoyable.
Leveling Up
Having hands-on access to the system, formalized training (in the form of the manual) and access to experts on the underlying process was immensely helpful. While each area was incredibly informative on their own, when combined they played off each other giving me more depth of insight than otherwise possible. For example, understanding that the project number for any given project was added to the general ledger code string shed a lot of light on why Finance was involved in the structure of project numbers (don’t worry if that doesn’t really make sense out of context!).
On the more technical side this combination of knowledge helped explain why our project managers were so adamant about knowing when data was available in their reports. If, for example, we loaded data from the system to our data warehouse at 1am that morning, their reports that day would be a day old. Once I explained this to them they got much less concerned when the number in their report didn’t match the live number in the system.
Learning a New System - Lessons Learned
Despite the specifics being unique to the situation, there are a number of lessons that can be pulled out of this experience and generalized to others. Indeed, I’ve repeated this general pattern many times so far (hands on, make friends, do your homework) since then.
Get hands on - learn by doing. Any time you have the opportunity to get hands-on with the thing you’re expected to learn, take it. It doesn’t matter if it’s a new programming language, new vehicle or new system, the more time you have poking around and seeing what is where the better.
Make friends - know your end users. Get time (face to face if possible) with folks who already use the system, or who understand the underlying concepts that will impact it. These folks will, at the very least, give you pointers on what to look into next. At best, they’ll be able to walk you through specific scenarios and help answer your questions.
Do your homework - understand the business applications. Underlying concepts or ideas are incredibly important to how systems, programs, processes etc. operate. Take time to read up on your field to get a better grasp of these. While they may be very abstract or seem unimportant they almost always will have an impact on what you do.