As companies grow, they have more teams to coordinate, more users with high expectations, and more users to upset when something goes wrong. It is inevitable from the leadership to eventually have higher expectations on execution and quality. That is where project management comes to the picture.

But how to grow project management competency for a multi-hundred-employee company?

What doesn't work?

The "doesn't work" might be a bit harsh, let's say what I haven't seen to work so far. In most cases companies either start to introduce templates (project, document, process) or thinking of hiring a project manager to manage work. They all make sense, but I think they often fail because

• Templates: People who need to use these templates don't have the same experience as the person who wrote the template. These templates usually describe only the happy path (while real world is messy), and don't talk about the intention behind them. They also don't explain how handle exceptions. People who forced to use these templates feel abandoned and stupid. If we are lucky they simply ignore them, but in worse case they waste time to fake them without impact.
• Hire (or contract): This approach brings the know how in, but that is not the most difficult part in project management. In fact, project management can be relatively simple, what is difficult is to know what tool to use in which situation, and how to apply it in a company where practically everyone around the project manager don't value or understand the need of estimation, milestone, or committing to timelines or to make tradeoff. Changing the culture is easier for a person who understand why the company works the way it works, where it is possible to change, and who are the key people who can make changes through.

They remind me when companies wanted to be agile, so they started to hire Scrum Masters, and cargo culted SCRUM without understanding what they do for what reason. Or when a smaller company hire an experienced Big Tech engineer who struggles in their new role because the small company maturity (tooling and engineering culture) is fundamentally different from Big Tech.

Fronts to fight on

Let's be constructive! I think there is a approach that works better, but before sharing it, let's talk about what problems it needs to handle:

• Recognition: Does everyone in the company aware of that this change is necessary? Without it, project managers will feel alone trying to change we work. It requires top-down approach, and consistent communication from leadership as well: don't communicate one month the importance of predictability and milestones, and then next month downplay the effort of the project manages trying to make their planned milestones.
• Cultural: Managing a project at a company where everyone is used to estimations, milestones, commitments, etc. is extremely easy compared to an organization where employees see this as an unnecessary, artificial, time-wasting corporate bureaucracy. I think this is the most important change that needs to happen, and it can be made much easier by people who have established trust and know who are the key people in the company.
• Knowledge: People needs project management knowledge, but for me, this is the easiest part. Reading a book or a few blog post gives you more than enough knowledge to start experimenting with project management. Talking to other employees in the company who are interested in the topic can always give good enough resolutions to the problems you have. No need to hire for this knowledge (it doesn't hurt), and better to learn this way than from templates.
• Tailoring: Project management doesn't happen in vacuum, it happens in an already existing environment. Knowing how to tailor the knowledge you acquired in the previous point need people who already know the company.
• Scaling: I mentioned the importance of culture change, and it changes by having more and more people thinking differently. I think the second most important problem to solve is to have a system that allows more and more employees from different levels to get involved and learn from each other.

What does work?

I see the following 5 step approach better to grow project management competency at a company:

• Flag to highlight: Leadership needs to communicate that growing project management competency is important. It is now just for the sake of playing around but a fundamental need for the company to be able to operate in the future. No big announcements are needed, just to be consistent in communication.
• Room to talk: Find the people at your company who are interested in project management and give them room to talk about it. The most important is to build bonds, and make information flow freely. Group learning is a working approach in modern education. A special interest group or a competence center can be made around this topic to make it official. Setting group goals is a good way to shift from "just talking" to eventually "arrive somewhere".
• Space to capture: Similarly the goal setting, documenting findings is important to scale later. The reason why documentation is important is twofold. (1) While project management literature exists outside the company, guidelines that tailored to your organization doesn't. (2) As your company changes, these documents needs to be updated. The goal is not to tell others how to do things (yet) but to capture learning.
• Process to scale: There is no organizational level change without scaling. Besides the above, there is two more things can be adding: learning through shadowing and delegation. Instead of relying on templates, start to pair experienced project managers with less experienced ones. In a different way, delegating a smaller part of the project to a less experienced project manager is good not only for them, but also for the original project manager by learning how to manage a project that has projects.
• Time to distill: Give time to this group and bubble up guides for the whole organization. How is this different from the template approach? Now you have significant amount of people in the company who lead by it, and many more who know why it is needed. These guidelines are less to make people to work by that, and more to tell people how the company works.

Project management is not rocket science. It is an old, established, well researched domain. The art in it is to know how to successfully apply its tools to your situation, and to create an environment where people can grow their competence on it.

I see the bottom-up approach to be more applicable than a top-down one.

How to capture learning

I once took the task to write the project management guidelines for my business unit that we can share with the whole company. I did a lot of research, and started to write the master document that addresses everything: definitions, why to do it, how to do it, alternatives, templates, how to share knowledge, etc. Needless to say I failed in the process.

Today, I would take a different approach. I think what you need is a short, basic guideline that focuses on the essentials, and many small documents that describes tools and practices that you can cherry pick for your case. These documents describes the situations when the tool is usable, how it works, give templates, examples, dangers, and contact person to reach out to with questions.

The essential guide must be applicable to all project. The more projects you have seen, the more you realize that only a few things are applicable to all projects. See my version of the document below.

Project management essentials

Every project is different, but there are principals that are true for all project. I am sharing my view on them as well as how to progress further from there.

Early OftenGabor Meszaros

My plan is to share the project management tools and practices I have experience with, what worked and what didn't. I will publish them as separate posts under the 🏁 Project tag.