Well, what) continue our communication)))

In the last article, I talked about who is the Project Manager in IT, what he does. In this I want to share working tools that help Project Manager in organising their work.

In any large company, and even at the state level, there are Standards for project activities, which are designed to standardise and systematise project documentation and the organisation of software development work. Very often, these are solid documents, with a huge number of signatures and approvals, the creation of which takes time comparable to the time spent on the development of the software, for which the documentation is prepared. And if changes are required, then there is another round of approvals, or even more than one (far from one))). And when such documents are approved by units that are not interested in the results of the project or, for example, when the heads of such units build a whole system of "torture and humiliation" for the units involved in the approval process, using regulations and instructions to satisfy their own ego and increase their own importance, the approval process becomes very painful and complex, and it loses all connection with software development. Moreover, this entire process of document approval does not guarantee either the quality or the desired outcome for the Functional Customer.

Therefore, if we discard the bureaucracy, the theory, the superfluous, the redundant, the non-informative, the "it has always been like this," the "we have always done it this way," the "according to the regulations, instructions, and provisions of № such-and-such," then what remains is what is actually needed and demanded.

What does the project manager and the project team need to achieve the desired result within the specified timeframe and budget?

First, there must be a document that serves as the starting point. These can be FTR (Functional and technical requirements), it can be TR (Terms of Reference), Protocol, Memo, Presentation, any document where the boundaries of the project are defined. From this document, it should be clear to everyone, at least approximately, What we are doing (Functional scope), With whom we are doing (Organisational scope), When we are doing (deadlines). Ideally, this document is written in simple language that is primarily understandable to the Federal Law (the Functional Customer). The document must be agreed upon by both parties (the Customer and the Contractor).

Second, based on the first document, a project roadmap is created. Of course, MS Project is great, but it really only works for small projects where all the work can fit on an A4 sheet, because when the list of work exceeds 1,000 or even 100, it loses its essence, meaning, and connection))) But I don't insist on it, it's a matter of taste and habit, but in none of my projects has MS Project survived from the beginning to the end of the project, of course, I'm talking about projects that last a year or more and are highly labor-intensive. The roadmap should be a simple schedule, ideally on a single slide of the presentation, highlighting the main stages of the project implementation with calendar dates, for example: Requirements gathering/detailing (clarifying the first document), Design (deciding how, on what, with whom, and what to do), Development (doing what has been determined), Testing, PIO, IO. The details of the dates, depending on the duration of the project – month/quarter/half-year/year. On this roadmap, I also recommend marking the periods of the Customer’s involvement, so that there are no surprises)). This document must also be agreed upon by both parties (the Customer and the Contractor).

The third, simple at first glance, is the project's Contact Card), which contains an up–to-date list of all project participants, indicating Roles in the project and responsibilities in responsibilities, as well as phone numbers and mail. It would seem that there is such a thing)))? But! I had such a project in my experience, which took more than one year, so there the team not only did not know all the participants on their side, but also did not know the Customer, to whom and with what question it is possible to address), which gave rise to constant dissatisfaction on the part of the Customer, which eventually led the project to a sad sluggish finale. Such a document is also needed within the team, to understand the distribution of responsibilities and roles in the team, to understand the contacts in order to find the right expert, as well as how, to whom and with what question it is possible to address on the Customer's side. This document is also useful for any new team member. For large customers, a document such as the Responsibility Matrix is useful, as it specifies who is responsible for what and who is in charge of what (they don't know without this document).

Fourth, of course, is the Project Schedule Plan. This is the main tool of the RP. Depending on the relationship with the Federal Law, this document can be maintained in a way that is as clear as possible for the Contractor, or for the Customer, so that the implementation process is transparent for both parties. But! Again, my subjective professional opinion is that it shouldn't be excessive either. Yes, it's more detailed than the Roadmap, and it already includes specific dates and names of responsible individuals, but it shouldn't be unreadable or uninformative. It should be clear and easy for all project participants to understand, and most importantly, each expert should know by what date they need to complete their portion of the work.

Fifth, any Task Tracker))). This is the real place of detailing the work, here you can detail how convenient and understandable it is for the team) It is also optimal to have Milestones, as in the Project Schedule, and under these milestones there are real works and tasks. There are sprints, deadlines, functionality, bugs, and intricate and exciting communication and exchange of pleasantries between analysts and developers) and the obligatory supremacy of the Architect) and here, too, the main thing is relevance.

Sixth, the Risk Map, the current status. On every project that is planned to be successful, there are regular status meetings with the Customer. These meetings are a good opportunity to discuss the current status, problems, risks, and methodological issues in a work-related atmosphere. Essentially, it is a way to verify understanding, including at the management level, of where we are, what we are doing, what resources are needed, and what risks exist. If there are risks, then a person should be identified to mitigate those risks, which should be documented in a working Risk Map. I have seen Risk Maps on projects in an amount comparable to the immortal work “War and Peace”, but this also did not guarantee the success of the project, so, simply, clearly, available and with the indication of the responsible person, it should be in the Risk Map and in the report on the Current Status of the project.

Seventh, the General resource of the project. In each project, there must be a common repository of all documentation. All documents, presentations, protocols, memo, etc. should be stored there. i.e. – the entire history of any documentation on the project. Unfortunately, sometimes we have to prove something to the Federal Law, why we did it that way, and this is exactly what the fixed agreements that are on a common resource help, and again, this is a necessary resource for the whole team, especially for new participants)

That's how it is)

It turned out to be seven, like the Seven Wonders of the world, let it be the Seven necessary tools for PM to see the Light at the end of the project))))