Project management. New Year’s theses

Project management. New Year’s theses

A little introduction (not self-promotion): back in 2003, I came to work as a young programmer in the accounting department, I had to study the area in which I needed to code, and after 2 years, the accounting department absorbed me. 15 years have passed, I have already managed to escape from the clutches of accounting, they call me as a manager and start talking about buzzwords: digital transformation, project management, Agile and others. It turned out that I will have to assemble a team and develop these directions in the company.

Years have passed, tons of articles have been read, hours of video lessons have been watched, hundreds of meetings have been discussed with colleagues, and many cones have been filled in practice. But the experience of what works and what does not work in project management has come. And also the realization that every stage of our life and every job is a project, not a process.

So, I will try to go through the main theses. Something may seem obvious to some, but I will be glad if it will benefit someone.

Thesis 1. There is no competition between Waterfall and Agile

Just like there is no hammer and screwdriver competition. Everyone has their own purpose. We are looking for a tool to solve a problem, not the other way around. I am exaggerating, but many are used to associate:

Waterfall – roadmaps, project passports, role matrices, risk maps and a lot of other documentation with detailed technical specifications on many sheets. And months of preparation for all this. And it is not a fact that after that something is realized.

Agile is a commonwealth of positive IT people and businesses who, over a cup of coffee, come up with another feature in the backlog and implement it for users within a day (week).

Unfortunately, but 50/50 both statements are both true and false. Why? Read on)

Thesis 2. Waterfall is not a dogma strictly according to PMBoK

PMBoK as a summary of project management knowledge describes us in detail and carefully the structure of the project, the stages and the documentation that should appear. And one of my mistakes was at one time “acting according to the textbook”. Hardly works, boring, long and expensive. However, it helped to take the most useful from it for most projects in abbreviated form:

  • Almost no one has denied the need for road maps for a long time. It is necessary, even if there is only one person in the team and the project is moving from point A to point B. An action plan as a checklist will not be superfluous;

  • From the project passport, you must have goals (at most according to SMART), a triangle (content-budget-terms), requirements for the MVP, in addition to good goals and assumptions (which we definitely do not do);

  • Breakdown into stages with a tangible result and criteria for its acceptance (somewhere it smelled like sprints);

  • The role model is very important for everyone to understand who/what is being done on the project and what is not being done.

Thesis 3. Agile does not mean no documentation

Agile Manifesto has been read by many people, but also understood by many people in different ways. Orientation to the result does not mean that the project does not need documentation, that TK is evil, as well as comments in the code. A balance is needed (again accounting in the head) between a quick result and understanding that the product still has years to live. Including, the teams will change, and when they come across legacy code without artifacts, they will not be engaged in product development, but in another refactoring (when they hit the ceiling) or in general rewriting from scratch.

Thesis 4. Part of the team, part of the ship

Despite the battered phrase, it is still relevant. Everything is important: microclimate, rituals from kick-off (introductory meeting on the project) to daily/weekly meetings, from demo to users to retro (when it would be called flight analysis). Contact is required, both within the team and with external participants: customers, vendors, etc. What should be done for this and motivate, on the condition that it is also necessary to do the work according to the project? Try to find an approach, talk both in One-to-one and group discussions. Moderate and facilitate not only meetings, but also conflicts, and the sooner the better. But start carefully, not everyone is ready to criticize or listen to criticism, open up and speak as it is. There are also many activities around work that can bring unity and team spirit: gamification, orange Fridays, joint events, stand-ups.

Thesis 5. Study, study and study again (c)

If you want to be a mentor for your team and involve people in the process, then you have to start with yourself. Including compiling your IPR with metrics and retro-analyses of both the effectiveness of this or that method of learning, as well as the usefulness of these or other acquired hard/soft skills. As my geodesy teacher used to say: “An extra profession does not drag on your shoulders.” Do not hesitate to develop in neighboring industries, expand your horizons, it will definitely come in handy. Based on these considerations, proceed to the IPR of the team members. Here, the relevance of the training program and the fact that most of the training takes place in the course of working and using Google must be taken into account. Do not hesitate to help, but the help should not be unsolicited and even more so arrogant.

Thesis 6. Learn from mistakes and admit them

I think this is the pain of many, regardless of age. The PM/boss/team leader is of course an expert on many issues, but that doesn’t mean we won’t make mistakes. Believe me, objective recognition of your wrongdoing in front of the team does not lower your rank, but on the contrary increases the degree of trust. Hindsight is very helpful in identifying the causes of mistakes and taking preventive measures. The main thing is not to dwell on this, but to enter it into the general knowledge base (FAQ), because human memory is so arranged that we involuntarily try to forget our mistakes. Some practices in psychology can also help.

Thesis 7. Abstraction

I often give an example during movies where the camera shows a person and then smoothly moves away into space. It is necessary to do the same with the analysis of any task, to look more broadly, at overlapping processes, at neighboring services, at the data used. And this is where the overview, both general and branch and subject, begins to help.

Thesis 8. A good plan today is better than a perfect one tomorrow (c)

This thesis is for perfectionists and also for people who think they are definitely not. You can endlessly write the most complete TOR or a beautiful user story or perfectly optimized code, but the product/feature is always needed yesterday, at best, today. Try to force yourself to eat the elephant in parts, approach iteratively to the implementation of the task, while not losing focus on the final goal. Here we will again mention the combination of Waterfall and Agile.

Thesis 9. Development and project management is also a business process

Everyone knows the picture of a swing, TK and a programmer. Any business process always has a beginning, actions of participants and an end (not always with a result). There are many variations of both project stages and the development process. I will stop at the stages of development of any feature: the beginning (a task or an idea has appeared), interviews (search and survey of stakeholders), analytics (at the same time, it is also important to abstract from the method of implementation imposed by the user and understand exactly why this is being done), review and user and technical coordination of requirements (business, system, TK, site user, etc.), development itself and architectural/infrastructural changes, technical testing (by the developers themselves, including among themselves), functional (that whoever wrote the TK should understand what happened in general, demo or user acceptance, implementation (transfer to prod, training, feedback collection, backlog of bugfix requests)

Thesis 10. Instead of an epilogue

Of course, there is much more that I would like to share, but then it would go beyond the scope of the article. So theses in this case will remain so, not pretending to be complete, not answering the question of how, but giving recommendations on what to do.

Projects that interest you, training useful skills, self-organizing teams, and positive burnout. As they say on the Internet: subscribe, like.

Related posts