The zing of bullets flying through the air, enemy soldiers popping up out of nowhere, a thud and a scream as a soldier falls to the ground. My heart is in my mouth and my palms are sweating. So how can we as technical managers learn from Lieutenant Winters in a scene like the Crossroads of the Islands Charge*.
Let’s imagine that you have been asked to get a failing project back on track. Typically these projects have blown their budget and have either missed a delivery date or look destined to do so. In the company I work in, we deliver technical projects to paying clients. This adds another level of complexity to the situation and in nearly every case I have seen , a very unhappy client. Now, if you squint your eyes a little and tilt your head to the side, it’s not really that dissimilar to what Lieutenant Winters was facing, an enemy of unknown size across an open field with a small team of people with you, granted they are talented but they are a little freaked out right now and having a bit of trouble focussing.
By the time a project has reached this point, there is a fair amount of dysfunction within the project team and everyone seems to have a different slightly and somewhat disjointed story. The information that is thrown at you can be overwhelming if you let it. Your first job is to take control and calm the situation. You have been brought in at that point because somebody has confidence that you can improve the situation or you are the last person standing, either way it’s up to you so you need to suck it up at this point, put on a brave face and be a leader. Let’s take a look at how Winters handles the situation. He speaks calmly to his team, “fix your bayonets”, “go on my signal”. The instructions are clear and simple and then he stands up and leads the way even though it’s scary and dangerous. He is inspiring confidence in his team and showing them that they just need to follow his directions right now to achieve their goal.
As the company engage the enemy in the scene, more information starts to come in. Winters starts to collect this information from key personnel. This is your first step as well, to listen to your key leaders on the team. In my organisation and most likely yours, this will be the Technical Consultant (TC) and the Project Manager (PM). You need to gather as much information as possible as quickly as possible. Ideally these two people will be on the same page, but that isn’t always the case. Once you start to identify the issues you may want to draw in other team members to get more detailed information on specific issues. Remember, at this point you are in information gathering mode not problem solving mode. While you might already have a few ideas on how to move forward make sure you don’t short cut this step or you could head off down the wrong path.
When to talk to a client can be a tricky decision. If you go straight to the client without gathering some initial information from your team it is possible to get biased information from the client and it is really easy to accidentally throw your team under the bus. On the flip side, sometimes your team might be thinking the client situation is much worse than the reality, so leaving it to late to engage with the client can cause you to end up sinking in a lot of effort that isn’t required or maybe even solving the wrong problems. In general I like to talk to my internal team, dig into any issues that I don’t understand a bit deeper and then talk to the client. When I say talk to the client, I actually mean get off my chair, go to their office and sit down with the client. Seeing their body language and picking the right words for the situation is a really really easy way to settle the situation and allow us to focus on the real problem. Your job during this conversation is to understand why the client is unhappy, what the client is expecting and when they expect delivery. You are not committing to anything at this point and if you are pushed by the client, you should let them know that you are coming on board to gather some information and put a plan together to get the project back on track and only commit to date that you will get back to them with more detail. When you leave this meeting the client should feel confident that you have heard their view and that you will be able to deliver a favourable outcome, in short they should have confidence in you even if they don’t have confidence in the team yet.
So you have a good stack of detailed information at this point from a wide range of people involved. The next step is to review and prioritise the problems. In nearly every case I have been involved with, the team are wrestling with many issues, trying to deal with these at the same time and spending a great deal of time being blocked and just spinning their wheels not making any real progress. In a recent case the team had become bogged down with trying to solve a complex two-way data syncing process to update profile information between our new system and active directory. We had gotten stuck in a loop because we weren’t even sure that we would have connectivity between all the systems or permissions to write to active directory. As it turned out there was no way the internal IT department were ever going to allow users to update these fields and the requirement for two-way data syncing just vanished before our eyes.
You will need to work closely with your TC and PM during this prioritising stage. I like to provide a summary of the information that I have collected so far and confirm with my team what the client is expecting as an outcome. Once the three of you are on the same page, I like to get the TC and PM up on the board to start prioritising the activities to be completed. I get them to talk their thinking through out loud, if it doesn’t make sense or is different to what you were thinking be sure to ask questions. They need to keep explaining until everyone is convinced the approach will work. I’m the type of person who values directness. I am happy for these sessions to end up being a bit of back and forth, because my team has worked with me for a long time and we can trust each other, they are not scared to tell me I am wrong and to fight for their approach if they believe it is correct. How you approach this session will depend on your own leadership style, but at the end of this conversation everyone needs to feel confident that we have the right approach and everyone needs to respect each other and to work together to execute the plan when they leave that room.
Once the general approach is agreed it’s time to get the development team back into the war room and to start making estimates, adding any missing resources, chunking tasks into delivery sprints and assigning tasks to the team members. I suggest that you review the previous sprint burn down charts before this session to get an idea of the quality of the teams estimates so far and the velocity they have actually managed to deliver to date. Understanding the reality that burn down charts tell us is a whole topic in itself that I will be talking through in a future article. My advice here is to ensure that the team sets an easily achievable goal for the next sprint. Encourage them to be conservative on their task estimates, to ensure they have enough time allocated for testing and deployment and to reduce the hours of tasks they are allocating to the sprint. Completing a sprint as planned is going to build their confidence and the client’s confidence as well.
The last thing for you to do is to go back to the client and explain the situation. You should admit any issues that are on your end, but don’t dwell on this. You need to clearly explain what the team will be working on, what the end goal is, what the next delivery sprint will include and when the client will see it. It’s time for you to give the client your word that the team will deliver and make sure they do. Between this meeting and the next sprint delivery you should talk to the client often, give them small updates and if something does go wrong, make sure you let them know as soon as possible and the impact it will have. In my experience a client will give you a lot of leeway if you keep them informed. You need to stay across the detail of the project for the next few sprints, joining the daily stand-ups and ensuring what the team is building is going to meet the clients expectations, remember you put your own neck on the line with the client.
In the height of our battle scene Winters calls in artillery support, he uses a specific format to communicate the requirements for the strike in a language the gunner will understand using words like “fire concentration Charlie”. It’s critical that when we talk or show something to the client you speak in a language that they can understand. At the conclusion of the sprint you want to ensure that the client is happy with the outcome. It’s critical that you work with the TC and the PM early in the sprint to ensure they have planned the sprint demo from the client’s perspective. Make sure they talk about real use cases and explain how the features they have developed will actually deliver value to the business.
Coming into a project that is off the rails is one of the most challenging situations for a technical manager. Utilising a structured approach to define the problem or problems, to prioritise a plan of action that the team can agree on and to accurately estimate and deliver to a timeline will increase your probability of successfully turning the project around. Just like Lieutenant Winters, you need to take control of the situation and instil a sense of calmness and structure that will ease the pressure on the team and allow them to focus on the problems at hand and never forget to communicate widely and communicate often.
* Band of Brothers Crossroads of the Island Charge watch it online at https://www.youtube.com/watch?v=DOSvLWK5Z2A
댓글