Management of Software Projects: General Guidelines

Over the years I have been fortunate (and unfortunate) to have worked under a variety of project managers. Additionally, I have performed the roles of a technical lead and a project manager.

Here, I do not go into the finer aspects of management of a software project, but rather, emphasise the human element of leadership. In fact, the best book on leadership I have ever read is Steel My Soldier's Hearts, by Colonel David H. Hackworth (and his wife, Elihys England). This book definitely demonstrates how to lead, and has lessons that can be applied to any leadership position.

This post is not a summary of Hack's ideas (read the book--it's fantastic); but his work inspired some of the bullets below.

When in a leadership position, whether it be as a technical lead or project manager (or both), it is best to follow these guidelines:
  • Lead by example and lead from the front. You should be able to jump in and help with the actual work, if needed. You do not need to know all aspects of the domain of a problem, or how to do everything with a given framework, API, or language, but you should be able to function as an actual member of the development team. Because of all this, you should have the same IDE, build tools, version control client, developer system accounts, etc, as the rest of the development team. Be on top of what is being done--attempt to do builds of each iteration. Make sure that you monitor what goes into source control (either by watching the logs or by receiving email updates).
  • Appear serious most of the time. Especially in the beginning, when people are just starting to get to know you. Having a serious, intense look, but not angry or nervous-looking, will help people to take you seriously. Then, later on, if you smile or laugh at a joke, they will feel pleased that you have a "fun" side, too. But if you are smiley and happy from the start, they might not take you so seriously. A lot of leadership involves good showmanship.
  • Be friendly, but do not fraternise. Whilst being serious most of the time, you can still be friendly, just do not try to be close friends with your subordinates. Avoid going out drinking with them. Do not appear to be friendlier to one over another.
  • Do not assume that most tasks can be simply broken down into smaller subtasks in the form of steps. Some managers make this mistake in thinking that everything is done sequentially, and can be put into clearly defined steps. Some complex problems instead require parallel efforts and re-iterative techniques.
  • Take care of EVERY individual on your team. Make sure everyone has all the tools they need to get the job done. Make sure everyone has a functioning workstation and functioning accounts. Also, make sure everyone has equal access to equally good tools. If you have something someone needs, and you do not require it yourself, be willing to swap theirs with yours. For example, if your subordinate has a problematic monitor, and the company has none available to replace the monitor, then swap the monitor with your own. You should be like the general with shiny new boots who swaps his boots with the corporal who has worn-out boots with holes. Make sure everyone has an adequately comfortable work environment. Pay attention to every individual's complaints. Just because the rest of the team may not be complaining, does not mean that it's just one person with a problem; many are reluctant to speak up. So at EVERY meeting, ask everyone if they have what they need--do they need any extra tools to get the job done; are their workstations functioning adequately.
  • Treat every individual on the team with dignity. Treat everyone as you would want to be treated. Never ridicule, insult, or shout at anyone. Do not be condescending. Never suggest or imply to an individual that they "might be better doing something else, like [fill in the blank with a role that is lesser than the person's title]". If they are unhappy, it might very well be because you are not giving them suitable opportunities.
  • Use POSITIVE reinforcement and praise your subordinates FREQUENTLY. As an owner of several canines over the years, I have learned a lot about positive reinforcement. Workers are like dogs who love to be praised. You can get them to leap through hoops if you give them encouragement. Then, when they are being difficult, you can surprise them with a very stern voice and get their attention.
  • Never show favouritism. Do not take only certain subordinates out to lunch, or only invite select individuals to sit with at lunch. Also, if you do take the whole team out for a meal, make sure you attempt to accommodate the dietary restrictions of the individuals (some cannot enjoy alcohol, or eat anything that simply was cooked on the same surface as an "unclean" food). Do not ignore the fact that one team member might have lesser tools than another; make sure that the poorer one is brought up to the same level of toolsets.
  • Teach whatever needs to be taught, and more. Any good leader must be a teacher, too. You should be able to show anyone on the team how to do what must be done, or at least point them in the right direction. The managers or leads that say things like "I don't want to have to babysit" so-and-so; or, "I shouldn't have to spoon-feed" so-and-so, are fools that have no business occupying a leadership position. If you do not know how to teach the topic that needs teaching, you should at the very least link up the individual with someone who can show them the way. EVERY manager should be a good teacher. If you refuse to do this, then you should get out of IT project management.
  • Do not let anyone on your team just fail. That is, do not let them drown if they are struggling. Do not have the attitude of "sink or swim". If someone is failing, and yet they are trying to give a good and honest effort, then you need to show them the right way to get the job done. If anyone should have to stay late or come in on a weekend, it is the project manager--the manager was supposed to ensure that the tasks could be accomplished within normal business days (8 hours of work per business day, in most of North America).
  • Get rid of cubicle walls, if at all possible. Few things are as irritating as hearing someone near you, but not being able to see them. People should feel comfortable and confident about approaching other members of their team.
  • Avoid crass or disgusting habits. Such as: sitting on other's desks, using your saliva to clean off your keyboard, flossing at your desk, picking at your toes, etc. Practise good hygiene.


Diagram of Skills: Perfect for IT Interviews

In addition to the typical CV/résumé for an IT interview, it might be helpful to the prospective employer to see a concise page displaying the candidate's skills. Because many of us who have been in the IT field for several years have very long lists of programming languages, frameworks, tools, IDEs, APIs, etc, that we have worked with, it might be helpful to break out the skills into separate categories. Better yet, instead of just listing them on a page, why not make a diagram? Here is a simple example:

Such a diagram can be saved to a PDF, then emailed to prospective employers or distributed at interviews.