In my last post, I wrote about the first thing I do when I take on a new project as the project manager (or whatever that particular organization calls “the person in charge of keeping the project on track and telling upper management if it is going to be delayed or otherwise go off plan”).
I have also written about how I make a project plan. These days, most of my software development projects run using something close to the agile method: we have two week sprints, and at the end of each one, we sit down with the representatives of the users of our system and prioritize what work will be done over the next two week period. We have daily stand up meetings that follow the “what did I do, what will I do, am I blocked” format. I like running projects this way, but I also like running projects other ways. I am fundamentally agnostic about the details of the process and will work with the preferences of the rest of the team. These days, most developers like to work in an agile or agile-like process, so that’s what we do.
Regardless of the process we run under, though, I insist on doing a dependency analysis up front. Often, the rest of the team isn’t even aware I am doing it. I may ask them questions, but the analysis is purely done for my own purposes. I have yet to find a tool I like better for the sort of dependency analysis I do than MS Project (or ProjectLibre, if I’m working for a company that doesn’t have MS Project licenses). So, even on projects that are running with an agile methodology, I end up making what looks like a traditional waterfall process project plan. This confuses a lot of people, and that confusion is part of why I don’t make a big deal out of doing this step. The project plan is a tool, but most people view it as part of a particular process. Nothing is gained by arguing with people about it, so I just don’t mention it to people who are particularly allergic to the waterfall process.
I like to have a project plan like this, with dependencies entered and milestones extracted. But I very rarely actually use this project plan to run the project these days. I make project plans in the Eisenhower sense: “plans are worthless, but planning is everything.” Creating the project plan is an exercise that creates knowledge I find useful if I’m responsible for a project.
Once I’ve done my planning analysis, I then need to transfer that knowledge into the appropriate tool to allow the team to track progress. What tool I choose depends on the project. Here are some tools I’ve used:
- Sometimes, I use the project plan for tracking, too, and in that case, it is a living document that gets continually updated as we run the project.
- For some of the small projects I’m doing on my own right now, I just transfer the milestones to a calendar, and map out what needs to be done each week. These projects have hard deadlines once I get past a certain point, and so the calendar method is a natural fit.
- Some of my personal projects don’t have hard deadlines. Once I have done the dependency analysis on those, I break the project into cards for my kanban board. (I wrote a bit about how I use a kanban board in an earlier post. I have also used a kanban board with a team, and would love to get a chance to do that again. )
- For projects done with a team that likes the agile or agile-like approach, I take the tasks I have on my project plan and turn them into tickets in an issue tracking system such as JIRA. This gives us a head start on our backlog, although I fully expect to add to it and close some of my tickets as “won’t do” as we go.
If I’m not using the project plan for tracking, I file it away. I might put private reminders on my calendar about the major milestones, or I might just pull the plan out every now and then to see how we’re tracking against the milestones. I do this so that I can tell if we’re tracking to what I expected for overall progress, because those expectations will have been communicated to senior management. I have yet to work with a company whose senior managers don’t want to have some expectation about when a project might finish and some means to gauge whether or not the project is “on track.” I actually think it is unreasonable to expect them not to want this information, and perhaps I’ll write about why in a future post. But for now, I’ll just state that I consider it part of my job as a project manager to be able to provide this information to senior managers while also providing the team the flexibility they need to run the project “right.”
If we aren’t tracking close to our overall plan, that doesn’t necessarily mean that something bad has happened, but at a minimum a change has occurred that I should communicate to the senior managers who will eventually judge whether or not the project “succeeded” and was “on time.” Often, those managers will be perfectly fine with changes to scope or timeline, as long as I can explain why the change happened and I can tell them about the change well before it has any impact on their other projects.
Once I’ve done my “Eisenhower planning” and transferred what I learned into the tool I’ll use to track progress, I’m ready to go. Ideally, this all happens before the project officially starts. In the real world, I’m often running to catch up with this work in the first few weeks of the project. I try not to skip it, though. Experience has taught me that if I skip this step, I’ll never really be running the project. I’ll be running to catch up with where the project is going, and that tends to run me ragged.