When it comes to project management, we often talk about the iron triangle of scope, time and cost. However, in my opinion, there are two very important angles of project management in the Internet industry, one is “value” and the other is “people”.

To do a project is simply to find some people (resources), cooperate according to certain requirements to complete one thing (process), and finally produce a deliverable (result). We often talk about “scope”, “time” and “cost”, from the three aspects of the project process to manage and control, to ensure that things are done right. “Value” looks at the project results, from the perspective of the interests of the company and users, to judge whether the completed project has value, to ensure that the project is doing the right thing. “People” is the most important resource of a project, and whether a team can coordinate neatly and efficiently will directly affect the success or failure of a project. It is precisely “people” that is the most difficult to manage. Different from materials, each “person” as a project member is a fresh individual with different demands and opinions. The difficulty lies in how to influence and drive others to do something. Let me talk about my perception on this point.

Don’t try to do everything yourself

First of all, we should understand not to do everything personally, especially the project manager who has just been transformed often unconsciously have this kind of wrong consciousness, that everything related to the project should be interfered or directly done by themselves, in order to rest assured. Hands-on project managers are the busiest, but also the least effective. There’s only so much time in 24 hours a day that even if you don’t eat, drink, poop, or pin your butt to a chair, you can’t slow down the earth’s rotation any more. Time is limited, and if you try to capture every detail, you will find that there is no end to it. You end up so busy that you don’t get the results you want, even though you’re interfering in everything.

Physically, if you make decisions about all the big and small things that are within your control, your energy will burn out quickly. How zhuge Liang died, tired to death! Why is that? Its small to the staff responsibility for the 10 stick to ask, not tired to blame. There’s another downside: you do everything, what do your subordinates do? You will stifle the creativity of your subordinates. From the perspective of management, a successful manager is a coach of his subordinates, teaching and supervising them rather than doing it himself. If a driving instructor is always behind the wheel and never lets anyone else touch it, can it produce qualified drivers?

So project managers need to learn to turn a blind eye. Turn a blind eye to important aspects that affect the project, such as risk, schedule, and change. In the task decomposition, responsibility to people, rest assured that things to the brothers to do, for details do not interfere, this is a blind eye.

In a word, leave professional things to professional people to do. Project managers have their own professional responsibilities and are already very busy.

Fogg behavior model

In fact, it’s much harder to influence others to do something than it is to do it yourself, especially with a new team. How do you do that? Let’s take a look at the Fogg behavior model. Fogg said that human behavior consists of three elements: motivation, ability and trigger conditions, and only when these three elements are met at the same time can the behavior occur. For example, at noon, when you are hungry and want to eat, you can go downstairs to eat, or you can order take-out. It is raining outside, so you open the take-out App and order take-out. From the Perspective of Fogg behavior model, the motivation of ordering takeout food is that you are hungry, and the ability is that a takeout App is installed on your phone, and the trigger condition is that it is raining outside.

Product managers often use Fogg behavior model to design products to stimulate users’ behaviors on products and improve activity and conversion rate. The project manager can also start from this perspective, carry out team building, drive team members to do things. For example, iOS developer A wants to grow into A full-stack engineer (motivation) and has learned Android(ability) in his spare time. If the project manager finds that the Android development task in the project is A little heavy (trigger condition), he can appropriately assign some to A. For another example, if the new employees lack skills and are eager to have more learning opportunities with the old employees, and the old employees are eager to establish personal influence, the project manager can carry out internal sharing salon according to the schedule to share their technical research results.

If individual demands can be combined in the delivery of the project, the project can not only deliver the project, but also meet the personal development requirements of members, which will be a project that everyone is willing to participate in.

Instead of being an overseer, someone might say, well, I’m not going to do it myself, I’m going to give it all away, and I’m going to supervise everybody. I would go to the development side to ask where the code was, go to the UI to see the half-finished interface, and go to the testing side to see if there were any Bug fixes. If the project manager needs to know the progress of the project in this way, what is the significance of the station meeting or weekly meeting? Besides, the other person is busy with something, and if you ask him, he will stop to answer your question, and maybe the two of you will have a spark of ideas and talk for a long time. It’s a waste of time and energy to pick up where you left off.

What the project manager should do is work with everyone to smooth out the project from start to finish, establish a set of process rules, clarify the responsibilities of each role, and get everyone’s agreement, and let the mechanism work itself out. The rules should govern the behavior of everyone, not the project manager.

Scrum values

Speaking of which, think of the five fundamental values of Scrum for Agile development: focus and respect (the others are commitment, courage, and openness). Keep talking.

Focus means that the team must focus on all the things it needs to do to achieve a deliverable, preferably on one project at a time rather than working on multiple projects in parallel. Similarly, when it comes to personal projects, you need to focus on one thing at a time in order to stay productive. This corresponds to the previous mentioned, the project manager should not be involved (reduce their own work efficiency), do not overwatch (reduce the work efficiency of others).

Respect means that team members should trust and rely on each other. Tukman’s ladder theory points out five stages of team development:

  • Formative stage. In this phase, team members get to know each other and learn about the project and their formal roles and responsibilities within the project. Team members tend to be independent of each other and not necessarily open.
  • Oscillation phase. In this phase, the team works on the project, making technical decisions and discussing project management methods. If team members can’t be cooperative and open to different ideas and opinions.
  • Specification stage. In the specification phase, team members begin to work together and adjust their work habits and behaviors to support the team, and team members begin to trust each other.
  • Maturity stage. Once in this phase, the team works as an organized unit. Team members rely on each other to solve problems smoothly and efficiently.
  • Dissolution stage. In the dissolution phase, the team completes all the work and the team members leave the project.

Respect in Scrum values corresponds to the mature team state, when the team is at its most effective, which is exactly what the project manager is trying to achieve when managing the team. From this point of view, the project manager is a micromanager who doesn’t trust the team. This goes against the values of Scrum and keeps the team in its formative or volatile phase, leading to the failure of the project.