Have you ever started a project when you felt that it’s not planned carefully and you were just waiting for something to go wrong? Key analyst gets sick, lead developer has to work on another project, everyone needs to wait one week for the server to get set up. Or maybe the data from the old system is corrupt which will push the deadline ANOTHER week…
Another scenario is when you’re in the middle of a big project that’s key to the organization and it seems that everything is according to plan – milestones are delivered within deadlines and budget is met…All is well until you try to deploy it and then things get late, over budget, or the software doesn’t do what the users want to…
In this article, you’ll learn about different methods of planning.
As a result:
- you’ll be prepared for 99% of possible disasters and have a backup plan so that you can still deliver the project within time and budget
- you’ll actually know exactly where you are with the project and have more control over it
Project planning survey
We ran a webinar: “7 ways your Cold Fusion project can fail and what you can do to avoid them”
We sent out a survey to the participants (mostly developers) asking them “what planning is done on your project?” The following graph shows the results:
Many software teams do task lists and estimates. But very few people do risk analysis, look at dependencies or resource allocation.
In this article, I will go over each of those planning methods, explain why they are important and how to put them into practice.
Why it’s important:
If you don’t keep track of who’s going to be working on what and when all kinds of unexpected issues can come up.
Tracking all your people resources will be useful. Just imagine you will know ahead of time if certain developers are busy with other projects or on vacation just when you need them. You’ll be able to see if anyone got an unrealistically large amount of work.
In a company we worked with, the key analyst was called for jury duty. Another time we had to do some change to the database and the database analyst was on vacation. As a result, the whole project was postponed a week.
A spreadsheet of hours assigned to each person and project is enough for small projects (less than a man-year) or you can even use a whiteboard.
In larger projects, software like MS Project will track resource allocation. Don’t forget to track key client people and DBAs or beta testers.
Track not only human resources
You might need to prepare budget or calendar for physical resources. This concerns servers for load testing, disk space for test data or special equipment or rooms for usability testing.
How do you start?
Identify key people resources: database person, testers, developers, project manager, analysts. Then identify how much time they have and what other projects they’re working on.
- Think about unrealistic expectations – how many hours someone would work on each project, if he is a full time employee. This usually means they have less than 40 hours because of all meetings, etc.
- Urgent needs come up: people can get sick, have jury duty.
- Too much work for senior developers and other specialists. They work on multiple projects which most often means they’re the project bottleneck because they’re maxed out.
To sum up:
Resource allocation is about juggling key resources between projects. This way you make sure all the projects can move forward.
On a deeper level, you might see why some developers or other resources are very popular for different projects and others are not- find gaps in your team skillset so that you can improve that.