One powerful way to destroy or limit a team is to add constraints that aren’t really part of the problem they are trying to solve. Bringing in fixed ideas about who you represent, how you do things or what you deliver causes friction and gaps in the team structure.
Even if just one team member has a fixed immovable idea, it can be a powerful limitation to the team’s performance, if that person exerts this idea consistently into the team’s activities.
Most projects already come with enough constraints without adding new ones ourselves.“When we’re all in a lifeboat at sea, with water coming in over the sides, I don’t need people arguing whose job it is to pick up a bucket and bail.” – Adam Russell (1998)
It starts with perspective
There are usually two extremes when it comes to flexibility for most professionals.
At one end, you have those that see themselves as joining the project team to jointly solve a problem. In that case, they use their personal and professional skills and tools as appropriate to support the team’s attempts to solve the problem.
At the other end of the spectrum, you have those that see themselves exclusively as a role or skill set, so they approach each problem as a chance to exercise the processes, tools and concepts of their profession.
If we unpack the latter extreme, we will see some common perspectives that I’m sure you’ve experienced in your projects.
Departmental representative perspective
This perspective is one where the project team member aligns their thinking, actions, and contribution with the needs and wants of their department, overshadowing or overriding the interests of the project.
Have you ever been in the situation where you have informally engaged a representative of a large function/department/team to participate in the project, only to be told many weeks/months later, after active participation by that representative, that their group has not been formally engaged?
Early in my career, it happened to me. I had learned enough to engage a number of different teams as early as possible, so that they could do all the estimates and impact assessments needed to put together a budget.
After 4 weeks of meetings and workshops, I requested each representative to prepare initial estimates. One representative’s response was shocking, “Oh no, we can’t do that – you haven’t engaged us. You have to fill in this online form to request formal engagement. This request will go to a prioritisation team, who will assess your request and make a resource assignment if you have all the necessary inputs. But you don’t have the right documents yet. After you do, whoever you get, because it won’t be me, will have to write an ‘Impact Assessment Requirements Document’, which will take about 6 weeks to complete.”
That said something about my inexperience in not clearing this process up front, a mistake I never made again. But what it said more to me were the expectations of the departmental representative. She was happy to participate in the team’s activities, but was not really part of the team.
Another common situation is someone who sees themselves only as a person assigned to develop a standard deliverable.
I have worked with many Solution Architects over the years, and they generally fall into the two extremes that I described earlier. Typically, a Solution Architect will be someone who sees their role to contribute:
- The best technical solution to the team’s problem. They participate as a team member and see themselves as the “owner” of the end-to-end technical knowledge for the project team. They readily assist as the technical representative in discussions with other technical teams and vendors. They also negotiate the solution architecture with all impacted technical teams who have to build the solution.
- A “Solution Architecture Document” that meets a range of corporate requirements: format, architectural compliance, and content. This type of person tends to operate independently of the team’s processes: doesn’t usually attend regular team meetings; can be hard to engage in general technical discussions with other technical teams; and sometimes develops a solution architecture that is not acceptable to the technology teams who have to implement it.
The second type is the “deliverable perspective”. The problem with the deliverable perspective is that it is executed “outside the team” construct, which heavily affects the team from forming into a cohesive unit.
Of course, the behaviour project managers should be looking for is the first type.
Process representative is the third common perspective.
This perspective is commonly found in the way business analysts analyse requirements, project managers run projects, and testers run the test function.
People who operate from this perspective place great faith in the processes they have learned and the results that the processes produce. They see it as their responsibility to operate these processes as fully and faithfully as possible. By doing so, the results can be reliably and repeatedly achieved.
The problem with this perspective is that the “real world” doesn’t always have the required conditions that are pre-requisites for the processes to work. The timing, in particular, may not serve the project’s goals, and depending on the process, participation by other people may be blocked or limited by the lack of specific knowledge, access to systems, or any number of other reasons.
How do we promote the team perspective?
At the end of the day, we want all the knowledge and experience that a team member may possess, but we want it aligned to the goals of the project. This is the team perspective.
It might not be possible to completely detach a person from their job function, departmental expectations, or professional training. But we can help them understand the team perspective and help them with dissonance or clashes that may occur between the team perspective and their other perspectives.
If a project team Charter had been clearly defined, many of the issues from the above examples would have been found earlier, where there was time to handle the situation with minimal effect to the project outcome.
Team Charter Clause #4: I am not a job title, a deliverable, or a process
At the end of the day, the simplest approach to promoting the team perspective is to simply state the expectation in or near the beginning of the project. And this is the purpose of Clause #4.
I join the team with my own specialities and domain expertise.
I may have skills that are unique to the team, but this doesn’t mean that they must be all used during my assignment. I agree to exercise my skills (unique or shared) only as required to achieve the team’s goals.
My job role may be a member of a department or organisation, which may have specific deliverables that it values or processes to follow. Executing these deliverables and processes are not my purpose in the team.
If the team’s goals require these deliverables or processes, then I can offer value in my knowledge of them. But they don’t “come with the package” of my membership with the team.
I share skills with other members of the team. My title, profession or departmental origins will not prevent me from utilising any of my skills or experiences to contribute to the team.
I agree to “play my position” within the team, but will be flexible to support and attend to the team in achieving its specific mission.
I will contribute fully across all team activities as they are needed.
What are your thoughts on the objective of this clause? Do you have any suggestions for modifications to the wording?
What do you think your team’s reaction would be to this Charter if you introduced it to your current project(s)?
We’d love to read your comments and thoughts, so please use the area below the article to provide feedback.
If you like this article, perhaps you’d like to be notified when there are more.
Subscribe to the AdamOnProjects Mailing List!
All the Principles