IT Project Manager first 90 days

The first 90 days as an IT Project Manager are crucial to determine your future in this role. In this article, you’ll discover hidden challenges and proven strategies to help you avoid the most common pitfalls. You will learn how to deal with technological chaos, office politics, and your doubts. It’s a practical step-by-step guide that will guide you through the first 90 days, helping you build a solid foundation for future success. I invite you to read it!

The Unspoken Truths and Proven Strategies to Avoid Disaster

Why Your First 90 Days as an IT Project Manager Will Make or Break You

The first days as a Project Manager will show you whether this job is for you. It seems nothing new; you could say this about any job, but statistics show that 43% of people who start their IT Project Manager careers drop out after a year or resign. Why is this happening?

First of all, when you start working, you have no idea what it will look like. This one looks very simple: manage people a bit, prepare documents a bit, present something, no philosophy. However, the reality is quite different. In the book Project Coffee, I wrote about what the work of a Project Manager looks like on a daily basis. I invite you to read it; the book can be purchased on Amazon.

The second reason is that candidates often start as Project managers without prior preparation. I know there are courses on project management, and these courses are often very valuable, but you won’t find any course that will tell you about the invisible walls you will encounter, and these walls are:

• Technological chaos – you don’t have to know how to code but must understand what it is all about. How software is created, what the rules are, what the limitations are, and what the software development process is. You won’t learn this in a project management course. Maybe you already have experience in coding, which will definitely come in handy, and if not, it would be useful to learn at least the life cycle of Online products and the principles of software development.
• Office Policy – A separate book about this, or maybe even a series of books, could be written. As an IT Project Manager, on the one hand, you deal with developers, so you need to be able to talk to them, but on the other hand, you are dealing with business, and you need to be able to play corporate games. You need to be able to communicate with both parties, understand their needs, and be able to balance on a very thin rope stretched between the technology and business domains. You will only listen to business developers who are willing or unwilling to let the project into a channel from which it will be difficult to dig out. You will only listen to developers, the business will quickly request a change of PM, explaining that you do not understand their needs.
• Your uncertainty or overconfidence – while at the beginning, you will be bothered by uncertainty, which is related primarily to constantly operating on an uncertain tomorrow, you may become overly optimistic and self-confident after a few smaller or larger successes. Being an IT Project Manager means efficiently managing an uncertain tomorrow, literally. At the end of your workday, you never know what will happen tomorrow, and tomorrow can be very surprising. Therefore, you must be confident in yourself on the one hand and humble about what will happen tomorrow on the other. Finding such a balance in yourself is difficult, especially at the beginning of your career.

The first 90 days as an IT Project Manager can be compared to a marathon, except that you have fins on your feet instead of comfortable shoes. You quickly have to find your way through a jungle of deadlines, sprints, and risks, and around every corner lurk stakeholders who are eager to listen to the team turn water into wine, but when water escapes from leaky decanters, you have to fend for yourself. Their role usually includes menacing frowning, nervous grunting, and impatient smacking.

Looking at it from the outside, it may seem strange because 68% of projects exceed the assumed budget and implementation time, so you could say that all of us in the project management industry in IT have gotten used to it, but it’s not true. Each new project seems to be the only one in which the assumed budget will be sufficient, and all the functionality will be delivered within the deadline. I must admit that it’s even a funny assumption looking at the statistics, but as a person entering the world of projects, you will definitely face such an expectation and maybe even get frustrated that you didn’t keep your budget in check or meet the deadline. Be calm. The best in this industry have such misguided projects behind them. It is important that you learn from your mistakes and do not make the same mistakes twice. This distinguishes the best PMs from those with a slightly worse reputation.

To sum up, being like Luka Modric or Andrea Pirlo on the pitch is the most important thing. From the first minutes, show that the team can rely on you, but never try to play solo. Play the ball neatly between defense (developers) and attack (business). Gain the trust of both sides and make both formations play to the same goal, and you will quickly make a name for yourself as a good PM.

One more piece of advice: more important than efficient Jira management is putting out project fires with a smile and coffee in hand.

The Hidden Challenges No One Warns You About

I’m curious what you think about your first 90 days as an IT Project Manager. Do you see more sprints, brainstorming, or colorful boards in Jira? Do you see fruitful refinements and successful presentations?

I would wish this for you and myself, but the truth is a little different. Most of your energy will be consumed by fighting invisible enemies, such as imposter syndrome, changes in business requirements, oversights in solution design, sudden twists and turns, and corporate politics.

Research shows that six out of ten IT Project Managers experience panic attacks before meetings with stakeholders – usually after discovering that “urgent scope change” means “do it for free until tomorrow”.

Even if stakeholders are not busy constantly changing business requirements, imposter syndrome is another invisible enemy in the project. He is like a real Ninja; interestingly, you never know who will wear a black outfit and start looking for a way to break into the design castle.

What is this imposter syndrome game about? Well, when you think everything in the project is organized, everything is going as it should, and you can finally get down to some mundane tasks related to settlements or organizing documentation in the project, suddenly a “ninja” jumps out of hiding. He comes and tells you that as far as he remembers, you dated differently, or it was agreed differently. And he is so sure of what he says that you have no choice but to start looking for records in the documentation that this “ninja” openly undermines. Finally, after many hours, sometimes days, you already have a complete set of documents, and you show them to the “ninja”, but he is not going to give in so easily and states that you must have misunderstood something and written it down wrong, and it should be as he says. Often, you have no choice but to start the design puzzle all over again.

I have not yet mentioned one mysterious enemy called “collective amnesty.” What does it involve?

Imagine that you start a project. You organize a “Kick Off” meeting where you present the assumptions of the project, present all stakeholders, and determine how you will communicate in the project and how you will manage risks or changes in scope. In other words, you define the rules according to which you will run this project. At the end of the meeting, everyone agrees with you. They thank you for the beautiful start of the project and wish you success. In general, the atmosphere is wonderful. You think this project will go smoothly, but it’s just an illusion. The next day, or within a week at the latest, all project stakeholders will forget what you agreed on. Everyone will act as they see fit, and you will nervously wave a note with the arrangements you all agreed on, but you know what? Just as you can guess, the “imposter syndrome” game starts now.

Finally, I saved the best of enemies, and that is “Tool Armageddon”. At first, you may feel like Winnie the Pooh standing in front of a honey closet, but it won’t last long. You often get access to a few or a dozen tools because they communicate on Slack, others on Teams. These people want to have tasks in Jira and others in Click Up. And if you’re wondering which of the systems is better, you can check it out in the Jira vs. ClickUp article. Add Excel, Miro, and who knows what else.

The truth is that neither party will let go, and you, as a PM, will have to learn how to use each of these tools. You have to be like Neo from The Matrix and master all the rules of using the systems as quickly as possible. Otherwise, you will be lost.

I forgot one more thing: you also need to choose a reliable project management tool that will allow you to connect all the threads in an ongoing project and remind you of the most important deadlines. Good luck.

A Step-by-Step 30-60-90 Day Plan for Survival (and Success)

Days 1 to 30: Listen, learn, and map the minefield

Your goal for the first 30 days is to learn as much as possible and take as many notes as possible. Why so? In the beginning, no one will be surprised or irritated by the fact that you ask a lot of questions, know nothing, and are simply curious about how the processes in the company are arranged.

Be like a detective on the trail of the crime of the century. Observe, take notes, look for traps, and look for potential allies. Find out who has what roles in the company, who can help you when to do research, who knows all the people in the company, and who is in the front line when innovative solutions are implemented.

Hang out with the developers when they have a daily meeting, when they solve problems, and when they refine. Attend business meetings, at least those that allow you to join as an observer. If possible, attend meetings with customers.

Also, remember to review the project documentation for both the projects you will be running and those that have already ended.

In other words, the better you get to know the company in these 30 days, the easier it will be for you to run the project later. Also, don’t forget to ask the project team how they would like the project to be run and where it is okay with you. Agree to the team’s proposal, and if you feel that the process should look different, let them know what you expect and why.

And one more thing. This is important because it can be different, and you won’t always have 30 days to get to know the company. It may be that you will get a day or two before they throw you into the whirlwind of design events. However, this does not exempt you from doing your homework in the first 30 days. You will simply have to complete project tasks and work as a detective at the same time.

Days 31 to 60 of this: Build alliances and solve some problems

There was time to get to know the company, and now is the time to show what you can do and build a position there. If you have worked honestly as a detective, the following days should bring measurable results and reassure your co-workers that you are the right person in the right place.

How to do it?

Choose a few problems that you have identified and complained about by the project team, and which can be solved within a week at most. The truth is that project teams are so focused on delivering value in the project that they don’t have time to solve problems related to how the company functions. You could say that they are like someone who goes to work every day the same way and trips over an invisible stone on the road every day. He never has time to move it because he is in a hurry to get to work, so he will either learn to walk around it or stumble endlessly. However, you have a moment to remove this stone. Do it and announce to the whole company that you have done it. Let them remember you as an effective person.

It doesn’t have to be a big deal. It’s important that the problem you choose bothers others and can be solved in a week. It could be a new way of defining sprint goals, a different format for retro meetings, a different way of describing tasks, or automating routine tasks. Don’t really aim for the mighty boulders; they can crush you. Instead, take a small pebble out of your design shoe, and you’ll remember it.

During this time, don’t forget to build relationships. Start with those who seemed friendly to you from the beginning. Talk to them and find out what they do, their hobbies, and what they are interested in. Building such a relationship shouldn’t be difficult if you are genuinely interested in the other person. In the next step, you can ask such people to introduce you to others, in this way you will get to know other people, and in addition, you will benefit from the effect of the authority of the person who will introduce you, thanks to which it will be easier for you to build a new relationship. Remember that good relationships are more valuable than gold for an IT Project Manager. Build and nurture them honestly, and there will undoubtedly be a moment in the project where solid relationships will save you and the project from trouble.

Days 61 to 90 of this: become a legend, or at least don’t let yourself be fired

Different things can happen during this period. If you put in the first 60 days and have a bit of luck, you will become a legend. If you are unlucky but have worked honestly for the first 60 days, you will probably stay with the company longer. If you haven’t entirely found your way around the company for the last 60 days, this is probably not the place for you.

So how do you get to the legend level?

Choose the problem or challenge that will bring the most benefit to your solution. At the same time, you will be able to present the results of the implemented changes after a maximum of 30 days. The plan is simple. At the beginning of this stage, you choose a problem and implement a solution, and at the end of this period, you boast about your success, thus making people in the company start to see you as a valuable member of the team.

It still doesn’t have to be something cosmically significant. It must be noticed. I will tell you from my own experience how I earned the nickname “success” in one of the companies I worked for. The IT department did not have good PR at the presentations of the work results for business. The focus on challenges and problems dominated, which meant that the business did not have the best opinion of IT. The director said this needs to be changed; we must boast about our successes at the presentations. But how can it be done if the IT department is very critical of the effects of its work? It helped to focus on every success, even the smallest one, and a bit of fun in word games. I took care of it and proposed a new way of presenting the results of the department’s work. What? The change in how the results were presented was met with a positive reception, and I gained the nickname “success”.

Your first 90 days in project management are no joke, it’s a real triathlon. Swimming in data, running between meetings, and cycling at breakneck speeds on the verge of breathlessness. But, if you play it right, after these 90 days you will be well positioned in the company’s ranking of effective and valuable employees, and as we know from practice, how people categorize you at the beginning of their relationship, it will stay in their heads for a very long time, which will come in handy later, because in projects you will undoubtedly face more than one failure or stumble. It is worth it for them to say “even the best of us” than “he has never succeeded in anything yet”.

The 5 Deadly Sins New IT Project Managers Commit

As in any new profession, in the IT Project Manager profession, you will learn the most from the disasters that will happen in the project. Disasters happen regardless of the level of experience of the IT Project Manager leading the project. This is the specificity of work. However, the difference between a good IT Project Manager and an average one is how they deal with this crisis. The weakest are those who manage through chaos, and the result of these actions is entirely random. Sometimes it works, but in most cases it doesn’t. Mediocre people can lead the project from a dead end, but the bad taste remains. The best ones pull the project out of the way in such a way that no one will even notice that something has gone wrong. How do you get to this level? In my opinion, you have to go through several disasters, learn from each of them, and not make the same mistakes twice.

Let’s review the five most common mistakes so you have a solid base to start your career.

Ignoring technical debt.

How does it manifest itself?

Most often, developers start complaining that the code is complicated and that some “workaround” was supposed to be for a while, and the second year, they are already struggling with it and don’t have time for refactoring.

What is the risk?

Introducing some, usually minor, correction or improvement or functionality will likely cause an avalanche of undesirable events. No one can predict that this workaround, which has been done for a while, is incompatible with this small code change and that the project will fall apart. Withdrawing shifts quickly to reduce fire, followed by long hours of cleaning up the fire. In the end, the developers will say that they will not go any further with their work until they organize the code. So, there will be delays in the project. For an IT Project Manager, these are two disasters at once.

How can we prevent this?

Plan your refactoring time. It won’t be easy because the deadlines in every project are unsurpassable, but if you convince stackholders that if we incur technical debt, there must be time to pay it off, everyone will benefit.

Promising the impossible.

How does it manifest itself?

“Sure, we’ll release this functionality before the end of the month” or “Adding this to the range won’t change anything because it’s a minor change”.

What is the risk?

In short, it was a “failure to meet the deadline”, but this is only the beginning of the problems. There are several scenarios for the development of events. Depending on whether the team delivers the promised changes on the promised date or not. Contrary to appearances, it is worse when it delivers. If he does not deliver, a drama will happen, and many grievances will be poured out at the next meeting with stakeholders, but the scale of the disaster will probably be relatively small. If the team delivers the change on time, it will most likely trigger an avalanche of new requests for minor changes. There is no good way out of this situation. It’s like speeding a car towards a wall, without brakes and without the possibility of avoiding this wall. The more promises you and the team deliver, the more you accelerate the car. A collision with the wall will happen; it is inevitable. The only question is at what moment and at what speed you will hit.

How can we prevent this?

You have to realize that the band’s capacity is not made of rubber. Every team has its limitations, even if you think it’s different at first. This can be due to many reasons, but you can be sure that the team will not deliver on an unrealistic promise at some point. So, if the idea to implement one small change comes up at a meeting with stakeholders, you respond like an automaton: “Okay, at what cost should we implement this change?”. Don’t be fooled if they encourage you to deal with it alone. This is not the role of an IT Project Manager. It is the role of the Stakeholders or Product Manager to determine what is to be implemented and in what order.

Neglecting communication

How does it manifest itself?

Corridor rumors inform stakeholders about the project’s progress. The project sponsor is not available. The Product Owner answers all questions with “I don’t know” or “it depends.”

What is the risk?

In the best case, the project will come to a standstill, and you will have to think a lot and work to ensure clear communication. In the worst case, they will throw you out of the project as an ineffective IT Project Manager. Either way, it won’t be pleasant. I wrote about how this can look in practice in the book Project Coffee, which you can find on Amazon.

How can we prevent it?

If the project is just getting started, define a communication pattern, discuss it with project stakeholders, make adjustments if necessary, and then stick to that pattern. If you find that your communication isn’t working during the project, make changes, discuss with stakeholders, and stick to a new communication plan. If you are entering an already accelerated project, familiarize yourself with the existing communication scheme, and if it is ok for you and works, then use it if you need to improve something, correct it, discuss it with stakeholders, and act according to the arrangements. Communication problems are one of the most common causes of problems in projects, which is why it is an extremely important aspect of the project and one of the most critical areas for an IT Project Manager.

Team micromanagement

How does it manifest itself?

You stand over the programmers and ask the same question every 15 minutes: “Are you ready yet?”. It may also be that the most common question on Slack or another communicator is, “How is the fix implementation going?”

What is the risk?

In the best case, the team will stop responding to your questions. In the worst case, they will report to the project sponsor to replace you with someone else because it is impossible to work with you. Both scenarios are disasters for the project.

How can we prevent it?

Daily is the best time to gather information about your team’s performance. Every development team practices a daily routine, during which you should collect enough information about the progress of the project or problems that have arisen in the project. If you don’t have answers to your questions every day, it means that something is wrong. What exactly is difficult to predict, but it is worth talking about it with the company’s team or more experienced IT Project Managers. Also, remember that every development team works on some project management tool, and from this tool, you can also read a lot about the progress of work, provided that the team honestly updates the status of tasks.

Lack of process documentation

How does it manifest itself?

You answer every question with “It’s complicated”, “Nobody knows how the process of accepting changes works”, or “It depends”.

What is the risk?

At some point, usually some time after the introduction of some functionality, someone will come and ask: “Why does it work like this?”, “Who agreed to this?”. If you don’t have documented processes for the project, you start nervously looking for an answer to this question. Of course, such questions only arise when something has gone wrong in the project. A change did not give the expected results or upset the client or customers. For you, these will not be pleasant moments and may end differently, depending on who and how upset they are.

How can we prevent this?

Even if there are no documented processes in the company or no one respects them, the project is your space. You in the project can set extraterritorial rules for documenting processes. Of course, they should be simple, understandable, and easy to enforce. Be sure to communicate them to stakeholders before implementation and explain why you’re introducing them. They may require minor corrections. Do it if these changes don’t turn the process upside down. Remember that the lack of clear rules regarding processes in the project always turns against the IT Project Manager, so make sure that the rules in your project are clear and respected.

Why do we fall into such traps at all?

At first, probably because project management seems easy. You don’t have to do much: attend a few meetings, collect some permissions, or send something there. Simple. It may look like this at first, but as you already know from this article, it only looks like this. Problems in the project pop up out of nowhere like crocuses in spring. The more problems, the greater the stress; the greater the stress, the worse the decisions we make.

The problem is that the longer you work as an IT Project Manager, the more confidence you gain. This can also lead you to areas where every move is a disaster, and you are left with a choice between the plague and cholera.

The most important thing is to be well prepared, vigilant, and, above all, accept that you are the conductor of the project. However, you do not do any work yourself, nor do you make decisions greater than those authorized by the project sponsor.

Don’t worry too much in advance, either. Everyone has made or will make any of these mistakes, or even all of them at once. The most important thing is to draw conclusions from them for the future and honestly admit when something goes wrong in the project.

How to Leverage Sports Psychology to Outperform Burnout

Most likely, at the beginning of your career as an IT Project Manager, you won’t even think about it. You may even think that the problem of burnout will not affect you. I wish you this with all my heart. On the other hand, research shows that burnout, frustration, or hypersensitivity affects every IT Project Manager. It is only a matter of time before project problems press you so much that you don’t want to do anything.

In this profession, time pressure, excessive expectations, conflicts, or stress are an indispensable cost you will incur. The question is, what will you do about it, and in fact, how will you manage yourself in the face of such a burden on your psyche?

It is very similar in sports, where there is a lot of talk about managing the team’s energy, resistance to failures, and strategic thinking under pressure. You could say that an IT Project Manager is a bit like a football team coach during a match. On the one hand, he will not score a goal himself, but the team hopes that he has prepared the best strategy that will allow them to win. On the other hand, the club’s management and sponsors are counting on a good result. Besides a good result, there are also fans who want to watch a nice game with the players, allowing them to feast their eyes. A lot of pressure and a lot of expectations to meet. Even if everything goes according to plan on the pitch, the stress must be enormous. Matches, on the other hand, take place every week, and sometimes even twice a week. Each important one, each one must be won. That’s a tremendous amount of stress to bear. IT Project Manager has a similar experience. Every sprint is important, you have to deliver value in each one. The business must see the results, the customer must be satisfied, the project must bring measurable profits, and developers must be satisfied with their work.

What elements from the world of sport can be implemented in the world of projects?

Start by focusing on what went well and what will go well.

Our minds tend to focus on what went wrong and what could go wrong. This helps for a while, but in the long run, it is destructive and generates high stress. I don’t mean to close our eyes to the lurking risks, but to balance the division between bad and good. After all, you can have notes about mistakes and how to avoid them in the future, but also notes about successes and how to replicate them in the future. In addition to writing out negative scenarios for the project, you can also write out optimistic scenarios. This will help you catch a broader perspective and balance your perception of how the project is going.

Team energy management- what is it anyway?

Sometimes, it seems that we are too optimistic about the capabilities of development teams, forgetting that they are people, not machines. If we approach the matter this way, you will probably agree with me that development teams cannot constantly work at full speed. They also need to have space for worse days and weaker performance, and in my opinion, the sooner we agree to this, the easier it will be for us to work on the project.

Of course, the point is not for development teams to have all day to do nothing or spend time in the game room, but rather to give them space for slightly less demanding sprints, during which they will refactor the code, supplement the project documentation, or search for interesting technological solutions that could be implemented.

If the team has such space to rest, there is a much greater chance that when 120% of their effort is necessary, they will find enough energy to make this effort and bring something to the so-called ASAP.

We also have breaks in matches or subsequent attempts at a given competition in sport. In IT, we also have such breaks, and they are called retrospectives. It is important to use them well. But let’s start from the beginning, i.e., why do we act iteratively in IT projects? In addition to the fact that it speeds up the process of handing over functionalities to the client or allows us to respond flexibly to changes in the project environment, it also gives us a chance to improve how we operate.

As humans, we can go on and on about what to do best and how to do it, but the truth is that we do best by doing. So let’s not be afraid to take up, even a very bold one, thesis at the beginning of the sprint, and then after the sprint, we can tell ourselves whether this thesis has come true or not. If so, that’s great. We can still refine it or leave it as it is, and if it doesn’t work, let’s throw it in the trash and take another thesis for verification. There is no point in blaming each other for a possible failure here. We are all human, and none of us has a crystal ball predicting the future, so each of us can be wrong. One today, the other tomorrow, there is no point in pointing out mistakes, but it is worth boldly looking into the future, testing what works and what does not, and drawing conclusions.

Finally, one more important element in an IT Project Manager’s work is dealing with failure.

Professional athletes train the ability to reset quickly after a failure. This helps them quickly draw conclusions and focus on the next challenge. Unfortunately, IT Project Managers dwell on every failure, even the biggest, as if they had just lost a match for the World Championship.

This leads to frustration and often to resignation from further career in this profession, but it can be done differently.

Instead of dwelling endlessly on design blunders, try these four techniques:

5 minutes of mourning

If something goes wrong, the project will have a solid setback; give yourself 5 minutes to mourn. Once you limit the losses, collect the wounded, and get the project back on track, give yourself a moment to mourn. Get rid of everything that sits on your stomach and doesn’t leave you alone. Write down bitter e-mails to people who have let you down; don’t send them later, but delete them. Shout out, draw caricatures of your coworkers, or imagine you are cleaning up on all of them. Do it, and then close the topic ceremoniously and focus on the next challenge.

Diary of victories

I have already written above, but I will write again: Note all your successes. The big ones and the small ones. It all matters because when the dark clouds come, when you start to doubt your abilities, then it will be the best time to open your victory diary and admit to yourself that you can do something and you have done more than one thing in your projects well, or even very well.

Pre-match routine

Create a ritual that lets your brain know it is entering an intense work mode. It can be anything, it is important that it acts on the brain as a trigger. For me, it’s preparing the machine to make coffee. I haven’t made it yet, but I’m preparing the machine. I put a teapot with tea in it, and in the meantime, the laptop starts. Every day before work, I do things in the same order, and my brain already knows I am starting work.

The whistle and the end of the match

It is also important to finish the work. Unfortunately, as IT Project Managers, we often bring work home because this still needs to be thought through, that needs to be solved, something else needs to be written, and something needs to be prepared. This means that instead of resting, we continue to work. How can we change it? Create a routine to complete the work. Just like with the pre-match routine, having a learned sequence of events after the match is good, allowing you to rest from work after work. I start by taking notes. If I don’t manage to do something or have to start another day with something, I make a note to get it off my head so that I don’t have to remember it all afternoon and evening until the next day of work. When the note is prepared, I close all the windows in my browser, e-mail, and finally, my laptop to eat dinner. This is how I finish my work daily; my brain already knows it is over, and it’s time for other activities.

Summary

Project management in IT is not an easy job, where you don’t have to do anything, everything happens by itself, and money falls from the sky like manna. The first 90 days are just a warm-up. Usually, you will get easy projects to start with, but don’t let that fool you because even in easy projects, there are the same pitfalls as in more extensive and complex projects. Use the first 90 days to build a solid starting position in the company, but don’t forget to rest. Over time, if you like it and find yourself in this industry, you will get more challenging projects to manage, but in general, the principles are always the same; only you will be more thoughtful about the experience. Good luck.

PS. If you have any questions about working as an IT Project Manager, feel free to ask them in the comment section of the article or send me an email.