When you are planning and also managing a software project there are hundreds (if not thousands) of different software products you can use to utilize and enhance your processes. I often ask my self if these products are really helping me or if they are actually more an obstacle. My largest issue with using software for all your process is that the software forces you to think and work in a manner that suites the software. Your mindset will quickly be limited to the available functionality.
We have all kind of different software that is widely used in software projects:
Every software projects have documents and most likely tons of them. You have specification docs, system docs, design docs, architecture docs and other documents describing the system. These are often large documents written in word and takes a lot of time to keep updated. What you often see is that at one point in the project you just give up having all these documents updated with changes and adjustments.
Spreadsheets are also widely used for project plans, budgets, resources, work break down and so on.
You often see that every project has it’s own regime for documents, format, templates and how this is done. You will also see that these documents exists in several different versions located in some kind of document sharing tool like Sharepoint.
Every project needs some leading documents but I think you should try to keep the number of different documents to a minimum. The documents should also be very concise and only contain important information. I often see that documents are written just so that you can say that your system have good documentation… In my opinion that is just a waste of time and a source to confusion.
This is were you start walking into the jungle of different products. For modeling and diagrams you have for example Microsoft Visio, Magic Draw, Enterprise Architect (my personal favorite) and many many more. You should be careful on how you use these programs and before you start drawing a diagram think about if you need to keep this diagram as documentation or if you maybe just should sketch it on a piece of paper or on a white board. Most of the projects will only need a few different UML diagrams.
There are also software that helps you manage, map and maintain requirements, user stories and use cases. In large complex projects with a lot of requirements leading to a large number of user stories and use cases tools like this can be a good thing but on smaller projects I will recommend to keep it simple and outside these kinds of tools. I have used Case Complete for this and is satisfied with this product. I also like the ability to configure Case Complete to run shared projects from for example a SVN repository.
When you come to managing the project, processes, plans, deadlines and so on you also walk into a jungle of products. You have many products for managing agile projects (for example ScrumWorks and JiRA with GreenHopper).
There are also several products for creating project plans and manage these.
My concern for projects that are to tight coupled with different tools is that the project will have to adapt to the tool. You will never find a tool that suites all your needs, you always need to compromise and chose the one that best matches your needs. What I am really trying to say here is that just because there exists tools for what you are about to do that doesn’t mean that the tools automatically will make the job easier and the result better. Before you start using a software tool you should spend a moment considering if you really need this tool in your project. I often find that the good old way by sketching/writing on a paper, post-it or white board still is the best way to achieve your goals. You can take some of the money saved on not using software tools and invest in some additional white boards.
I think that in an environment involved in software projects the walls should be filled with white boards and post-it boards.