Does It All Lead Back to MS Project?
If you’ve worked on a software development project, there is a good chance you’ve either used or done everything to avoid using Microsoft Project. I avoid MS Project when I can and have developed my own Excel-centric task management system. However, as my system grows to meet the needs of my projects it is eerily converging on Project itself. Is there any escape or I am bound to run so far away from Project that I run right back into it again?
A complete project in MS Project is in many ways a thing of beauty to behold. Tasks are joined to resources, timelines and other tasks as dependencies. You can adjust someone’s allocation and watch the timeline warp and wriggle in response. You also have the comfort of being able to produce solid, comforting diagrams which show your progress and plans to your non-Project blessed co-workers. Then your project moves along just as you planned, with satisfying milestones along the way to the anticipated successful solution.
With these happy sentiments in mind, why did I spin up my own system for task management and project planning? There are 2 major problems I see with Project, the “buy-in” cost and adaptability. Buy-in cost is the amount of time and effort it takes to get your project into MS Project. Project planning is important, but the mechanics of entering your tasks, setting up resources and linking up dependencies is quite clumsy. By itself however, the buy-in cost would be a reasonable investment if it were not for the second major problem with Project, adaptability.
Changing out resources, redefining tasks and dependencies, adding or deleting entire chains of tasks happens all the time during projects, yet represent great pain points in Project. I remember a specific project I was on where a failed attempt to change a few dependencies cost my project manager literally days to recover from.
Beyond changes to the project itself, Project is restrained in the meta and supporting information you can easily attach to tasks. If you really dig into Project, you can set a lot of this up, but again, based on past experiences, Project does not end up being the definitive source of information about a task. So you have other documents, spreadsheets, etc. which all then try to refer to the tasks in Project, leading to synchronization head-aches and disconnects.
One possible answer to these problems is to spend the time to really learn Project, to deep dive into it and hope to mediate the pain points with your newfound guru status. However, at this point you are likely to be stuck (consciously or not) running your actual project in such a way that matches up with the constraints (and capabilities) of your project management tool.
To avoid this inversion of priorities, I have been experimenting with my own system of task management and project planning. The foundation of my system is Excel and so far it is quite primitive in comparison with Project. Nevertheless, I have enjoyed growing my system to create capabilities I find lacking, rather than growing my project to use capabilities I received by default.
I haven’t had to test how my system scales to a large project yet, but even with a small to medium sized project, I do look at parts of Project with envy. I have to laugh when I see my spreadsheet layout inching closer and closer to a Project style look. While MS Project is over weight for my current purposes, it was not developed out of the blue, but in response to certain scenarios that occur while on a project. The problem lies in trying to solve every one of these at once and in the process making solving any of them individually that much more difficult.