In my 8 years of experience as a Project Manager, I’ve learned that every project I’m working on is a completely different story. Depending on the client’s needs, product requirements, and even cultural differences when working with clients from around the globe, a specific approach and set of skills is required. Well-tailored attitude and a perfect plan are often key to success, but even the best plan may peter away if one small part of the mechanism fails.

As I mentioned before, every project is different in some way, but on the other hand, the same rules apply to each and every one. If you want your project to succeed, you don’t have to follow all the rules below. The point is to find those that apply to the particular project you’re currently working on.

From a Caterpillar to a Butterfly

Before ever starting the project it’s extremely important to establish major product components and define the client’s needs and expectations for the final product. A strong foundation keeps further work much easier if you know what you want to achieve at the delivery time. Sit down with the client, think it through and write down why the product should be created, how it should work, and how it should look. You need to UNDERSTAND the purpose of the product. Don’t ask about the button colors. Ask what it should change in the ecosystem, what should the user feel when using it, how it’s supposed to make things easier, what’s the overall impact of the application you need to achieve.

Get The Paperwork Done Well

This is an often mistake made at the beginning of the project. We work with the client on a vision of a final working product and the PM perfectly undertands this vision. Everything seems to be fine at this point as both parties want to get the product from the drawing board to the point envisioned and deliver it as planned. But during the development process some requirements may change, the vision may get slightly different over time — there’s nothing wrong with it and it happens more often that you would expect, but you have to remember that good documentation spares many stressful moments. Having very detailed specifications and requirements, UI design mockups, UX workflows and descriptions of expected behavior make the work much easier both for the client and the company.

You shouldn’t treat the software project in any way even a bit differently than a construction project. Changes may occur overtime, but everything should be documented. You wouldn’t want to build an additional floor of the building without knowing that the floor below has been changed during the building process and can’t withstand the increased load, right? So don’t do it with the application. Everything should be in the papers. 

Set Some Milestones

There’s nothing more frustrating and depressing than waiting too long for results of your precisely-planned and tightly-budgeted enterprise. It’s vital to define milestones (preferably one every week or two) where we can show the current progress to the client — refine UI, new feature, etc. First of all, it’s making the client happy and gives the very necessary proof of getting work done. It’s also extremely important for the development team to know that their effort results in successfully completing certain stages, and may be considered as a getting-shit-done-o-meter, making them motivated and keeping their abilities at a top notch level.

Autobots, Assemble!

If you already have everything well documented and you know what exactly you want to create, it’s time to get the right team around the project. The team should work as a perfectly assembled gearbox, composed of gears of different sizes and teeth shapes. The things that glue it all together are the common goal, appropriate motivation, and — what I find very important — excellent communication skills and simply knowing each other well. As a PM at Tivix, I have an awesome opportunity to choose my team from top-level specialists in every single field of expertise I need for the project. What’s worth noting is that we’re also laying significant emphasis on the team integration. What’s making our team the best on the market is not only the experience, knowledge, and education we have, but the good friends we all are.

Get The Numbers Right

If you asked me what I understand to be good Project Management, I’d say: “it’s simply knowing what’s going on in the hood.” It’s extremely important to keep track of progress and be aware of every blocker, issue, client concern, and questions on a daily basis. One must simply know what’s happening! We’re also keeping track of the hours we spend on the project every week, creating a weekly budget report so the client and we are also well-informed about the budget.

Predict The Unpreditctable

What I’ve learned from my experience is that it’s worthwhile to think about possible risks in the time between design and development on the product timeline. It often involves getting everyone around the table and a thorough discussion with the client’s representatives and all team members about what may go wrong. Not today, not tomorrow, but even in a few months. It’s not a very comfortable moment, especially for the client, when we’re talking about things that may break in the process and — believe me — there will be many of them, but we also want the client to realize that when we have the discussion now, we’d probably won’t need it in the future. 

As Murphy’s laws says: if something can go wrong, it will go wrong and in the worst possible way, but identifying risks before they happen and creating a well-considered fix plan for critical issues that may occur, significantly reduces the fixing time and reduces the stress. But remember: always expect the unexpected. You won’t prevent it, but you may be prepared.

Let Me Be Your Guide

A key role in project management is being a leader. This position involves not just maintaining proper momentum of the development team and keeping them well motivated. It’s also all about keeping the proper balance between the team and the client’s needs.

This part is actually the thing that excites me the most about being a PM. It’s like being a link in the chain, like a translator at the UN conference. You take one sentence from the client and translate it to the mythical language of devs. You take the reply and translate it from Klingon to Human speech.

This is why I think PMs shouldn’t be solely a developer / architect nor an entrepreneur / business analyst, but should combine abilities from these two, seemingly contrary, fields of expertise. Only then can a PM maintain proper equilibrium and understanding.

As a leader, sometimes you need to be a guide for your team, sometimes a mentor, sometimes a boss and sometimes a jester to relieve the stress. You need to take your team through the dangerous paths full of unexpected obstacles and difficulties. You need to cheer them up in the hard times and give them a break when the situation is getting more calm. It’s not easy, but if you have proper leadership skills, the team will accept you as their guide and will trust that even in the most dangerous journey they will stay unharmed.

Be Proud Of What You Make

This one is very simple. Just deliver clients delight. It’s not enough for us to simply know that we followed the requirements and created the product accordingly to the specifications. Until we deliver anything, we need to be 100% sure that the product we’re giving away to the client is a thing we’d like to use personally, that the product it’s something we’re proud off. And — believe me — our expectations for quality are very high.

Obviously this is not a full guide of “How to be a good Project Manager,” but the points above cover the things that I consider the most important, the lack of which will most threaten the success of the any project you may have the chance to work on.