Robert P. Churchill CBAP, PMP, CSM, CSPO, CSD, CLSSBB Process Analysis for Business and Industry I can help you... Analyze and Document Your Process

Project Manager / Program Manager

First you learn how to do, then you learn how to organize the doing.

While I received a certain amount of leadership training in the Army and have earned a PMP certification, the most important insights into managing projects, programs, and to a lesser degree products, is experience. The experience comes in the form of understanding systems; communicating with customers, colleagues, technical and non-technical staff, and stakeholder at all levels; software development tools, method, and theory; and having a sense of what meeting customer requirements is about.

I began traveling to work with customers very early in my career and was recognized for having a certain amount of "customer savvy." This gave me more opportunities to get involved in upfront planning, discovery, and design efforts that taught me more and more about how all the pieces of a project, program, or product come together. While developing, installing, and commissioning control systems in the steel industry I was often the last person remaining on-site. Since I was also solely responsible for much or all of the Level 2 control systems and the high-level operation of the furnaces I served as my company's main liaison with the customer for extended periods. I also began to attend sales calls and design meetings, and give presentations.

When the opportunity presented itself I implemented online discussion boards to allow company personnel to interact with customers and each other. I began to work with contracts, first at a fairly superficial level and then in a much more involved way. I began to elicit and manage requirements and do extensive design and process documentation. I also provided training to customers and colleagues in different situations. I often did much of the communication with the customer about travel, schedules, meetings, milestones, and design, and ultimately ended up managing a program with four separate task orders, 30-something employees, three subcontracting companies, a remote office, and a sizable budget with responsibilities for tracking and invoicing.

I've used some of the standard collaboration tools but I tend to keep my planning, tracking, and reporting methods as light as possible. I prefer tracking costs and tasks on my own in Excel rather than Project, even when it comes to Gantt charts and critical path analysis, which rarely come up anyway, at least for the efforts I've been on. I view bodies of knowledge like Scrum to be guidelines and suggestions rather than rigid frameworks. I apply what works and what's needed for the situation at hand.

I'm a big believer in keeping everyone involved, informed, and engaged, and that involves sharing what I've learned, being honest about what I know and don't know, helping others learn and grow, learning from and being open to everyone, supporting internal and external communities of practice (I regularly attend several technical meetups in DC and Baltimore and have been a presenter), giving people opportunities to try new things, and generally trying to make things easier for people.

I didn't plan this part of my career. It wasn't a goal to do any sort of management, it just kind of happened. I just like to analyze interesting problems and come up with neat technical and procedural solutions. If that experience gives me more leverage to affect what kind of cool analyses I get to do and what kind of systems I get to work on then that's great. If that experience isn't needed and I'm only asked to be a team member then that's great, too. Either way I can give colleagues the best of what I've seen while helping them avoid some of the pitfalls.



CC0 if possible, else Creative Commons License CC Attribution 4.0. Full statement here.
Rights to third party linked and referenced materials are assumed to be held by their respective owners.