#3. Project management environment
So far, we've talked about what a project is, and we've described the primary artifacts used in IT software development projects. In this article, we will talk about the working environment of the modern manager.
Once upon a time, in the days when management was a military discipline rather than an industrial one, it consisted of someone with a silly title reading out a list of actions for soldiers from a large parchment while sitting on a horse.
By the beginning of the 20th century (thanks to F. Taylor), people began to realize that it was a rookie mistake to rely on the memory and ingenuity of employees. So they started the practice of writing down key tasks & goals on sheets of paper, and nailing them to the walls, for clarity. In the second half of the 20th century, the Japanese were among the first to realize the immense potential of management (and optimization, which is essentially one of the roots of this science). They began to introduce strict management systems in their enterprises on a "mandatory, voluntary" basis. Kanban is one of these systems (and a favorite method accordingly to various management book authors). Mainly, it consisted of a huge board in the center of the factory that showed the current status of the multiple departments' tasks so that employees could see "in real-time" how the company is doing. Toyota gradually developed it over three years (indeed, a thousand days!), and by 1962, apparently having been convinced of its unconditional efficiency, all its production lines operated on Kanban principles.
With the development of information technology, managers in IT companies were continually developing new methods for managing and coordinating the activities of IT teams. Various schemes were printed on A3 and A4 sheets. From the '80s, managers began to actively use mainstream post-it stickers. In the early 2000s, experiments were intensified, using a variety of new and unusual frameworks, including Kanban method, albeit adapted for IT software companies.
Thus, management techniques which several decades ago inspired doubt and mistrust now became not just the norm, but a necessity. The modern working environment consists entirely of web and mobile applications. All these applications boil down to solving three key issues:
- Coordination of the project participants' activities and continuous monitoring of the current status of the tasks;
- Communication between project participants;
- File sharing between project participants.
Now let's have a look at an example of such software.
But before we proceed to the description of various applications and approaches to management, there's one thing I always say: any program or approach is only a tool. There are no bad and good tools. Any tool is useful only if it is appropriate to the problem at hand. You need to choose the tools which suit a specific team, a specific project, and its specific short-term and long-term tasks. As simple as that.
Coming up now is a description of several popular tools and how have I used them in different projects. The idea is not to memorize them, but rather to understand what kind of tools are appropriate, dependent on the working environment of the project.
Let's start with a simple but popular tool: Asana.
Here's a screenshot from the project to develop a large portal (eSports):
The tool allows you to create lists, divide them by headings (1), add tasks (one line: one task), mark as solved (5), assign people responsible for the task (6) and much more.
Then there are tools and symbols which the system does not provide by default, so we added them for convenience:
We used prefixes: symbols that were unique within our project and which enabled the project participants to quickly understand what they were talking about. For example, we added (2) the prefix [IMPV] for tasks that are improvements to existing functionality, the prefix [Portal] (3) emphasized that this is a web platform and not a mobile application (which was also being developed), and the prefix [Player] pointed out to us the page to which the task belonged (in our case it was about the Player Profile Page). We marked bugs with a simple prefix [BUG] (7). In this way, we kept it quite clear and straightforward.
And here's the same project board, recycled in Trello:
Trello operates with somewhat different concepts: List (List) - the designation of the column. Card (Card), Labels (Colored markers on the cards), Powerups (Extensions, mostly third-party developers, allowing you to add new functionality to the board).
- Backlog list, where all tasks yet to be implemented are placed;
- "In Progress" list, for the tasks that the developers are engaged in real-time;
- "In Testing" sheet, where tasks are put for testing by a team of testers;
- "Done" list, where tasks that have already been solved are placed;
- Some of the prefixes we used: in particular, the [NEW] prefix meant that this task is related to a new project feature, [Blocker] indicated that this feature needs to be implemented before the project is launched online, [CMS] (7) – means that the task is related to the Content Management System, and the [News] prefix: that the task is related to the distribution of news on the portal;
- The Trello system icon showing that there is a description in the card (available by clicking on it);
- The Trello system icon showing that files are attached to the card;
- Through the "Custom Fields" PowerUp, we added external indicators to separate the Frontend and Backend tasks that various developers were engaged in. True, we could have used a prefix for this, but at some point, we decided that it would be more convenient this way;
- The Trello system icon showing that there are comments from the project participants in the card;
The Trello system icon showing that there is a checklist in the card
- Orange label, which marks the tasks associated with the visual design, performed by the same developer.
Below is another project. This one's in a rudimentary state (initial settings):
- In the first card, a document is attached, describing the work to be done. The business name of the document is "Scope of Work," or SoW for short. This is one of the titles of the document which defines the list of works as agreed by both parties: the customer and the contractor;
- The colors used here are spelled out: their meanings and abbreviations will be used in this project (for example, for UserStories not to write multi-line end-user role names such as "As Project Database Admin I want to", instead we use "APDBA I want to ..." etc.);
- Attached to this card are all the materials related to the design so that the team working on the project does not get lost in emails and links looking for different files such as fonts, pictures, logos, instructions, etc.;
- There are additional project management instructions, providing general information for all the participants;
- List with EPIC;
- User stories based on epics;
- Tasks created based on stories (though in the above case, the team has not yet managed to make a list of tasks);
Below is another example of a Trello board designed to coordinate technology training for one of my colleagues:
And finally, here is JIRA:
JIRA is a huge tool with a wide range of settings. In order to avoid a long description of its functionalities in this post, let's go over one of the boards we use in Joomag:
- Names of sheets. A new query is added to “NEW”, in the second column a check of the relevance of the query and its feasibility is carried out. The third column assesses the deadlines, and so on;
- Number of objects in the column;
- Project members who have access to this board;
- Task priority;
- Number of days how long the task is in this column;
- The deadline for the task;
- The person responsible for implementation;
- Task name;
- The sequence number of the task in an abbreviated format: number (ABC-25).
These and many other applications are created with the main goal of coordinating the activities of the project participants. These tools make it possible to set up a transparent system, where each participant will see what his colleague is busy with, what his own tasks are, and the time frame for completing them. The ability for participants to communicate is an essential part of almost all these applications, however, as a rule, the purpose of such comments is to act as hints concerning tasks, rather than real communication.
By far, one of the most popular tools these days is Skype. Its "Skype for Business" version is widely used by many companies as the primary tool for communication.
Besides, another application is also widely used: Slack:
- Shows the available Workspaces, so you can simultaneously be in multiple workspaces with different teams, projects and tasks;
- The name of the current workspace;
- Channels of communication usually created for thematic discussions. So, we have a channel called # yerevan-random to which everyone has access and where anything goes, and another channel # yerevan-announcements in which significant events/alerts are published;
- Lattice channels (#), which are public; locked channels: limited to specially added members;
- List of all participants in the workspace, where everyone can write to anyone directly.
- Search for messages. Works both in private conversations and in group chats.
These and other applications have free versions and are available to anyone in the form of web and mobile applications. In some companies, I have seen how they use Facebook group-chats as the main communication tool, but this is, of course, the rarest fun exception.
3. File sharing
Once we have decided where we're going to collect our documents and distribute tasks, as well as what communication tools we're going to use, one last question remains: file sharing.
Since any project, regardless of its specifics, involves cooperation with different people who each have their own tasks and their own working methods, the issue of file sharing can be solved by simply creating private folders in Google Drive, with shared access for the right participants.
However, before you start creating folders, it's a good idea to briefly present the activities of each participant and the files you'll be working with.
For example, if there are several designers in the team, and it is essential for us that the design materials are gathered in one place, we simply create a design folder. And since Google has officially announced the termination of support for GDrive, we can instead make use of alternative free software: OwnCloud.
Time to sum up.
Well, we learned how to quickly outline the project's working environment and solve the problems of coordination, communication of participants, and file sharing. However, all this is secondary compared to the most significant difficulty when creating a new working environment for a project/company, namely: the problem of reaching agreement on the rules of cooperation between all the project participants.
My advice is to agree in advance with the participants and write down these rules so that they are always in sight, but much depends on the culture in which you work. In some, mainly Latin American countries, formal documentation of the rules may offend someone's feelings, and in some Middle East countries, it could even be considered rude.
Assuming we were able to agree with everyone about which chat channels, we'll communicate through and what issues we'll cover, as well as how to distribute files and how to work on tasks, the second challenge for us will be to ensure that all participants comply with these agreements.
This is essentially a paradox. On the one hand, presumably, everyone is very interested in the success of the project; otherwise, it would not start, but on the other hand, we get situations where, in pompous posts, this or that participant tells a sob story and complains that the previously agreed rules constitute an "attack on their ego" and an "encroachment on their freedom." And they use this as an excuse – the developer "forgets" to indicate completed tasks on a project board because he "has no time to drag cards on the board" and "writing code is more important." Or a designer can claim that "it's just not convenient for me, my work is creative, putting ticks in JIRA is beneath me" and so on.
People who only partially comply with workflow rules will always find reasons why they didn't have time. Still, before accusing a person of disobedience, you should make sure that he (a) understands why this working environment was created and (b) why the working rules were discussed. In conclusion, it should be clear that:
- Management is necessary;
- Management, like any process, can vary from “good” to “bad” in the context of the task being performed;
- Failure to comply with the agreed rules reduces the efficiency of the agreed process;
- A reduction in efficiency damages the team;
- Excuses such as “I forgot” or “I ran out of time” are the failings that create this damage.
I will not go into how these very obvious truths need to be conveyed to the team, and who should do this, but let's agree that this task is essential.
In the work process, there should be no exceptions for anyone.
In the work process, there has to be a united approach to understanding the objectives of the project and methods for achieving them.
In the work process, the employee's ego must be put to one side, since it cannot help the team anyhow.
A few numbers about Japan:
There are legends about the devotion of the Japanese to their work.
The economically active population of the country is 65 million people.
It is one of the strongest economies in the world, reliably ranking in 4th place after China (1.3+ billion people), USA (300+ million people), and India (1.3+ billion people).
Japan is the birthplace of the founding fathers of tens and hundreds of legendary management systems and project management methodologies. The Japanese know what management is, and they understand why they need to follow the agreed rules.
Unfortunately, in our society, most people still do not understand that it is possible to be dedicated to your work and yet have a personal life. One doesn't have to damage the other. Some people think that management is "big brother watching you," or "they do not trust you," and unfortunately, managers have to contend with these prejudices from the very first day of the project.
For a more detailed understanding of what I have set out in this conclusion, I can recommend reading The One-Minute Manager, a short book by Kenneth Blanchard and Spencer Johnson. Despite its size, the book is exciting in expanding all that I mentioned in the last paragraphs.
In the next article, we will talk about the philosophy of project management systems and also explore the difference between philosophy, methodology, and project management methods.