Though management is a skill which is generally considered as a generic skill through which a manager gets the job done by a group of people (though it is preferable to have a team rather than a group of people but I don't want to go into that debate on what makes a group of people "a team" and saving that discussion for future discussion) but there's a subtle (sometime, not so subtle) differences in managing a team to accomplish a software development project compare to a non-software development project in Information Technology.
Sometime what you learn in school of management doesn't always fit to the specific work environment you are in. Here I am summarizing some of the practices that I found very useful, specially, when I applied them in my area of work. You may treat them as best practices or as thumb rules and these would be very helpful if you managed non-software project but would like to have the transition to the software development field or you just have started managing a software development project.
1. Any issue or questions from the Development team and business users should be documented in some forms of register. Without this there is high chance that you'll loose track of issues and queries and eventually would be dropped off of the final software deliveries - it is a "must have" when you work with geographically distributed team.
2. Always keep the delivery schedule in front of your eyes (literally like hanging the schedule on the wall of your cubicle or office) with minimum information such as the delivery date and/or possibly with the features to be delivered on the targeted date. Again, use the reference number to trace the requirements
3. Always assign number (or ID) to the user requirements and features. You can use any format ranging from word document to excel file or just a text file but each piece of the requirements should be referenced to a number for traceability purpose
4. Make sure you track the changes (it comes as a feature if you use Microsoft Word) of the the requirements and scope of works, or at least track the changes from the base requirements through highlighting the delta. This will reduce the frustration from fishing for a small changes within a large text document more over it will reduce the chance of missing out the subtle changes in requirement and as well as dropping in the actual implementation
5. You should never set priorities of a feature and, even if you have that in your mind, never mention it to users before user expresses their need/want. This is something you don't intercept - keep it with users.You can negotiate with the date later on once user put the date on the table
6. Keep versions of each and everything the team produces - from simple document (e.g. manual, requirement, design artifacts etc.) to the software itself. For documents, keeping the version histories is a must that should include track changes, the summary of changes, who has updated it and when it was updated for each of the version update. For software and software package make sure to give a version number. This will pay you off down the road, could be after few years but it will save you from a potential disaster
7. Never compromises with the IT Security e.g. access management, put control on code review, loophole in code etc. If you need to compromise it due to a VERY high priority business case, get back to the process soon after that need is met. Otherwise you will put yourself in unnecessary troubles. It also shows your maturity in management
8. When you are talking about deadline with the development team, ask them for the date and negotiate it from their. Try to give them the date developers asked for. Developers take the responsibility of their given deadline. But make sure when you review the status and if they're lagging, never ask them when they can complete it rather, this time, you tell them the date.
9. Measure the completion of tasks numerically. Never take the development status as near completion, almost done, should be done in couple of hours etc. Just ask the the percent of work left
10. Have One-on-One session with all the member of your team. This is very helpful to get to know lot of internals that you otherwise would never get. You should ask at least 3 questions in that meeting - (a) what do you think about your performance and what you could do more; (b) What do you think we should do to improve the team's performance and (c) Open up yourself of anything related or unrelated to work
11. Measure the performance of the team and individuals quantitatively using consistent metrics. Have 360 degree evaluation if feasible
12. Clarify the meaning of any apparently simple word that might have multiple meanings which would have critical or adverse effect on your project deadline. For instance, when a developer tells you that she's going to "reuse" an existing piece of code, don't be shy to ask to explain the word "reuse". This seemingly obvious word caused one of my project to be delayed by five (5) months where the developers meant "copy the code to the new module and modify it for the purpose of the new module" whereas I assumed the literal meaning of that which was "reuse the existing code from the existing module while refactoring the code to meet both modules' need". Sometime the words - "it doesn't work" could have two meanings. One is "it doesn't give out the result as expected" and the other is "it is actually broken or it bombs"
13. Programmers take pride of what they do so don't offend them with your knowledge or or with your idea specially if it's half baked. Brainstorm with the team to come up with solutions and participate with the team not as a boss. The creativity stops sprouting when the boss is in the conference room with an attitude of bossing around. Yes, you've to take the call to stop at a point where the discussion turns into argument (yes that's very common in software development world) but do it without offending one over other
14. This kind of goes against the current stream - Never call the programmers as a "resource". This offends the very nature of humanity (and programmers are human at work). I also have seen where managers call them as "body" like "I need three more bodies for my project". It's very subtle and often the person who you're referring to may not even notice that but eventually it has profound impact on your behavior on how you would treat a member of your team. Treat them as human and I would strongly stand with the fact that the programmers are actually more emotional compare with people of other industries
15. Recognize the excellent performance of individual member of your team. There's a debate on where you should single out a person to reward or recognize and I agree that there's pros and cons of that as it may go against the spirit of team work. But I prefer to recognize a best performer of your team while keeping the team spirit as one of the criteria to select one. It's like mixing of Socialism with Capitalism where you create the sense of common ownership but also reward individuals for their extra mile run that goes beyond the set expectation
16. Remember Newton's first Law of Motion: An object at rest stays at rest and an object in motion stays in motion. Same is true for your team that you manage or lead. If the team is in a habit of failing the deadlines, they would keep it like that until you force it to turn around. So, make sure that every tiny little milestones, deliveries or commitments are met. If you think a deadline won't work, reset it early enough (but don't wait for it to fail). Once your team is in meeting their commitments mode, you can relieve the pressure but keep the monitoring in place so that the hard earned team's state doesn't get rusty
Sometime what you learn in school of management doesn't always fit to the specific work environment you are in. Here I am summarizing some of the practices that I found very useful, specially, when I applied them in my area of work. You may treat them as best practices or as thumb rules and these would be very helpful if you managed non-software project but would like to have the transition to the software development field or you just have started managing a software development project.
1. Any issue or questions from the Development team and business users should be documented in some forms of register. Without this there is high chance that you'll loose track of issues and queries and eventually would be dropped off of the final software deliveries - it is a "must have" when you work with geographically distributed team.
2. Always keep the delivery schedule in front of your eyes (literally like hanging the schedule on the wall of your cubicle or office) with minimum information such as the delivery date and/or possibly with the features to be delivered on the targeted date. Again, use the reference number to trace the requirements
3. Always assign number (or ID) to the user requirements and features. You can use any format ranging from word document to excel file or just a text file but each piece of the requirements should be referenced to a number for traceability purpose
4. Make sure you track the changes (it comes as a feature if you use Microsoft Word) of the the requirements and scope of works, or at least track the changes from the base requirements through highlighting the delta. This will reduce the frustration from fishing for a small changes within a large text document more over it will reduce the chance of missing out the subtle changes in requirement and as well as dropping in the actual implementation
5. You should never set priorities of a feature and, even if you have that in your mind, never mention it to users before user expresses their need/want. This is something you don't intercept - keep it with users.You can negotiate with the date later on once user put the date on the table
6. Keep versions of each and everything the team produces - from simple document (e.g. manual, requirement, design artifacts etc.) to the software itself. For documents, keeping the version histories is a must that should include track changes, the summary of changes, who has updated it and when it was updated for each of the version update. For software and software package make sure to give a version number. This will pay you off down the road, could be after few years but it will save you from a potential disaster
7. Never compromises with the IT Security e.g. access management, put control on code review, loophole in code etc. If you need to compromise it due to a VERY high priority business case, get back to the process soon after that need is met. Otherwise you will put yourself in unnecessary troubles. It also shows your maturity in management
8. When you are talking about deadline with the development team, ask them for the date and negotiate it from their. Try to give them the date developers asked for. Developers take the responsibility of their given deadline. But make sure when you review the status and if they're lagging, never ask them when they can complete it rather, this time, you tell them the date.
9. Measure the completion of tasks numerically. Never take the development status as near completion, almost done, should be done in couple of hours etc. Just ask the the percent of work left
10. Have One-on-One session with all the member of your team. This is very helpful to get to know lot of internals that you otherwise would never get. You should ask at least 3 questions in that meeting - (a) what do you think about your performance and what you could do more; (b) What do you think we should do to improve the team's performance and (c) Open up yourself of anything related or unrelated to work
11. Measure the performance of the team and individuals quantitatively using consistent metrics. Have 360 degree evaluation if feasible
12. Clarify the meaning of any apparently simple word that might have multiple meanings which would have critical or adverse effect on your project deadline. For instance, when a developer tells you that she's going to "reuse" an existing piece of code, don't be shy to ask to explain the word "reuse". This seemingly obvious word caused one of my project to be delayed by five (5) months where the developers meant "copy the code to the new module and modify it for the purpose of the new module" whereas I assumed the literal meaning of that which was "reuse the existing code from the existing module while refactoring the code to meet both modules' need". Sometime the words - "it doesn't work" could have two meanings. One is "it doesn't give out the result as expected" and the other is "it is actually broken or it bombs"
13. Programmers take pride of what they do so don't offend them with your knowledge or or with your idea specially if it's half baked. Brainstorm with the team to come up with solutions and participate with the team not as a boss. The creativity stops sprouting when the boss is in the conference room with an attitude of bossing around. Yes, you've to take the call to stop at a point where the discussion turns into argument (yes that's very common in software development world) but do it without offending one over other
14. This kind of goes against the current stream - Never call the programmers as a "resource". This offends the very nature of humanity (and programmers are human at work). I also have seen where managers call them as "body" like "I need three more bodies for my project". It's very subtle and often the person who you're referring to may not even notice that but eventually it has profound impact on your behavior on how you would treat a member of your team. Treat them as human and I would strongly stand with the fact that the programmers are actually more emotional compare with people of other industries
15. Recognize the excellent performance of individual member of your team. There's a debate on where you should single out a person to reward or recognize and I agree that there's pros and cons of that as it may go against the spirit of team work. But I prefer to recognize a best performer of your team while keeping the team spirit as one of the criteria to select one. It's like mixing of Socialism with Capitalism where you create the sense of common ownership but also reward individuals for their extra mile run that goes beyond the set expectation
16. Remember Newton's first Law of Motion: An object at rest stays at rest and an object in motion stays in motion. Same is true for your team that you manage or lead. If the team is in a habit of failing the deadlines, they would keep it like that until you force it to turn around. So, make sure that every tiny little milestones, deliveries or commitments are met. If you think a deadline won't work, reset it early enough (but don't wait for it to fail). Once your team is in meeting their commitments mode, you can relieve the pressure but keep the monitoring in place so that the hard earned team's state doesn't get rusty
