For me, as a project manager, this story started when the team was already 3 months behind schedule with delivering the agreed functionality. On one side I had a frustrated client, who did not seem to understand the reason of our delay. On the other side – there was a strongly discouraged team, as the very cooperation with the client was extremely difficult and challenging.
It is worth stressing the fact that it was a big (15 members) team, consisting of experienced employees – there were seniors in every area; development, testing, business analysis. The company supported the team and the project with all possible personal resources and best practices.
All the parties (the client, the team, the company) were convinced of the need for change. However, the idea of what should be changed remained vague. Nevertheless, it was quite obvious who was supposed to make the change – Project Manager.
In this post, I am going to discuss my endeavours at defining and carrying out this change. I would also like to show why command and control management, which usually has a bad reputation and is associated with the lack of project management skills, may be an effective tool (if well-selected and applied consciously) of improving a project’s difficult situation.
Analysing a problem encountered in a team and while cooperating with the client
Each and every change should be preceded by such a thorough analysis as circumstances may allow. Even if there is a fire after a fire n a project, and we feel more like a firefighter than a project manager, a deep analysis will help us take the best decision at a given moment.
My situation was quite convenient – I took the project over after another team member. We worked together for 2 weeks during the transitional period, hence we had enough time to discuss the most important aspects which, from the perspective of my predecessor, affected the project status in a given way. If it hadn’t been for such a careful handover, which the guild took care of, it would have been far more challenging to carry out the analysis.
Those two weeks made it possible for me to meet all the sides: the client, the team, and the company’s representatives. I was able to get a more accurate grasp of their expectations and the reality that was far below these expectations. I also had an opportunity to find out what the root of the problem was according to each side, and what should be done in order to succeed in completing the project.
The outcome of the discussions allowed us to determine the actual obstacle in delivering the software within the assumed time and budget. Thanks to that, we were able to draw up a plan of tasks to be performed, which aimed at efficient delivery of the system.
From team management to team cooperation
Consequently, I carried out an analysis, specified the tasks and put them into practice – everything went smoothly. In the end, the prince kissed the princess and, as in every fairy tale, they lived happily ever after… Unfortunately, the reality is not as beautiful as in Ezop’s tales. It was a bit more difficult… well, more than a bit.
I have already mentioned that each party had agreed that the project required sweeping changes. Based on common sense, one could assume that if everybody agrees on the necessity of change, its implementation should not pose a challenge. Unfortunately, one thing is to be aware of the need for change and the other one is the very willingness to do so.
I started implementing my changes with determining the team roles as well as my expectations towards each of them. One could think that it is absolute basics, which we should not bother with in an existing project. In my opinion, specifying expectations in a clear way should be a starting point in a PM’s work, since each team member has different experience gained from various projects. It is very often the case that people deal with issues that are beyond their competences. One of the advantages of determining the roles is that employees focus on what they are supposed to do, and they stop taking care of things they should not – and this is what happened in my case.
As I have mentioned earlier, I managed a team consisting of 15 experienced people. With such a big team, it is extremely important to cooperate closely with the leaders, since it is hard for a PM to communicate our expectations to each and every individual and require each team member to perform certain tasks. Therefore, it is communicating changes in a project is of huge importance. If there is no understanding of why we are doing what we are doing and what effects we expect, such a situation may lead to some kind of resistance, which we may not be able to overcome. Thanks to close cooperation with leaders, we are given an opportunity to receive support from technical experts (developers’ leader, architect).
After assigning the roles and responsibilities to team members, and having agreed on that with the team leaders, we clearly communicated the rules which were to be applied from that time on, including task granulation to 8h, lack of goldplating, working only within the task, updating the board during the daily. The most significant issue here was to be consistent and firm in implementing these rules until they became a habit.
Such actions are very often resented by team members. In my opinion, it results from the fact that we like working on ordinary patterns and every change brings about some kind of a natural anxiety. As a common saying goes: ‘’The devil you know is better than the devil you don't’’. One does not need to be a genius to figure it out that command and control management, introducing rigid rules and being consistent in their implementation, does not work in favour of a PM. If a PM expects to give high-fives with the team members at this stage, he or she may end up being disappointed.
It is worth pointing out that such a management style brings benefits relatively quickly – which does not necessarily mean immediately. In my view, only after the first few results, can we expect the team spirit to increase and the members to become convinced of the validity of the decisions taken.
We obtained positive results in the project. We delivered the long-awaited components, the client satisfaction increased, and the situation became stable. Now, it was time to change the way the project was managed. I could let my experienced team be more autonomous and take more responsibility for the project.
It did not mean, however, that the rules that had been determined earlier were to be thrown into the trash and that we would need to start from scratch. Some of them had to be modified so that they could fit the new situation better, and some of them were yet to be invented. What was important here is that we were trying to come up with these rules together as a team.
Retrospectives turned out to be a good opportunity to work on such new rules. The team could come up with ideas, which were later put into action and became rules. As a PM, I was supposed to provide my team with enough space so that these ideas could be implemented.
Our further work was performed in a much better atmosphere, the rules created together were modified as the work progressed, and the team members changed.
Command and control management is often associated with the lack of management skills. However, if consciously selected and skillfully applied, it may be indispensable in certain projects. Other methods may lead to early termination of a project. Therefore, it’s crucial to notice the moment which requires to switch to a new model of cooperation since, in the long run, only a very strong and close-knit team is able to succeed.
If command and control management is applied too frequently, or if there is lack of competences to manage the project in a different way, frustration and dissatisfaction seems to be inevitable. Such a situation may also lead to conflicts, or even employees’ decision to leave the project/ company.