A Fool With a Tool
Wanted: A Silver Bullet
You can see it coming a mile away. A project team runs into a problem managing requirements, keeping track of their project schedule, tracing their tests back to their requirements, or some other activity crucial to the success of a project. They get together (good sign) to discuss what they should do to improve their situation and inevitably the suggestion comes up, "if only we had a tool to do that..." And so it begins.
Teams often look at tools as the silver bullet to slay all of their problems; and when used correctly, they can keep most werewolves at bay. Thing is, tools can also cause more problems than they solve, especially in the hands of those not completely prepared to use them.
The Problems That Tools Cause
Not too long ago I heard about an organization that was having difficult keeping their projects under control. They struggled with selecting the projects on which they chose to focus, and with managing those projects once they were underway. How did they choose to improve their project management approach? They bought a Project Management tool produced by a large software company, and purchased training on that tool for the people who are the most active in their projects.
None of the people who attended that training hold the title Project Manager. Rather, most are managers or executives who manage teams of people and are responsible for leading projects. Throwing a project scheduling tool at a group of people who had only a cursory knowledge of that discipline, and then only providing them training on the use of the tool-not the art and the science of the discipline-created a group of people so focused on the nuances of the tool that they completely lost sight of the realities of leading and managing projects. You know, things like managing risks, removing obstacles facing the team, and making timely and value-based decisions. At least they followed my advice to not bother with the resource leveling feature.
This little story—true I'm afraid (you can't really make this stuff up)—highlights a common misconception among teams and organizations: that you can learn a trade simply learning its tools. Training a bunch of people on a project management tool with the expectation it will make them project managers is akin to training someone on a spreadsheet program and expecting them to be an accountant, or training them on word processing software and expecting them to become a novelist. (I would have said writer, but could then anticipate the emails, "Yes but Kent, you know how to use a word processor and you claim to be a writer...") There is a lot more to being an accountant or a novelist than simply using their tools, just like there is a lot more to leading projects than knowing how to use software that helps you create project schedules. There are all of those nuances that you learn through experience, or through mentoring from someone who has slogged through it before.
Of course, there is some value in giving people the basics of the trade that coincide with the use of the tool. That information can serve as a foundation while they gain the experience that teaches them all of that nuance. But what I often see happen is that when someone's only understanding of a trade is how to do it using a particular tool, their initial deepest understanding of that trade is colored by how that tool requires you to do things. At the organization I mentioned above, their impression of project management comes down to the mechanics of using the tool. You hear phrases like "I spent all day trying to add tasks to this tool only to find that I can't save them." Or, "I spent all afternoon trying to close tasks but the tool won't let me."
Problems of a different sort can arise if you have people on the team that know the trade but do not put a great deal of forethought into their tool selection, or (*gasp*) have it selected for them by people that don't do that particular task on a day to day basis (that never happens, does it). In those cases, the team becomes stuck with the particular way of doing things that the tool is based on. They also use the tool as an excuse to not change processes that are not working. The ferocity of this argument increases exponentially with the initial price tag of the tool. "Sure that sounds like an easier way to do things, but how do we do that with this tool? We invested so much in it, we have to keep using it."
Solving the Tool Problem to Solve Your Project Problems
So what are teams to do? After all, there are cases where tools are extremely helpful to a project team, especially where there are repetitive tasks that could be automated, freeing up the people on the team to focus on those tasks that require more thought. Examples in a software development project are things like automated builds, automated tests, and configuration management systems. Below I provide some things for a project team to consider when they think they need a tool.
What is the job that is to be done?
The minute that the idea for applying a tool comes up, the teams needs to make sure that they have a clear understanding of why they think a tool is necessary. What do you expect a tool to accomplish that is so much better than doing it without a tool? This is especially important if you sense that a specific tool is being recommended because someone saw it and thought it would be really neat. They rarely say this, but often it is a solution in search of a problem. This same question needs to be asked when the use of tools is being dictated by "the process" or by the PMO. Does the use of the tool actually add value to the project, or are you using it simply because you were told to do so?
Treat the selection of a tool as a mini project.
When it comes down to it, selecting a tool is very similar to any other packaged system purchase. Generally speaking you would not make a major purchase without knowing why (see above), knowing what you are looking for (i.e. requirements), and having some idea of when you will be satisfied with your selection (selection criteria or acceptance tests). Most of the time, selecting a tool-unless you have multiple to choose from in your organization-is a major purchase. Of course, you don't want to go overboard and put too much process around the selection decision such that it impedes progress on the actual project. After all you don't want to waste all of the business value that would be gained from the use of a tool in the selection process. Gather enough information to make an informed decision, but don't waste time doing it.
Bigger is not always better.
The main purpose of tools is to help automate repetitive activities or those things that do not require human brain power to accomplish. Often times, simple tools that are highly flexible can be used to realize most of the value from applying a tool with hardly any of the cost. I have found that spreadsheet programs can perform a vast majority of tasks for far less cost than specialized tools. Plus, in some cases, building a model for performing a particular task using a simple tool actually helps the project team build a better understanding of the nuances of the trade. In some cases, even a spreadsheet or word processor is overkill. Depending on the situation, sticky notes, a whiteboard, and dry erase markers are sufficient and preferred, especially in the case where uses of a tool prohibit collaboration, such as a requirements management tool which leads the team to interact with the requirements management system in stead of each other and their stakeholders.
Don't let the tool dictate your process.
When selecting a tool, make sure it supports the processes you currently follow that work. If the tool drives your team to use a different process, make sure that process makes sense for the project team and that particular project. Most tools that you bring in will have lots of shiny new features. Resist the temptation to use them unless they directly support what you are trying to accomplish, and don't feel compelled to use a feature simply because it exists. Remember, the tool was built to appeal to a wide variety of users, so there are bells and whistles that you probably don't need and could get in your way.
Don't Be Foolish
So the next time you sit in a retrospective and get into a discussion about how the team needs to be better at understanding how to schedule a project and they read an product review about a great tool that will do just that, engage them in a friendly conversation about what problem they are actually trying to solve and what makes the most sense for your team. Then whip out a stack of sticky notes and a pen and suggest there may be an easier, less expensive, and more collaborative way to do it.
Tools for Teams: Beyond the Email Bottleneck
A slightly different take on the tools conversation—how do you know when you need one, and how should you implement it?
Agile Technique Guideline: Information Radiator
Kent explains a simple technique for addressing an often complicated problem. Sticky notes are used in abundance.
Agile Technique Guideline: Stand-up Meetings
Another example of elegance through simplicity. (And more sticky notes.)
Project Management Software Tools Evaluation
Determined to have a tool? Make sure it's got the right features.
Resource Leveling Using MS Project
Dead set on using resource leveling in spite of Kent's advice? Here's how.