A Project Management Toolkit

I’ve been slow to post a note here about my latest Chronicle Vitae article, but better late than never: my latest article is up! It is about transparency in management: why you want it and how to get it.

Writing that article, and then writing my response to a recent comment with an excellent question about kanban made me start thinking about my approach to project management methods. I’ve used a wide range- from old-school waterfall to Agile methods like scrum and kanban.

I’ve worked with purists in all of these methods, but I am not one of them. Perhaps because I was slow to warm to project management as a career choice, I have never been hugely invested in any particular technique or style. Instead, I view all of these different approaches as sources of tools for my project management toolkit.

When I start working with a new team, I initially adapt my project management style to fit their existing processes, and then we slowly change processes as we see the need. I’ve never started a team completely from scratch- there has always been at least one person there already in addition to the person who hired me. Starting a brand new team would be an interesting thing to get to do. I suspect a project management style would evolve over time as the team grew and I responded to what was and wasn’t working with my methods.

What would my methods be if I had free reign to pick them? That is hard to say, but I can identify some tools I’ve put in my toolkit over the years.

I started my project management career in an environment that emphasized the methods in the PMBOK (Project Management Book of Knowledge, the basis of the PMP certification). These are often called “waterfall” methods, because the project flows through various stages much like water flowing down a waterfall.

I picked up some really powerful tools in my early project management jobs. The ones that have stayed with me even as I moved to less waterfall-y environments are dependency analysis and risk analysis.

Dependency analysis is the process of looking at the various steps and tasks that your team needs to complete and identifying how they depend upon each other. Some tasks can’t start until others finish. Some tasks can run in parallel, but must finish together. Some tasks are completely separate from each other. Really understanding the interrelations among the tasks in your project helps you respond better to the inevitable changes in requirements and timeline slips. It lets you understand when it is OK to let a task finish late, and when it is worth asking your team to put in some extra hours to get things done on time.

I instinctively do a dependency analysis whenever faced with a list of tasks now, even at home. I think this may be one of the reasons I can (usually) get a lot done without working really long hours. I know when a delay will cause a cascade of pain and when it will be no big deal. An extra hour or two of work is worth it in the former case, but not the latter.

I still use Microsoft Project to analyze my dependencies, even when I have no other reason to produce a project plan. I’ve yet to find a better tool for this job.

Risk analysis involves thinking about what might go wrong on your project, and deciding which risks are worth mitigating and which you’ll just let ride. The extent to which I choose to mitigate risks depends on the type of risk, how painful it will be if it actually occurs, and how expensive the potential mitigations are. Sometimes I write down the risks and categorize them, like I learned to do in my early days as a project manager. When I do this, I use Excel. I think anything that can make a table will work just as well. Now that I have more experience, though, I find that the risk analysis often happens almost implicitly, and I only really recognize why I’m adding more testing in an early step or advocating completing the riskiest technical work first if someone asks for my reasoning.

Since I’ve worked on a lot of software development projects, I’ve used Agile methods a lot, too, particularly Scrum. In Scrum, you don’t spend a large amount of time in upfront requirements analysis and design steps. Instead, you work closely with a product owner who represents the user community to iteratively build useful software. The goal is to release a working version of the software after each sprint, which is a short period of time (usually 2-3 weeks).

Programmers usually love Scrum, probably because it treats them like the intelligent professionals that they are and because it lets them start programming earlier than waterfall methods do. I like Scrum, too, although I am frustrated by the tendency to skip doing any dependency analysis. In my opinion, this can slow down projects or lead to a continual crunch time situation, in which the team always feels like it has to work extra hours to “catch up.” This happens when the team commits to implementing a set of features in a given sprint, but then realizes that the dependencies among the features make it difficult to complete them all on time. Experienced people avoid this situation implicitly, but it can be hard for more junior team members to learn to do so since the dependencies are often not explicitly called out.

Despite that quibble, I have taken some powerful tools from Scrum, as well. The idea of releasing a functioning version of the software frequently and incrementally improving upon it is particularly powerful. It forces the team- including the product owner- to stop and think about what features are truly essential, and which are “nice to have.” This method also makes it easier to adjust to changing user needs. I find that even when I’m working in an environment in which a full Agile method is not appropriate, I try to implement the idea of having smaller release cycles and more frequent feedback based on using a functioning version of the software.

Another tool I’ve taken from Scrum is the idea of having shorter but more frequent meetings, and using those to let the team self-organize. In Scrum, the team meets for 15 minutes each day, and each team member says what he or she has done and will do next, and whether or not there is anything blocking progress. Sometimes, the team organization and work environment does not support having daily meetings. In those cases, I look for ways to support the larger goals of having the team self-organize as much as possible, and having frequent communication among the team members.

I came to kanban on my own, when I was looking for methods to help me address a tendency for senior management to overload my team. My initial use of kanban tools was not a true kanban implementation: I worked at the project level instead of the task level. However, I was so struck by the power of some of the tools that I started looking for opportunities to do task level kanban as well. The kanban tools that I find particularly useful are the ideas of visualizing your process and limiting work in progress. Since I’ve written about kanban before and have also discussed mapping projects more generally, I won’t expand on these tools here. I will just say that I have found the idea of limiting work in progress so valuable that it, like dependency analysis, has permeated all aspects of my life now.

As much as I love kanban, I don’t think it is The One True Way to organize work. I have never been a true believer of any project management method. Perhaps that is because of my science background- in science, we’re trained to formulate hypotheses and test them. I tend to look at each unique project management situation and formulate a hypothesis about which of the various tools in my toolkit will work best. Then I apply the tools and see how it goes. We rarely get a hypothesis completely right on the first attempt, so it doesn’t bother me at all to have to tweak my approach as the project evolves.

This may also be representative of my pragmatic work style. It doesn’t matter how much I love a particular method of managing projects. If the method does not make sense to the team or clashes with the overall culture at a company, trying to apply that method is likely to lead to project failure. I want my projects to succeed, so instead I’ll shape my methods to the environment. That doesn’t mean I just “go with the flow,” though. It means that I focus on the core insights I’ve learned from the various project management methods, and look for ways to apply those in my current situation.