10 Basics of Project Management

By Olga Sa

I would like to share 10 basic tips from my own experience in project management that might help people new to the profession.
Always keep the constraints of your project at the top of your mind.

Any meeting that you are in, internal or external, every phone conversation you are having with the client, a hallway chat with a team member - you must know the project constraints: scope, time, budget, quality, risks, and reference any new information against these. The reason this is important is that if the client mentions a potential small delay for a relatively simple deliverable, you must do a quick mental check against the project constraints to assess potential impact. If a team member comes up to you to discuss an approach for the development of a relatively simple feature, you must reference their proposed implementation method against the constraints and raise a “pink” flag if you see any potential issues. It can be as simple as someone asking for a day off two months in advance. You agree and then a week prior to the date realize that is your code review date! Of course it is not possible to remember complete schedule for a long term project so at least make a mental note and double check when you get back to your desk.

Always know the details of: Deliverables, Milestone Dates, Financial Forecast, Dependencies.

Similar to Point 1, this will help you stay on top of the project in casual discussions and foresee any issues ahead of time. You are the closest person to the client and know what is expected. The team is often not aware of the smallest details and it is your job to communicate those. If you are delivering a piece of documentation, don’t expect the team to read your mind, repeat and reinforce any special requirements the client is expecting. Keep the milestone dates visible to the team and the client at all times. Don’t expect the team to reference the timeline you sent them in the beginning of the project. Remind them of the milestone schedule on weekly/daily basis.

Be nice but firm.

This is a personality thing. I am a nice quiet person when it comes to my personal life. However, this is business. If the situation demands it, you must decline family vacation and ask the team to work overtime. Be nice about it, buy the team working overtime dinner, but be firm, they are not doing it for you personally. If there is a performance issue and you have spoken to the team member about it more than once but don’t see any improvement - escalate. Again, this is not about you pointing fingers, it is about running a successful project.

Always document the project requirements.

You may call it a scope document or feature backlog etc. Whatever it is, make sure you track every requested feature all in one place. Annotated wireframes are not the best place. You need a list of smallest features and tasks required to be performed. Especially note down vague requirements, tiniest details or obscure aspects that are hard to quantify. Those are most likely to slip everyone’s mind. Alternate states, error messages, etc. Ask the technical team to help you brainstorm any possible requirements or questions that UX/Design team did not cover.

Organize the file repository.

Implement a good version tracking system and use it! Then, if something was approved - move it into the separate folder. Archive the rest. A new person will come on board and all this great common sense method you have going will make absolutely no sense to them.

Communicate often and right away.

This is one of the most important, most repeated points. Don’t underestimate the importance of communicating the smallest detail. Don’t jump the gun and send client unverified information. Don’t spam. Don’t sit on the bad news for a day either.

Trust but double check.

This is especially true for timesheets and deliverables. Everyone hates timesheets, it is one of the main reason why people fudge their time on them. Unfortunately this doesn’t help your reporting. Be nice but firm about keeping the timesheets real.

Check everything before sending it to the client. Spelling, file names, dates - everything! You are the last person the files go through and any mistake will make you look bad. Yes, PM = QA.

Update your financial forecasts weekly.

This way you will see the first signs of discrepancy in the forecast at completion and will be able to notify client early on before it bubbles into a significant number.

Feedback frequency controls stability.

This is something I learned from engineers and also on my own skin. It is a rule of thumb, if you do not hear from your client for a while, the project is going to have issues. Too in/frequent communication will cause problems. Find a healthy middle for your project and stick to it. For financial communication weekly call can be sufficient. During UAT period, you may want to ask the client to send you spreadsheet with issues daily.

Share your experience with other project managers.

You may think that the problem you are experiencing is unique and embarrassing because you should have known better. Chances are your colleague had the same or similar issue. Find out how they dealt with it and figure out what to do yourself. Do not work in silo, it is harder to succeed in this profession if you do that.