Making beautiful music together ...
I played drums in my childhood, starting in 4th grade, to college. My family suffered after many hours (and headaches) that I beat up skins for jazz, funk and rock music. When I started playing with the school band, I needed to know that making music was not about how quickly I could make flam-a-dddles or how loudly I could play, but how I did it in relation to other members of the group. If the music caused an adagio (slow and slow pace), it would be a bad idea to break into In-A-Gadda-Da-Vida drum solo, while everyone else will play in the elevator. It was important to combine my play with other instrumentalists and make beautiful music together. While I never had to drop fame with my own surroundings and groups, I learned that music is how the whole group sounds not like a separate player.
By now you are probably wondering why I made a mental journey to Tahiti to tell you about my musical aspirations. For me, a well-structured project team, in which each team member understands his or her role in the successful implementation of a project, is similar to the musicians playing in a group. Each member of the project team knows what they need to contribute to the project, knows when they need to perform, understands what other members of the project team are doing in the project, and knows what is needed for success. It is also important that each member of the project team helps each other in ensuring the overall success of the project.
How does this happen
There was no clear design organization with clearly defined roles. -
This goes beyond the hierarchical diagram. Everyone should know what function they play in a team, how they fit into other functions, and what happens if they do not do their work.
Depending on your industry or functional discipline, there may be standard or user roles that you use in your project. However, there are a few things that I learned about the standard project standards as follows:
Begin with standard or custom roles specific to your projects.
If the project requires a special role that is not related to the standard, then create a special role.
If the project does not need a standard or custom role, then exclude the role
This may seem like overly simplistic statements, but I was amazed for years, seeing the bulky structures of project roles, because the project manager was associated with a deviation from the standard project roles. As experienced project managers, our job first and foremost is to make sure that the right people are assigned to perform the right tasks to get the right result at the right time. In the end, I was never judged by how well I adhered to the standard structure of project roles; I appreciated the results.
If the project environment does not have standard or custom project roles or if I accept a unique project, then I like to take a very pragmatic approach to defining the role:
- Identify 3-6 things in a project that bother me the most or pose the greatest risk to me
- Create roles that cover problems or areas of risk
- Recheck the roles with the work that needs to be done in the project schedule to make sure that all the main roles are defined correctly.
By doing this, I address risk or risk issues, defining a single point of view role for managing the areas of my project that are most likely to fail. This method helped me in more than one project to sleep better, knowing that I have my most important areas.
Team finger pointed and thought publicly -
In any project that you do, if more than one person is involved, there will be lively discussions. When this happens, it is very likely that something good will come out of the discussion, and as a result the project will move one step closer to the finish line. In past projects I managed, I was very aware of allowing these discussions and allowing the team members to ask each other. However, I applied several rules:
- It's very cool to challenge and stretch, but as soon as we make a decision, we need to be behind him as a team.
- What happens in the room remains in the room; outside the room we are one team
- If we make the wrong decision, we make the decision as a team; finger pointer not allowed
- We focus on the problem, not the person; don't make the problem personal
So, were the rules followed 100% of the time? Unfortunately not (including me). In the end, we are humans. However, you should still strive to gain some basic rules to avoid group struggles where you can.
There was no "rallying cry" -
You can look at many large successful campaigns and pull out of them some slogans that embody the message behind the slogan; “Where the beef is,” “Milk, it makes a good body,” and “Plop, plop, fizz, fizz” are all unifying messages that make you think about the product. Likewise, when you manage a project, it helps the team to have some sort of unifying cry or mantra that elements of the team when managing work. In one project, we wanted to be extremely careful not to re-arrange the decision and not to introduce too many bells and whistles to help us lower our costs. We began to use the “good” rallying cry at the design stage to be a continuous reminder that we didn’t want to overdo the decision. It worked incredibly well because the team was critically questioned: “Is this good enough?” When looking at the architecture and functionality. In addition to helping our solution be cost-effective, a rallying cry helped the team improve communication.
Team members were not held accountable for shipping -
With project teams, I firmly believe that each role must clearly understand what they need to do, when they need it, and how their work fits into the big picture. I also firmly believe that the project team is not only accountable to the project manager; they are accountable to each other, because if any of the other roles fail, the whole team will fail. Given this, it is vital that each role is visible in relation to what each other role performs for the following reasons:
- Each role must constantly look at the other work that is being performed to make sure that they know how and how they fit into the other work.
- Each role should feel that if they miss a deadline or do not do their job perfectly correctly, they give the team as a whole, and not just the project manager.
- Meeting or lack of deadlines and results is a group question that should be presented to the team.
This is about accountability. Each member should feel responsible for their work and should experience the joy of success as well as the discomfort of failure. The project manager must use discretionary powers to ensure that everything remains constructive. The focus should be a lot about how the team will return to their tasks and move forward, as well as insulting a team member.
In some cases, however, you may just have someone at work that is not entitled to perform. The project manager must quickly deal with these situations, because if he does not, he or she does not do his job, and they are not responsible to the team when faced with a problem.
The project manager was not suitable for the job -
The needs of the project and its business criticality will be key factors at the required level of experience of the project manager. For relatively simple projects, you can staff the project with an inexperienced project manager with a more experienced project manager who is a temporary mentor. As projects increase the complexity and criticality of the business, however, there is no substitute for an experienced, experienced project manager.
I have worked with incredible success with some outstanding project managers over the years. Considering the best project managers, they had the following common features:
- They knew that project management techniques are cold.
- They knew (through experience) where they could bend rules about methods to be able to buy time or be more efficient.
- They always kept moving forward.
- They knew when to go from the "discuss" mode to "allow" the mode
- They held others accountable for their work.
- They praised the success
- They were great communicators.
- They took the heat for the team when external criticism occurred
- They were calm and focused when everything started to work badly on the project, and everyone else steamed.
I do not know the magic formula for fitting a project manager to a task; I can say that you better be mistaken that you have an experienced project manager, and not an experienced one.
I knew a very young project manager (let me call him the “Author”), who believed that he was an outstanding project manager because he knew these methods well (cost management and schedule, status report, etc.),
As the author knew these methods, he felt that he could at the same time take on three complex projects that really should have each individual project manager. The author not only read very valuable lessons, but, unfortunately, he also cost his company dearly because others came and wiped the mess. Both the author and I cannot emphasize enough to make sure your project manager is suitable for the job.
The team did not celebrate victory -
Driving through a project is hard work. It is incredibly easy for people to get frustrated when a team gets into roadblocks or has setbacks. It is vital that the team celebrate key points in order to maintain morale and maintain the momentum of the project. I'm not talking about a three-day cruise-type celebration; it can be as simple as bringing a pizza or cake or something that allows people to let go of their hair and breathe a little. I would have warned you about this too much; too much celebration reduces the effect of the celebration and can actually annoy your team members. I was in a project where people didn’t like morals, because it meant that they had to stay that evening to do their job. So, celebrate, but do it in moderation.
Warning signs
The team shows confusion about who does what -
Confusion can exist either because of poor communication with who is responsible for which tasks, or because tasks can fall under the responsibility of more than one role. It is important not only to get people to accept areas of responsibility, but also to ensure that responsibilities are clearly documented and transferred to the entire project team. Also, be prepared to pull out this document and remind the team of their relative responsibilities, as the confusion slips back into the project team.
Discussion is destructive and unproductive -
You know how it looks; If you cannot lead a discussion without personal, derogatory, or overt meaning, this is a fairly clear sign that you do not gel in a team. The project team should not be best friends with each other, but they should at least respect what each other brings to the table.
Team members do not help each other -
In fact, I was in some environments as a consultant, where some team members enjoyed the fact that other team members failed and did nothing to help them for the good of the project. Members of the project team, who carry “every person for themselves,” are not going anywhere to approach their full potential.
Turn around
Clarify confusion -
Take the team members locked in the room and hammer them. If you are stuck on a particularly controversial area or if you see hardening burning, set it aside and work on other things, then return to the disputed area. Make sure that the duties are documented and clearly accessible to all participants.
Contact a member of the problem team -
It was never a pleasant task, but it happened to me more than once that a member of the project team took off the project because they simply remained a destructive force in the project. At the same time, I was also able to turn the destructive situation around. In any case, quickly fix the problem before it causes additional damage to the rest of the project team.
Match the command -
I had some of my greatest successes when the project team was physically located in the same area and had minimal physical barriers to suppressing communication. This may or may not be entirely possible depending on your project, but wherever you have the opportunity to jointly find team members, deciding to do it.
Go out to the milkshake -
Sometimes it’s great to just remove people from your work environment and chat with your favorite foods and drinks. As a consultant for non-urban projects, our project teams were usually very effective, because we had more time for communication and communication during off-hours. Get to know each other a bit and be able to laugh, because the team will pay huge dividends in the overall effectiveness of the team.
Everyone works and does not play ... -
... makes for a really boring and demotivating project. Spend some time out of the project to laugh. I, of course, know that we sometimes play a random joke on a project or introduce some random lungs during a particularly busy time in a project. Just be careful that the use of humor is not too excessive or inappropriate; but make sure you share a laugh or two, even if it is at your expense.
Be a unifier -
As a project manager, you must take responsibility to force the gel team and learn about existing hairdressers who prevent the team from being a very cohesive, collaborative and high-performing team. From time to time this will probably be the most awkward part of your job, but it can also be one of the most useful when everything is going well.
To take
- Define clear project organization with clearly defined roles.
- Be a team of thick and thin; don't publicly state when things start going south
- Develop a “rallying cry” that focuses on the team
- Let team members do their work, but be responsible for the results and dates
- Make sure you have a project manager who is seasoned appropriately for the project.
- Celebrate team wins
