Top-Ten List of Tips and Suggestions for Effective Software Project Management
Contrary to popular belief, there is no special trick or secret to successful software project management. Just like any other software-related task, be it development, testing or support, project management requires some knowledge and experience, and a willingness to apply the required effort. So why is it that software project management has gotten such a bad rap? One reason is that project mismanagement gets the brunt of the blame for the many software projects that do indeed fail. Another reason is that often software developers – with little or no preparation – are promoted to managerial roles. While it certainly helps for a software project manager to have a healthy background in software development, the basic skill-sets and aptitudes required for these two tasks are very different.
Making the Transition
I come from a software development background and have been doing software project management for a decade now. This transition has not always been easy. Probably the biggest conceptual challenge I had to face was assuming personal responsibility for code written by others – developers that are often less experienced or proficient than I am. My instinctive reaction to this was to try to get directly involve in every aspect of the projects’ development process. I learned to resist this urge because it would have made me a bottleneck and would have practically guarantees that the projects would not be completed on schedule. Also, developers hate to be micromanaged in this way, so it would have created a lot of friction within the team. I learned to trust my team, and in some cases transform it into a team I could trust, and to set up the appropriate checks and balances to identify and correct mistakes early enough in a project’s life-cycle.
Based on my own experience as a manager and the books and articles I’ve read on the subject, as well as the presentations I’ve attended and webcasts I’ve listened to, I’ve come up with a personal “Top Ten” list of tips and suggestions for effective software project management. This list is by no means exhaustive or conclusive – I’ve intentionally kept it short and succinct. It is also no substitute for actual study and experience but it should help get you on your way managing projects. Certainly if you are managing software projects and you are not familiar with all of these items then your processes are lacking.
- Research and preparation – make sure you understand the problem domain, either through personal research or by consulting with experts in the field. I highly recommend consulting with experienced enterprise/system architects. I’ve learned more about a specific problem domain from one excellent enterprise architect than from all the books and articles I’ve read on the subject.
- Planning and organization – gather the requirements, write them down and keep that document up-to-date. Then make sure everybody involved in the project reads it and understands it. If it all possible, get the stakeholder to sign off on it. Even if you can’t achieve either of these goals, this process is still worthwhile because this document will help you to stay on track. Pay special attention to requirements having to do with security, performance, and internationalization as these are difficult to tack on at a late stage.
- Simplicity and completeness – I’ve already written about the importance of the KISS principle. Create the simplest Functional Specification that satisfies the requirements. Then create the simplest Technical Specification for that functional specification. Well documented header files, interface definitions and schemas can be sufficient technical specifications. Finally, create the simplest working implementation of that technical specification. Do beware of oversimplification – your requirements document should help you out here.
- Tracking and management – use project management and issue (bug), tracking software. Even if your project is small or your budget is tight, there are solutions out there that can fit your needs. Enforce the rule that developers cannot move on toward developing new features until they have addressed all their existing open, unresolved issues. Beware of bottlenecks. Especially beware of becoming one yourself.
- People and tools – make sure you have sufficient and appropriate personnel and that they have the tools they need to perform their tasks. Skimping on either will end up costing you much more in the long run. Take into account that a single good developer is more useful and cost-effective than several mediocre developers. At the same time, good developers who lack the appropriate tools to do their job will become frustrated and unproductive. If you are unable to obtain the personnel and tools required to successfully complete the project, raise a red flag to your managers as early as possible.
- Goals and accountability – set for yourself, and for everybody on your team, goals that are challenging but achievable. Do this together and let your team members set their own timeframes if possible. This will induce them to become accountable for their goals and commitments. You need to be knowledgeable enough to recognize inflated timeframes. At the same time, you need to help inexperienced team members avoid setting themselves up for failure with unrealistic schedules.
- Milestones and benchmarks – use milestones to break a lengthy project into manageable parts. Specify benchmarks for each milestone so that you will be able to determine conclusively if you have achieved that milestone or not. The entire team must be familiar with both the milestones and the benchmarks. Milestones should be defined in such a way that each milestone is a prerequisite for the next one. This means that you will not be able to skip milestones for expediency.
- Meetings and triages – conduct daily status meetings, preferably in the morning, to identify roadblock and bottlenecks. Keeps these meetings short. If they start getting too long, do them standing up (similar to the Agile Daily Stand-up Meetings but not necessarily with the entire staff all the time.), Similarly when approaching a milestone deadline conduct triage meetings to identify which issues must be resolved to meet the deadline and which issues can be postponed to a later stage.
- Priorities and timeframes – don’t waste time looking for perfect solutions, go with solutions that are good enough. Remember that there will almost always be a next version, and some issues do not need to be fully addressed in the current version. Also remember that resolving issues always has cost, and in some cases the cost can exceed the benefits. This is especially true for changes applied at the last minute.
- Learn and reuse – solving a difficult problem once is essential complexity. Solving the same problem twice is accidental complexity. Do your best to promote reuse of existing knowledge and solutions in order to avoid redoing work. If appropriate third-party solutions exist, use them (see reference to proper tools above),. And always remember: Google is Your Friend. Also, conduct project post-mortems so that you can do a better job next time.
This is, of course, just the very small tip of a huge iceberg. Lots of software project management books have been written over the years, and I recommend reading several of them (for example these),. Hopefully my list will help you out while you are doing that.