4 Key Elements to Create Better Alignments with a Team
Have you ever had any experiences delivering a work and turned out to be not what the stakeholder expected? Have you ever run into a situation where your colleague delivered you work that didn’t meet your expectations?
This is a very common scene and, in my experience, it happens because of miscommunication and misunderstanding about the project. My observation is, most likely this happens because projects are handed over as a to-do list. The person who needs to perform the work is not part of the defining phase of what needs to be done. So the person who receives the project has to interpret best of their knowledge and execute the work. If the outcome of the work aligns well with the expectation, that’s great. Also the longer you work with the same people, the expectations are easier to be understood without talking in detail. But this also has a risk. What if a new person joins? The communication and dynamic changes very easily and misalignment can happen.
What’s the impact of this misalignment? It requires more time, more frequent check-ins and discussions. So how do we align better? I’ve found a better approach that can mitigate this risk and create an alignment by structuring the 4 key elements of a project.
It has been very helpful for me to clarify my own projects as well as projects with others that I have to delegate. More importantly, this framework works very well because it generates active conversation with the team members. It helps enable the alignment established together with the team, instead of spending time creating a to-do list that gets handed over to someone else. Before I get into the detail, here are some positive outcomes that you can expect from this framework:
- Fewer meetings
- Clear ownership
- Employ everyone’s creativity to get the job done
Here are 4 elements and definitions of each element.
- Timeline: When this project needs to be done.
- Resources: People who are working on this project. Resources can mean different things, but in this case, it means people who need to execute the work.
- Scope: How big the project is.
- Quality: What level of completion or deliverable type.
In order to explain these elements, here is the example scenario:
Manager: “John, can you finish the design for the feature X by next week?”
John: “I don’t have any bandwidth by next week. I’m pretty busy with project A.”
Manager: “Let’s discuss then what we can achieve. What’s the scope and quality do you think we can achieve if we have to deliver a design by next week for a stakeholder meeting?”
John: “We can probably deliver wireframe to explain the design and if we only cover the feature for user type A, but not user type B which requires additional functionalities”
Manager: That sounds good, the purpose of this stakeholder meeting is to introduce the idea of a new feature, so wireframe and covering the key persona A would meet the initial goal.
Before going into each element, it is important to think about the priority of these elements first. For example, do we have a definite timeline that we have to deliver our work? Or do we have to proceed with this project with a very specific person on the team because he/she is the only one with that specific skill? How do we prioritize these elements effectively?
Sometimes it is obvious which one is the highest priority, but sometimes it can be very difficult to figure out. Prioritization can be also difficult because it is often not easy to quantify. When prioritization is difficult, it is helpful to think about the opportunity cost to guide your decision.
In the example above, a manager prioritized the timeline over quality and scope. Timeline is the gain and quality and scope is the cost in this example. In this example, timeline is the definite priority because it is already planned and involves stakeholders. However the quality and scope can be adjustable to meet the meeting goal and lowering the prioritization of these items is the cost in this case.
As you prioritize these elements, you discover which elements are pre-defined. Oftentimes I would have to define a timeline based on the larger plan and let the team member know. In my work, resources (the people who are doing the work) is also something that is often pre-defined. If there are multiple people collaborating on the same project, then it is important to let the team know there are multiple resources for the project.
The purpose of clarifying the predefined elements is to create a clarity on which elements can be discussed further. Take a look at the following example.
“John, can you finish the design for the feature X by next week?”
In this example, John is the resource and by next week is the timeline. Now, the underlined text “finish the design” is the scope and quality. If John is very busy with other tasks, he may ask “Can we do it by week after?” or he may say “No, I don’t have any bandwidth by next week.”
If the timeline is negotiable, you can let him know that it is possible to extend the deadline. If the timeline is not negotiable, you can get into further discussion with John asking him what he can complete by the timeline. This is the conversion topic to define scope and quality. If the timeline is the most important thing to achieve, it is important to define the appropriate scope and quality. Let’s look at the conversation again.
Manager: “John, can you finish the design for the feature X by next week?”
John: “I don’t have any bandwidth by next week”
Manager: “Let’s discuss then what we can achieve. What’s the scope and quality do you think we can achieve if we have to deliver a design by next week for a stakeholder meeting?”
John: “We can probably deliver wireframe to explain the design and if we only cover the feature for user type A, but not user type B which requires additional functionalities”
Manager: That sounds good, the purpose of this stakeholder meeting is to introduce the idea of a new feature, so wireframe and covering the key persona A would meet the initial goal.
Do you see the scope and quality? “Wireframe” is the quality of the deliverable that is a lot less work than visually completed design. “Covering only the user type A” is the scope. The full-scope of this feature might be for both user types, but by clarifying the scope decrease, the decision and expectation becomes a lot more clear between John and the manager.
I hope this framework helps you align with your team too. What’s great about generating the conversation like this with team members is so that your team member can plan and decide what s/he can do to execute the work. It will help create not only the clarity of the project and expectations, but also the sense of ownership and motivation for your team. Creating a sense of ownership and motivation elevates the quality of the work. This sense of ownership and motivation topic relates to the book “One-minute manager” that I am planning to write in the future blog. If you have any other useful ways you use to communicate and create alignment with your team, please feel free to comment.
