This article was first published on the LiquidPlanner web site in 2017

In the beginning, project management was formless and empty, and darkness was over the work breakdown structure. The Founders looked over the face of the startup and said all is good. And there was evening, and there was morning—the first day (metaphorically).

Then the company grew and its teams were fruitful and multiplied.

Projects competed for resources, and everything was late. The Founders looked upon the chaos and were not pleased. They looked upon the multitudes and chose one who was more organized or less busy than the others and said, “It is up to you to be a prophet, bringing order to the chaos and leading the projects to the promised land of on-time delivery within budget. You must quiet the babel of squabbling the offends our ears.”

So you have now been appointed to be your company’s first project manager.

You may have never been a project manager. You may have never worked with a project manager. Your company has no templates, no resources, no software, and, most importantly, no culture of project management.

Where do you start?

Have a clear mandate from the leadership.

I once worked at a small company without project management and was struggling because of that, so I just started doing project management without any training or buy-in from the company leadership.

This did not go well!

I wrote the company’s first requirements document. As we reviewed the document, one of the stakeholders said, “I’m used to just complaining when engineering delivered something that isn’t what the market wants.”

I explained it was easier to build things right in the first place, which made a lot of sense to him. Having a requirements document reduced the constant churn of the product definition and helped the engineers focus on what they should be delivering.

Delivery dates were based on when someone wanted a product and not a detailed plan. I was sick one day, and on my return the scope of a project I was leading had changed significantly, but leadership expected no schedule slip nor did they allocate additional resources. When delivery dates aren’t based on real plans, then management can’t make the cost-benefit trade-offs that they should.

People were moved on and off projects with no warning or notification. No one set priorities among the large number of active projects. Not surprisingly, every project was late.

Without a mandate from the top, I was unable to control how resources were allocated or expected completion dates were set. I could change things around the margins, but not fix the underlying . Quoting from Reinhold Niebuhr’s Serenity Prayer:

God grant me the serenity
to accept the things I cannot change; 
courage to change the things I can; 
and wisdom to know the difference.

Do what you can, make the case to do what you should, but if there’s no buy in, accept that and hope that your example of good management over time will change things.

Always be adding value.

For a salesman, the key is to Always Be Closing. For a project manager, you need to always be adding value, or at least not subtracting value.

Before you were anointed as your company’s first PM, things were done a certain way and it probably gave the individual contributors a lot of autonomy. They probably “knew” what needed to be done (and were probably right most of the time). They won’t appreciate you coming in, setting priorities, and “getting in the way”.

For you to do your work (e.g. building schedules and writing status reports), they’ll need to spend time sharing their expertise and knowledge. If they don’t see the value project management adds, they’ll see this as “wasting” their time that should be spent doing valuable work.

You need to be gentle but firm with this pushback. Make sure you get what you need to be successful, but be as accommodating as possible. Maybe you put together a starting point work breakdown structure and ask, “Where is this wrong?”

Listen more than you speak. Before sending a status report to stakeholders, send it to the team. This provides the team with an opportunity to check it for accuracy, helps them understand why you’re asking for their updates, and shows them that their concerns are being communicated up the chain.

Whenever possible, be a resource to make their job easier. One of the best ways to help the contributors is to create schedules based on input and logic, rather than management’s hopes and dreams. Having clear requirements can be a great help to the individual contributors as can going to battle getting resources (e.g. software upgrades, test equipment).

You could volunteer to take on vendor logistics and management. Everyone should know that you want to help and nothing is beneath you. Be careful not to take on tasks that the team doesn’t want you to do.

Methodically build your infrastructure.

You’re starting with a blank slate, which is a wonderful opportunity and a daunting task. You’ll need a task management tool (like LiquidPlanner), bug tracking system, standard-operating procedures, document control, and the list goes on and on and on.

Where to start?

Pick the biggest project management related problem you currently suffer from, and work on solving that. Maybe managing resource conflicts is the biggest problem, in which case I’d start with a list of every project in priority order, which can help manage conflicts.

If that doesn’t solve the problem, try creating a matrix with every project on one axis and all resources on the other. Add how much time each team member is expected to spend on that project over the next two weeks, and work with the managers to update this sheet regularly. If any person is loaded by over 85 percent, gather the impacted managers and negotiate.

If that doesn’t solve the problem, then implement a tool like LiquidPlanner that can balance resources automatically across multiple projects. In every case, implement the simplest solution that solves the problem.

Be a problem solver.

As you help your company eliminate barriers to success, the team will see the value you’re adding and be more eager to help you build strong plans.

When they see delivery dates based on detailed schedules they helped create rather than when somebody wants something delivered, they’ll be happy to contribute to the planning processes.  When engineers no longer feel pulled in five directions by three people, they’ll understand why you’re not just “overhead”.

Every time you solve a problem it makes the next one easier.