I want to share one story that happened to me some time ago. I was working as a TPM on a program which required contributions from multiple development teams. I joined that program mid-term and started working with existent teams on deliverables. My goal was to implement a few key improvements into the existing system. We had multiple meetings with a few teams at once, discussed goals, next steps, and schedule. I was assuming that everything was under control. After some time, when it was time to check if the development of every ticket was on track, I figured out that one task was not ready. Moreover, it was not even scheduled by the corresponding team for any upcoming sprints and no ETA was available. After discussions with the team manager I figured out that our expectations were completely different. We were misaligned.
But what is misalignment? And what is alignment? And how can we build alignment?
What is alignment
Well, usually alignment happens when everyone knows what is the final goal of a program and what is their role in achieving that goal. We need to eliminate ambiguity as much as possible because it can cause harm later on.
To build alignment we need to ask and answer multiple questions.
The most important one is What do we want to achieve? We need to clearly paint a picture of the final result and understand what success looks like. We need to explain this to every individual and team involved in the program. We need to provide a way to measure success to be able to track if we achieved the goal or not.
The second question is Who will do what? Here we want to define responsibilities and make sure that everyone understands their role in achieving the goal. Every task should have a name attached to it and this person should be aware that he or she is accountable for it.
Third question is When do we need to accomplish this? Every task should have a deadline and, again, a responsible person should be aware about this deadline and commit to it. So we are not notifying people about deadlines, we are getting commitments from them. We need to make sure that they properly understand that we expect them to deliver results on an exact date.
After that, we need to understand What resources do we need to achieve our goal? Do we have enough resources? Do we need to allocate more resources? Do we need to purchase or rent any equipment, hire more people with specific skills, etc? If you don’t have enough resources, what is our Plan on allocation of these resources. And again, you need to define Who is responsible for executing this plan? Plan should have a name attached to it and this person should be committed to execute it.
The next step is to identify risks and prepare mitigation plans for them. It is important to identify any critical risks in advance to have a chance to be prepared for them. Not all risks will be necessarily realised, but it is important to proactively prevent them. It is super helpful if you will be able to integrate risk mitigation in the design of your system. So you will design the system in a way where it will avoid these risks.
One more important aspect is prioritisation because some tasks could block each other and be dependent on third parties. It is important to make sure that everyone understands the priorities and the order in which tasks should be completed.
And the last but not least topic is expectations. You need to make sure that everyone understands expectations from them, and that their expectations are correct.
How to identify misalignment
Since there is no such thing as a partial alignment it is very important to identify any misalignment which is building up. And how do you understand if you have misalignment? Well, you can’t look inside others’ heads, so you need to pay attention to anything that goes wrong. These symptoms could be delayed tasks, tasks implemented in wrong order, any missing communication, any tension inside teams. All this should trigger a question if we are still aligned. The main problem of misalignment is that usually it is detected too late when something is already going wrong so the earlier you will detect this the smaller consequences and problems it will cause. Even small misalignment potentially can cause huge losses. The later we identify misalignment the higher risks that some resources were spent in the wrong direction and it is crucial to identify misalignments as early as possible.
So when misalignment happens? Usually this happens when there are some changes in the program. These could be on-boarding of new talents, replacing managers, changes in scope deadlines or budget. Also lack of communications can cause misalignment.
Best practices for achieving alignment
So what are the best checkpoints where we need to make sure that everyone is aligned?
Obviously, the very first such checkpoint should be a moment when you join some program. This could be a brand new program or this could be a program which is already running. Usually it is a very good idea to make your own observations about the program, document everything, review these observations with the teams. So, you need to make sure that everyone understands the current status and next steps correctly. This will eliminate any potential misalignment which was built before you joined the program.
Here is an example. Once I joined a program where we were developing a small internal tool. Almost immediately I realised that there was a mess in alignment. Engineering team was claiming that they completed a big portion of functionality and delivered the minimum viable product. At the same time their internal customers were not using this product at all. Customers did not understand how to use it. Leadership was under the impression that nothing was happening and that nothing was developed at all. There was little to zero communication and huge misalignment had already built up. I’ve spent a few weeks collecting all pieces of this puzzle before I was able to write down the current status of the program, identify next steps and create a roadmap for a product. We discussed these findings and achieved alignment across all stakeholder. This was a crucial step which helped me to achieve alignment and properly step into this program.
Another good cheek point is when you’re about to approach any major Milestone. This is a good place to check if you are on the track and if you have any major problem which could cause delays for the program. Also, stakeholders tend to have some expectations about key milestones and they might differ from yours expectations. It is very important to properly communicate expected results from achieving your Milestone. For example, if you expect to deploy new functionality with some limitations, communicate these limitations clearly and in advance. This will allow you to manage expectations and avoid misalignment in the future.
Also, once such a milestone is achieved, it makes sense to align on next steps and next dates. Sometimes milestones are achieved with delays and if you don’t have enough buffers in your roadmap this can delay next milestones. If you foresee such delays, communicate them immediately to ensure that all stakeholders are aware about these risks.
Program risk management process is another place where you need to check the alignment. If you face any significant risk that could affect your schedule usually it is a good moment to initiate the proper communications to maintain the alignment.
On top of that it is worth it to align as soon as the program experiences any significant changes in scope, deadlines, budget or resource allocation. Obviously if you need to reduce the number of engineers or add some new unpredicted feature this can affect your schedule and you need to align these changes with all stakeholders. Overcommunication is very important in such cases.
And the last but not least checkpoint is your intuition. If you think that it is worth aligning on something, most likely it is. You are the person who knows your programs the best, and usually intuition is the very powerful tool which will suggest to you When you need to re-align.
Form of the alignment process
Okay, so now we understand when we need to initiate the alignment process and how to build the alignment. Let’s talk a bit about the form of this process.
My experience says that the best form for such an important discussion is a mix of in-person communication and something in written form. Something traceable and to which team members could return later and refresh details in the memory. For me, a written document works the best. Usually I prepare a document, which explains current status in detail, provide next steps and long term goals, describe challenges, opportunities and risks. All this is in plain english, very condensed information, nothing fancy. Document should be clear and there should be no ambiguity. Any potential ambiguity would play against your goals later on.
In addition to the document, usually it is a great idea to setup a meeting where your stakeholders can literally read, comment and provide feedback on this document. Please, make sure that every stakeholder provides feedback. Assume that no feedback means misalignment. Chase every stakeholder in the meeting directly or later via direct message, phone calls, email, etc and get feedback. Also, make sure that you have meeting minutes with the outcome of the meeting and send these notes to every stakeholder.
It might sound boring, but the great tool which helps to minimize misalignment are status reports. It is a good idea to send weekly updates to your stakeholders providing them with a summary about what happened to the program last week, describe current problems and your next steps to resolve them.
One time one engineer complained to me that he had a problem – status reports. He was required to send them but he treated them as a waste of time so this was like a problem in his perception. Ugh…. How typical and big misunderstanding it is! I had to explain to him that status reports are not a problem but an opportunity. Opportunity to align, opportunity to get visibility, opportunity to manage perception. Send me an email if you are interested in deep diving into this area and I will prepare a separate podcast on this topic.
Conclusions
Now we understand how to achieve the alignment. Let’s summarise.
- Building initial alignment is a heavy-lift task. But once achieved, it will be much easier to maintain alignment. Maintenance requires very little effort compared to building initial alignment.
- Once teams are aligned, will they stay aligned forever? No! Building alignment is not a one-time job. This is rather a continuous repetitive process which requires periodic health-checks and maintenance.
- Preventive alignment allows to avoid building up misalignment while it is small and cost of errors is small.
- How often do you want to re-align? As soon as the program experiences any change or when you feel that this is needed.
- Listed to your intuition. If you suspect that somebody might be unaligned, invest some effort and ensure that person or team are on the same page.
- The rule of thumb in program management is following. Overcommunication is better than lack of communication. You’d better send too many reports and do more alignments that might be needed, than drop the ball to end up in a situation where teams are doing something wrong and do not meet expectations of stakeholders.
Leave a Reply