Skip to content

My first project at Objectivity - PM summary


Apr 8, 2019 - 5 minute read

Michał Stankiewicz
See all Michał's posts

2988 HC Digital Transformation 476X381


This is the last part of the story describing my first project that taught me more than any other project that I have taken part in.

In the previous posts (part 1, part 2 and part 3), you had a chance to learn about the mistakes we made while preparing, initiating and delivering the project. Today, as promised, I am going to present the mistakes I made. There were a lot of them, however I have chosen two most important ones as they were the root causes of all other issues I faced during the project. Moreover, I believe those two mistakes are frequently made by managers during their first projects.


When a  Project Manager joins a new organization,  they are expected to perform their tasks efficiently from day one. The same expectations applied to me. Nevertheless, I wasn’t left alone. I had my mentor’s support, who I could consult my doubts with. My boss was at my disposal at any time I needed. I could observe other project managers in action - the techniques and tools they used. Last but not least, when starting a new project, I was given a detailed description of the delivery process, which was supposed to guide me through the next phases of my project. As you can see, my environment was well-prepared. However, it was my responsibility to make the most of it. Unfortunately, I didn’t.

Delivery process

The delivery process defines two things: steps to be taken during each phase and roles to be involved, which I was certainly aware of. However, the first serious mistake I made during the project preparation was to tick off the points from the list without thinking about their actual purpose. As a consequence, our team lost the opportunity to prepare well for the upcoming work. On the face of it, everything went smoothly. In fact, we overlooked many issues and problems that made our work harder.

The second mistake was to assume that everyone was aware of their own areas of responsibility. It was true to some extent as the delivery process seems to define itself. However, the devil is in the details. As there are no two identical projects, detailed duties need to be clarified at the very beginning. This is even more important when we are new to the organization. It may result from the fact that roles and responsibilities might differ between companies.

So what were the consequences of such a mistake? As I didn’t know what to expect from the Analyst and the Architect, I often had to assume their responsibilities. I prioritized the backlog or made decisions regarding technical aspects. It was quite confusing for the team and resulted in significant waste and efficiency drop.

Notebook and pen

No single source of truth

The main responsibility of the Project Manager is to know exactly where the project is. It’s quite common and normal for a project to be delayed. However, it is not fine when a project manager is not aware of the degree of the delay.

The control over the project is as good as the quality of data and tools used. As it’s already been mentioned, I used the tools that other managers did. But instead of understanding them well, I decided to automate everything. I spent a number of hours working on big Excels containing complex formulas that were supposed to do the job for me. As you can imagine, nothing worked as expected. I got different results every day. Instead of focusing on the team and the project itself, I was troubleshooting my tools. What was even worse, I wasn’t able to provide the team with clear info about the project status. Therefore we weren’t able to plan the work. I felt I was losing the team’s trust and I had no idea how to change that.

It is a Project Manager’s  responsibility

It is quite common that when we are trying to help someone, we come up with a bunch of solutions. You might be surprised but it wasn’t the case during this project. From the very beginning until the very end I heard nothing like: ‘’Do it this way’’. Instead, I heard: ‘’We trust your skills; let us know if you need any help’’. I heard it even when the first signs that the project might fail occurred. It was me who was in charge of the project and everyone respected it. It also hadn’t changed even when I lost control over the project. So what happened that I managed to get out of the woods, you may ask? When the situation started to look really bad, two things took place. Firstly, I got a clear message: ‘’We are afraid you have no control over the project’’. Secondly, I was asked to present the way I see the project. Sounds simple, doesn’t it?

Turning point

During an hour-long meeting, while describing my perspective out loud, I started noticing some issues. I think the most eye-opening moment was when I was jumping from one Excel to another, trying to get simple info: what is the remaining capacity and scope to be delivered. And as you can imagine, I didn’t get it. However, this exercise allowed me to change the way I looked at the project. I realized I was focusing on solving current issues instead of paying attention to their root.

Right after the meeting, I gave up automatization for a simple solution. Until now, I track my projects within a single Excel file entering the most important metrics and registers only. Finally, I had time to look for other issues we were struggling with within the project. I switched from reacting to the situation to shaping it. Thanks to that, I was finally able to make a plan.

My lessons learned

From a time perspective, I can say that this project is one of the best things that have happened to me in my professional career so far. During these 4 months, I learned as much as within the previous few years. From all the lessons I’ve had, the following ones have been the most important to me:

  • Even the best process won’t ensure success if blindly executed. Everything you do as a Project Manager must have a purpose and requires focus on achieving project goals.
  • Having control over the project is as good as the quality of data used for making decisions.
  • Simplicity is the key, there are just a few metrics that can give you a very good overview of the project.
  • Sometimes it is worth having a short break that will allow you to change your perspective, see the bigger picture and look around in search for the root causes or ideas of how to improve the situation.

With the last point, there is yet another finding.

Great place to work

It is just fine to fail as long as you draw conclusions and learn your lesson. This is the task of your organization to provide you with room for making mistakes. It is easy to take over control and fix everything quickly. What’s more difficult is to show trust and give support even when things are getting worse, which should be done in moderation, of course. I am lucky that Objectivity shows understanding and that I had been given a great opportunity to grow.

This was the last part of the story. I hope you enjoyed it and found it useful.

2988 HC Digital Transformation 476X381
Michał Stankiewicz
See all Michał's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle