>Lessons for Budding Project Managers

>

Over the past many years, I have worked with numerous project managers and team leads. Some of them were really great and I learned a lot from them. However, others suffer from what I call, “Jaldi kya hay” syndrome and usually are below par at their performance. They tend to make the most common mistakes one can think of and yet do not see anything wrong in doing so.

So for all those budding project managers, I have put together a list of things to be mindful of. Use it as a guide and as your rule in your organizations.

Martial your solders: Have the whole team involved during any major project, especially during the critical days before the release of any software product. And if you find someone sitting idle and not doing any task, assign them something to do. For example, let them do research on a particular topic. It is better than doing nothing.

Delegate Responsibility: The bulk of the work should be done by the team members hired to do the job. Many managers think they are better software engineers than their team members, therefore end up doing last minute work themselves by pulling all nighters. If the manager is doing it, then what is the purpose of the rest of the team? It cannot be emphasized enough that this is not your job description to code, rather you are expected to manage and coordinate with the team and get them to deliver the tasks at hand. If you believe that the current team members cannot deliver, then you must also consider the fact that you have hired the wrong people. Therefore, learn to delegate or let them go.

Plan ahead: There could be a time, when certain team members take short leave or call in sick at the critical juncture of the project. Unfortunately for you, the client does not care about that. Therefore, plan ahead and let the team know that they must be present to meet the deadline. Send them a car (or a taxi) to pick them up if they cannot come to the office for some odd reason, treat them to a lunch/dinner if they sit late or come over the weekend or whatever in your power to keep them motivated enough to get the work done on schedule. Otherwise, it is your neck on the line, not some junior programmer’s. Also make sure that the team knows the deadline schedule clearly. Post it on their notice/electronic board or send them an email reminder. Just make sure that they know it that they cannot miss the deadline and it should definitely not be something they find out at the last minute. Learn to plan ahead and monitor the progress.

Learn the art of transitioning: There will be times when certain team members are moving out (quiting the team) or moving into the team (joining the team). Make sure you have a plan to manage this transition, especially during a major launch phase. All assignments have to be done before such a transition can take place. And if that is not possible, then make sure that there is ample time spent by the outgoing person with the new team member (replacing him/her) in passing on the knowledge. Creating an excuse for not doing work because you did not have the right resources will not win any sympathy from anyone. Not even your boss let alone the client. Therefore, learn to transition between players especially during tight deadlines.

Manage time: Do not schedule any unwarranted meetings when you have a major launch pending. If you cannot allocate time for the most critical project that you are managing, certainly, your team will never make time for it either. Use project management softwares and other similar tools more diligently. If you are not going to use them to assign and manage tasks, the team will never use them either to manage their tasks.

Be Stern and Strict: There is no free lunch, especially in a deadline oriented software company. The whole team should be there taking it as seriously as you are. It is not really worth the effort if two people out of twenty work while the rest take it easy. Learn to be stern and strict but gentle at the same time.

Grade with a Teacher’s eye: The work performed by the team needs to be graded, bullet by bullet and point by point as defined and agreed when assigning tasks. As a manager, you should focus on making sure that the team does what it is assigned and does not do what it wants and when it wants.

Do one thing, but do it right: In a typical software house, one will find the team doing a lot of work. However, if the manager is not careful, then the team will do work in a disjointed fashion, using different servers/platforms, messed up coding techniques and half hearted attempt at meeting client requirements which they poorly understand or visualize. There is no point in showing the client 500 hours of work that makes no sense and nothing seems to be totally complete or working properly. Five hours of focused work that meets all requirements for a particular sub task is much much better and appreciated by everyone. Make your team start one thing/task and make them finish it properly before they move to the next task. Learn to focus on the task at hand, and your results will improve dramatically.

Murphy’s Law: During a major release, what can go wrong will go wrong. There is no question about it. The server will crash, the software versions will be incompatible, the libraries will be missing on the deployment machines, the code will not run on deployment server and so on and so forth. Therefore, anticipate ahead and expect the unexpected to happen. Test everything in advance, try things out differently and have a fully functional version running on a mirror machine somewhere. The client will not care about new issues that popped up right there and then. They only care about work done on time and on schedule. So no amount of excuses will get their confidence back.

It is not done, till it is actually done: Never claim that it can be done in a few hours without first analyzing the problem at hand based on the available resources. Sometimes, working on a few simple pages could take dozens of hours to code. It could be the complexity of the problem, or the team could be stuck on some software bug. Therefore, never commit or claim it is complete or you can do it in so many hours/days till you have thoroughly discussed the problem with the team and your client.

Communications 101: This cannot be emphasized enough. Sometimes, managers are shy of speaking to their customers or even communicating with their team members. At other times, they simply never inform anyone, including their bosses, the issues they are facing or progress they are not making. It could be lack of resources, or even lack of time to solve a certain problem. In short, inability to share information and keeping everyone abreast of the latest development could mean disaster. When everything is honky dory, no one notices and all is well, but when things begin to go bad, then everyone starts pointing fingers. And when something does go wrong seriously, and the client and your boss find out the hard way (missed deadlines, angry client, etc) your neck will be on the line. So make sure that any news, especially bad, that comes out regarding the project, comes from your mouth.

Advertisements

About Atif Mumtaz
A serial entrepreneur who loves to travel, discuss politics and hikes on weekends.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: