Work breakdown structure and project management tools

Project management or online collaboration?

According to some estimates income from sales of tools of project management will grow up to $730 million in 2016. Such interest to applications for running everyday business activity has a solid base of advantages. Forrester Research says that profits from implementation of digital command centers is highly notable, for example, losses from downtime in activity of a staff can be reduced on a quarter, not mention to reduced failures of a project or cost overruns. 

Rapid growth of demand on these profitable solutions provoked equal increase of mutual offer. It is so significant, that one can hardly work through the market of such services. Currently more than a hundred of them already exist, and many tools are in development. Nevertheless, despite such selection many of these services copy each other reiterating the same conception - a bug tracker. This trend became very popular from launching of Basecamp by 37Signals in 2004, and other tools were soon to follow: cute RememberTheMilk, complex JIRA, Assembla for optimizing development process, and so on. These services, of course, have predecessors (GNATS, for example) but their principal advantages over earlier tools were usable interfaces and comfortable use cases.

Such tools became very popular not only in developer communities, which applied them according to their primary bug-tracking function, project managers also appreciated them as a task distributing tools and started to apply them too. But initial optimism disappeared soon - it turned out, that such tools cannot handle complex and lasting projects to run. The most annoying problem relates to storing information in these services: Basecamp, RememberTheMilk, other similar products supported only flat to-do lists, unfit for creating work breakdown structure according to PMBOK. 

Absense of relationships between issues is the point of weak for plain to-do lists, and makes running of complex project a difficult task. Long term planning and expanded activities are impossible without deep decomposition of issues - WBS allow managers keep their projects from overriding costs and deadlines by making them controllable. Even if you apply agile approach in your work process (for example, SCRUM), decomposition is always helpful and effective.

Tool, which isn't applicable for creating work breakdown structure isn't a tool of project management, it's rather an online collaboration service, and this very feature tells simple products like Basecamp, Trello or RemeberTheMilk from full-fledged systems for serious business: desktop old-fashioned MS Project and Oracle Primavera or modern askcow, FogBugz or Wrike web services.

Why to-do lists everywhere.

The number of simple tools without support of work breakdown structure is huge in contrast to full-fledged services of project management capable to store the information about a project inside a tree of issues. In addition, such products often are more expensive, and sometimes the price on these solutions can exceed a thousand of dollars. The situation is easily explained. 

Tree of unlimited depth, especially for web services, is much difficult in implementation than plain to-do lists, and sometimes developers fail or refuse elaborating full-fledged tree for the application. Not so many engineers capable to make expanded tree works fast, especially in web services, and sometimes developers just put aside full-fledged implementation of this feature. LiquidPlanner, for example, seemingly supports a tree, but at closer examination only few levels of hierarchy for storing tasks are available, what makes deep decomposition impossible.

LiquidPlanner isn't a single service with simplified WBS capabilities. Another is Asana, which suffer from absence of clearly visible structure of a project. Deep decomposition of tasks is possible in this service, but an interface doesn't display complete framework of a project - only few separated hierarchical levels of tasks are accessible at the same time. Engineers did their job well, but UX designers were not, despite colossal investments in developing Asana.

Heavy expenses on labor of engineers and designers ruined many undertakings, or at least raised prices on final products too high. Of course, these risks are obvious for those who develop tools of project management. Nobody wants to fail, and sometimes it's better to make a simpler service, than not to make it at all. That's why the number of tools, which go without WBS functionality, is much greater than of full-fledged project management services.

Difference between online collaboration and project management tools is also become apparent in price, which can exceed $1000 for downloading a software package. Of course, not all services with WBS support are so expensive, and there are some exceptions from this rule, askcow, for example.

To-do lists are simple and cheap, but they cannot handle complex structure, and if you're looking for project management software, seek for a tree.

Tags vs. tree.

But some people suppose that there is a solution, which can create a structure for information without applying a tree of issues. The story now is about tags, and usually people work with them in the following way.

According to this approach, a project is being run into a single list of issues without relations between them. Similar tasks are marked up with a same tag.  When user wants to see similar tasks, he searches through his project by using a corresponding tag, and then deal with a short listing of search query. In addition, some tools, JIRA, for example, allow saving search criteria as a bookmark, so, practically, your information is accessible in one click only.

This approach has many advantages, but often only simple executors take use of this feature. Managers responsible for entire project face important difficulties, because tags don't display the structure, and this problem slows down the work and its efficiency. Of course, you can describe in tags relationships between issues, a name of parent or descendant task, for example, but it's painful. In addition, you have to constantly refer to list of your project tags, and this contributes to discomfort.

Certainly, there are other ways to get to framework of a project, but they are even more confusing. Anyway, I doubt that tags are indispensable. Indeed, why do project management tools need them, when there is search functionality? In askcow, for example, which fully supports tree of issues, you can find all tasks containing a keyword and save the search as a bookmark, like traditional tools without WBS capabilities do. Tags are useful for making results of search query uniform, but they cannot substitute tree in creating project framework.

This piece of functionality become very popular nowadays, you can meet tags everywhere, but tools of project management are unlikely need them. Usual search does the same.

How not to tumble from a high tree.

Conception of tree for storing information about project's framework along benefits has some disadvantages.

Sometimes it isn't so convenient to deal with for simple employees, who often get confused by large number of tasks inside entire project, especially when some of them lie deep inside the framework. The solution for this problem is to restrict users from accessing tree branches, which don't interfere with their job. By adding somebody to a project, just set him narrow zone of access consisting from few tree branches related to his activity. In addition, tree doesn't exclude usual flat lists, and almost all project management services support them. By a click you can transform your project framework into a to-do list for employees, and of course, decent tools provide such ways of running a project.

Another important problem for tree relates to task management. It is not enough to place task inside a tree once, user should have a possibilty to change issue's place at any moment. Not all tools support moving an issue from one tree branch to another (Asana), in addition some of them don't keep track of issues, which have been moved, so they can be lost.

The first problem is critical. Of course, when you select wrong branch for newly created issue, you can send it to litter and arrange a new task in correct place - you'll lose only seconds. But if your task is mature, has many comments and attached files, impossibility to change the parent of this issue becomes painful. You have to create a new task instead of just moving it, and this is highly annoying UX scenario.

The second problem, inability to trace an issue position when it changes, isn't so disturbing. You always can use search for finding missed task, but if someone dropped it into other tree branch by mistake, it's hard to know about it. And here I want to make a small remark related to drag-and-drop, which often is responsible for occasional disappearing of issues. Many tools apply this conception for carrying tasks from one place to another, but just mentioned problem keeps me from unquestioning approve of this feature.

Tree can also have other weak spots, which can make work with it uncomfortable. Some tools, for example, don't allow concentrating on a single tree branch by applying adjustable filters. In others, tree works very slow and it hurts efficiency a lot. But such problems aren't so important, project can go with them, whereas lack of possibility to move tasks between branches and switch to plain to-do list from a tree view are highly important.

Tree is a must for tools of project management; it also has to be elaborated well and shouldn't substitute traditional flat lists.

WBS approach and serious business.

Running a medium or large project without work breakdown structure is impossible nowadays. Deep decomposition allows managing costs and resource both in time and space, so corresponding tools will always be in demand. One of the largest and most expensive engineering and scientific projects, International Linear Collider is run according to WBS methodology, and this is a clear illustration of efficiency of discussed approach to planning.

If you didn't yet choose a tool for starting new project or running a business, don't forget about frameworks and WBS, because it definitely save your money by making a collaboration of your staff manageable and focused. If you already work with a tool, which isn't capable to represent hierarchical organization of your activity, I strongly recommend you to find more comfortable services as soon as possible - tree awaits.