With over 30 years of professional experience, I found myself in the job market trying to bring the value of that experience to a host of organizations that didn't find my resume impressive enough to even give me an interview. Many of the roles I applied for had lists of qualifications that required certifications of some sort or direct experience as a member of a product team. How could I spend 30 years involved in the management of products with no certifications or titles? I began to kick myself and feel like a complete failure because of it. Well, my pity party got me now where, so I began to reflect on my experience to understand how I developed my understanding of project life-cycle. My knowledge comes from direct collaboration with Product Managers, Owners, Designers, Project Managers, Engineers and Technical Support Specialists as a Technology Trainer
Many years ago the training department of my organization was moved from under the Operations organization to the Project Management organization. I'll never forget our first meeting as a newly merged team. Almost everyone on the training team were former broadcast operations experts made up of Producer, Editors, Graphics Operators, Operations Managers and Field Producers, so we were, for all intents and purposes right-brain dominant, while the Engineering and IT folks were also a part of the team, were more left-brain leaning. Our leader had the difficult task of trying to merge the two teams together, so he called all 50 or more of us into a room with one of the best facilitators in the company. We spent several days brainstorming the mission, vision and overall goals for the new team, which included a review of current project management timelines. Training was located at the very end of the timeline, if at all. I can't remember. However, I recommended that we embed training activities through out the project timeline moving forward. Our leader agreed that training should become a frequent touch point throughout the project life-cycle.
Finding myself on project teams as a trainer, was the safest seat in the room, because most of the time I could sit and listen to the myriad of conversations around both met and failed deliverables. I could listen objectively and offer ideas and solutions to keep moving the project along, because my contribution to the project couldn't be executed until design, development and delivery of the product was reached. Soon after participating in several of these meeting, the training department became a trusted and respected part of the team.
This is how we do it.
A training resource should always be invited to project meetings, especially when an effective training plan is necessary for the rollout of a new project.
