Managing IT projects is like playing Magic: The Gathering

Magic: The Gathering is currently the most popular collectible card game. In the game, players take on the role of powerful wizards who use creatures, spells, and artifacts to try to defeat their opponents. In the most popular format of the game, we start with a deck of 60 cards and face one opponent at a time. We achieve victory by reducing the opponent's life points to zero or running out of cards in their deck..

TIn a very interesting game format called draft, we build decks from a limited pool of cards, which we pick from "boosters" prepared for the game. During each drafting round, we can only choose one card and pass the rest to other players. At this stage, we must decide which colors our deck will be and what abilities it will rely on.

Similarly, at the beginning of a project, once we know the client's requirements and have chosen the technologies, we can start selecting people for the project. We build the project team from a limited pool of developers in the company, and whether a particular person joins the project depends on their workload with other projects, their skill set, the technology resources they have available, and sometimes even something as mundane as planned vacations.

In every Magic: The Gathering match, predicting the opponent's moves is a crucial aspect. At every stage of the game, whether it's your active turn or the opponent's turn, you should focus primarily on the possible response from your opponent to your play. This allows you to manage the resources needed to cast spells or summon creatures properly and to play the right cards from your hand.

This principle applies to project management in the analysis and identification of so-called "bottlenecks" in the software development process. These are situations that can cause significant programming problems, and failure to resolve them can affect the project's completion time and some of its functionalities.

In most game formats, matches between players end after one side has won twice. Often, when sitting down to the first game with an opponent, we do not know what deck they have, what playing style they prefer, and what surprises they may have in store for us.

This has an impact on projects when, even after analyzing possible problems that may arise during software development, we receive a list of errors that need to be corrected during the final testing. Therefore, every hour saved should be properly planned so that it can be used for testing and implementing fixes.

In the "constructed" format of Magic: The Gathering, we assemble a deck from an unlimited number of previously printed and allowed cards. One of the main principles of building a deck is the element of surprise, which means placing cards that the opponent does not expect and does not have an answer to in their own deck.

In this case, we have decided that in project management, we cannot afford to be surprised! When the client talks about their business expectations for the product being developed, our task is to clarify those expectations as much as possible to avoid any surprises.

I have often found myself in a situation where I had a significant advantage over my opponent and was confident of winning in my next turn of the game. Just as many times, I was disappointed when my opponent managed to completely reverse the situation with a few moves, ultimately causing me to lose the game.

This is the most important rule for us in project management: we cannot let our guard down too early. Even if a program has gone through a series of tests on developer versions, it may not function as expected when moved to a production environment. Our most important goal in such situations is to react appropriately and quickly.

In Magic: the Gathering, in addition to a deck of 60 cards, we also have the option to choose 15 additional cards, known as a "sideboard". After the first game, we can exchange cards from the deck with any cards from the sideboard to be better prepared for the opponent's moves in the next round.

In projects, we also use help from outside the project team. This allows for a fresh perspective on the problems that the project team faces every day. Sometimes it's temporary support for a specific task, and sometimes these people are engaged until the project is delivered to the client.

Decision-making is a key element of playing Magic: the Gathering. We start by deciding on the colors of the deck, specific cards to include, the sideboard, and the choices we make during the game against the opponent.

In projects, we face the same situation: we start by deciding which developer to involve in the task, how to plan their work, when to deliver the beta version of their project to the client, and whether to allow changes on Fridays in a project that is in production.

I hope that my conclusions have convinced you that project management is very similar to playing Magic: The Gathering. 🙂 What do you think? Maybe you have your own observations on this topic? In both cases, let us know in the comments what you think. Remember to also watch our vlog "IT Project Management 📅 is like a game of Magic: The Gathering 🔮".

Thanks for your attention and good luck with your projects and your game tables!

PS. If you want to visit eEngine for a game, let us know 😉