I’m addicted to applications. I frequently find myself looking for new apps that could improve the way I work and the way I manage my time. There’re tons of great applications out there, many of them with super fancy UI and a list of features that requires time not only to read but also to imagine all the possibile advantages that they can offer. Some of them are specifically related to task management, notes, file management, some others are a little more complex and pretend to be the only tool to organize the way your team collaborate and work. All of them (almost) are fully integrated, for example with Slack or Gmail. If there’s not a specific integration to satisfy your use case, there’re a bunch of online services that you can easily setup to fill the gap (eg. IFTTT).
For all the nerds obsessed with organization and task management like me, this world seems a great time to live… However the more I work and the more I understand that tools are just tools. Let me explain.
The importance of method
Using a tools is not easy as it may seem: every tool, to be really efficient, need a method. The fact that today there’re lots of good applications is a great advantage. Everyone can find a specific tool that custom fits the needs, but not everybody is aware that it’s not the tool that organizes the work but the method that you apply while using the tool itself.
I recently experienced this issue on my daily work, let’s take this as example. We use two main tools to manage the analysis, development and testing of our software: Mingle and Trello. The two combined are a perfect example, because they serve the same scope (specifically manage the development of software) but they have some major differences:
- One is extremely simple, the other is far more complex to use;
- One is free, the other is extremely expensive;
- One is fully integrated with mainstream fancy services, the other can be integrated but it’s not as easy;
- One has a mobile application with notifications, the other uses emails as notifications and doesn’t have a mobile dedicated app.
I’m pretty sure that this list can go on and on, but this is not my point. I don’t want to review Mingle or Trello (even if I’m a super fan of Mingle, because Trello is often too basic). What I’m trying to say is that the tool will never be as important as the method applied for using it. You may have the most incredible and fancy tool ever but, without a good communication and a shared work flow, it doesn’t worth a penny: ironically Trello is far more fancy than Mingle (for many people) but it can easily become a source of confusion, without a method of use well defined. Having multiple steams of development (or production) increases the level of complexity and a clear view on the actives is fundamental. Of course the needs can defer between organizations and projects: they depend on what you do and how you do it. For sure not all the tools need rules for using them, but many times the so called “Project Management tools” (as Trello or Mingle) require it, in order to use them in a more efficient way.
Identify the needs
So, how can you understand if the actual process you’re using is good enough to give a clear view on the flow? How do you understand if you simply rely on the tool itself or on a process that uses the tool to enhance your organization? Sometimes it’s easier than you think. A good way to start is to look inside your team and ask yourself:
- I don’t like: Is there any issue in the what the team is doing? Is someone complaining?
- I like: Is there something that the team likes about the process?
- New ideas: Is there a tool that the team suggests to use, in order to improve? Also improvement on the process, maybe?
- Pain in the ass: Is there something that bother the teamwork?
Those questions are only the starting point of a brainstorming that every team should implement in order to improve their method of work. Do those “brainstorming” on a scheduled basis can facilitate and train the entire team to a new mental approach (let’s call it retrospective). Remember that the point is never the tool itself but the method: the specific tools you’re using can be changed anytime, the method instead is deeply rooted in the team culture and way of acting. The team should be open minded enough to accept changes/improvements, challenge themselves and be self-critical.
Share, collaborate and improve
Improving the working method itself and selecting a specific tool is never the point of arrival, the difficult part comes next: be sure that the team is aware of why there’s a change in the method and how to use the new tools. Too often people tend to use the given tools as they personally prefer or want: this could be an issue, especially when it’s used to manage team activities. Let’s take a single requirement as example: if everybody change its priority or edit it (even someone who doesn’t have context), the management of the team could become extremely difficult, since nobody has a clear vision on the final objective and customer need. It’s important to use a common method inside the team, to collect and share informations in the best possible way, also keeping track of different responsibilities. There’re at least two good reasons for this:
- Organize the flow and don’t lose the control of the activities;
- Improve the flow.
The processes and the tools that the organization uses are many times defined with a top-down logic. It basically means the the management defines the way of work for the entire team and everybody must follow the path. This logic may become the source of multiple problems: not enough motivated team, sub-optimal solutions or a lack of precision in process details (because the management doesn’t even know the details sometimes). I don’t think that a pure top-down logic is completely sane and it has many limitations: don’t get me wrong, I don’t want to suggest a fully down-to-top logic. The truth is often in the middle, it’s not good to impose (top-down) a method to a team but it’s not even possible to let the team freely decide how to work. The entire working process needs two souls: an higher and more complete view (i.e. the management), in order to focus on every aspects of the project, but also it has to be enough flexible to integrate the suggestions of the team. It’s important to take some time to share feedbacks and discuss on how the working process could be improved. This exercise can be very useful, in order to improve the way the team approach the everyday routine. Never underestimate how the improvement of little aspects can impact your organization: if you add them together your team work may generate higher value.
Guide the change
Changing the way people work is not easy. It needs patience, time and lot of communication. Involving the team in the change is a good way to start, so don’t be scared of trying out new tools and applications to improve teamwork. Good examples are Slack or Moxtra: they enable a more efficient communication inside the team and they’re also extremely easy to setup. However, as any other change, the use of new tools must be guided inside the organization. Trying out a new tool on a simple and circumscribed project is a good way to start. If the tool doesn’t fit your needs you can always switch to another one easily, without having negative impacts on the entire company.
While moving to a new tool, or during the setup of a new method, is incredibly important to define moments of discussions between the different stakeholders. Organizations usually involve many people at once and impose a new way of working to everybody is not a good idea. Setting up some meetings to present the new flow are a good way to start.
Final but not least, when the new process of work has been defined and tested, involve everybody in the new flow. Share the reasons why you shifted from the old process to the new and explain to everyone in the organization how the new flow will work (don’t forget the details). Don’t expect people to perfectly fit the new process from day 1, it will take time. The important thing is to pursue the original objective and keep sharing the feedbacks on how to improve. It’s never a linear process: it should always be a circular process, where the implementation becomes naturally the source of new points of improvement and so on.