Playing a board game without all participants having a consistent understanding of the rules is a frustrating, time-wasting experience.
The same is true when a team starts to work together for the first time. Whether it is done proactively when the team assembles or is done as a reaction to unhealthy conflicts, having a basic set of working agreements can help to accelerate a team's transition out of the storming and norming phases of development.
While we often think of working agreements as covering team member interactions such as how to deal with conflict, the communication methods to be used for different situations or logistics for regular meetings, a good set of ground rules will also cover the teams way of delivering value. For example, the Definition of Ready or a Definition of Done are two examples of delivery working agreements.
But how do ground rules get defined?
In my past experience, I've encountered four scenarios:
Most of the teams I've witnessed fall into one of the first two scenarios. Highly mature, self-managing teams will transition from the second to the third scenario. I've rarely seen the fourth scenario, and mostly that was with teams who had novice leaders.
I ran a one-week poll in PMI's LinkedIn Project, Program and Portfolio Management discussion group as well as the ProjectManagement.com community. Unlike some of my recent polls, this topic drew a large number of responses: 236. 53% of the votes were cast for the leader as a facilitator, 22% for the team defining rules on their own, 16% of respondents indicated that no rules were explicitly defined and the remaining 9% were the team leader defining the rules.
It is encouraging that three-quarters of the responses indicated some degree of self-organization and team autonomy, but that still leaves a quarter of teams either having rules imposed which might reduce their motivation or having no rules at all which increases the likelihood and duration of interpersonal conflicts.
"Rules and responsibilities: these are the ties that bind us." - Neil Gaiman
The PMBOK® Guide, Seventh Edition defines a Work Breakdown Structure (WBS) as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables".
While this definition provides a good understanding of what a WBS is, it doesn't provide guidance on how to organize the structure of a WBS. This is helpful as it provides flexibility for teams to determine what is the most appropriate means of doing so for the context of their project.
Although there is an infinite variety of projects, I've found three approaches used by most teams who develop WBS's:
A deliverable-oriented approach helps to focus the team on everything required to complete each deliverable without worrying at that stage about who does it or when it would be done. This can work well for projects where the full scope of a project can be decomposed early on, but can be challenging when a rolling wave approach is taken unless there is a clear identification of planning packages which need to be elaborated at a later date.
A phase-oriented approach works well with a rolling wave approach as the team only needs to focus on what will be completed in the upcoming phase. However, there is the risk that the team might miss key scope elements for specific deliverables as they won't be focusing on decomposing a single deliverable at a time.
A responsibility-oriented approach works well when there are multiple stakeholders and there is the need to have a clear segregation of responsibility for planning and execution between them. It suffers from the same risk as the phase-oriented approach, but more severe as there is the potential for deliverable sub-components to be assumed by each stakeholder to be the responsibility of another.
I ran a poll in PMI's LinkedIn Project, Program and Portfolio discussion group as well as the ProjectManagement.com community to gauge the distribution of usage of these three approaches. Out of the combined 141 responses, 57% were using a deliverable-oriented breakdown, 28% used a phase-oriented approach and 9% used a responsibility-oriented one. The remaining 6% indicated they used another approach but when I reviewed the comments those participants had submitted, it seemed that they were just using a combination of these methods rather than something entirely new.
While the WBS is commonly-used tool with projects following a predictive life cycle, this doesn't mean that those following an adaptive one can't benefit from it. If we consider a user story map, it is just a WBS constrained to two to four levels and developed in a progressively elaborated manner. With a story map, the structure might be persona-oriented or theme/capability-oriented.
Regardless of how your team chooses to decompose the scope of work on their projects, a WBS or a variant thereof should be considered as a valuable tool in their toolboxes.
In a project-oriented structure where the project manager has people management responsibilities for their team members, it is expected that an individual's performance on project work is the primary basis for their formal (HR) evaluation. But in a matrix structure, formal evaluations get carried out by the functional managers to whom the team members report to.
This can generate a number of risks, especially when the team members are spending the majority of their time doing project work including:
When HR policies require functional managers to seek input from the project managers whom their team members worked with, and project managers are required to provide objective feedback into the formal evaluation process, it mostly eliminates these risks.
But this is not something I've run across frequently.
Alternately, it is possible to address the risks by having proactive functional and project managers who will respectively request and provide feedback without being mandated to do so.
And even if the functional managers are disinterested in hearing what the project managers have to say about their team members, some project managers will provide the feedback unsolicited to the functional managers, or at worst, only to the team members, leaving it to the team members to bring that feedback to the table during formal evaluations.
The common thread across these choices is the demonstration of a proactive leadership stance by the project managers. However, if a project manager isn't interested or they've had their wrist slapped for doing so in the past, team members receive no feedback which increases the likelihood and impact of the risks being realized.
While I've witnessed project and functional managers engaging in all of these approaches, I wanted to bring this to a broader audience and did so by conducting a poll within PMI's LinkedIn Project, Program and Portfolio Management discussion group as well as the ProjectManagement.com community. The poll question was simple: "Do you provide feedback to managers about their team members' performance as an input into formal evaluations?"
The poll received 95 responses, with the following breakdown of responses:
While I do find it encouraging that the vast majority of project managers see the value of providing formal feedback on their team member's performance, it is unfortunate that almost one out of five project managers doesn't.
While this is bad for the team members, it can also hurt the project managers, especially if other project managers working with the same team members do provide such feedback. In such cases, when a team member has to juggle multiple, competing projects, which project manager is likely to be given a higher priority?
Ken Blanchard said "Feedback is the breakfast of champions" so do you want to deprive your team members of the most important meal of the day?
One of my parents' sayings which used to irritate me when I was much younger was "Act your age!". In those days, it was usually a critique of some immature behavior or action on my part.
As project managers, we usually are "acting our age" but might there be some benefits in channeling the child within us?
See the forest from the trees
Professional magicians sometimes have difficulty in fooling younger children with their magic tricks. While an adult can be easily misled by sleight of hand, small children haven't learned to focus their attention on a single thing for long and are more likely to witness the magician's misdirection.
On our projects, it can be easy to get tunnel vision.
A critical issue or a variance in a key constraint might command all of our attention but we could end up missing something else going on which could cause us bigger problems down the road.
Ask "Why?" (or "Why Not?")
For parents, one of the less endearing traits of many small children is their incessant questioning of each and every decision. Through a combination of ignorance and a belief that anything is possible, kids are seldom content with the response "Because I said so".
As we get older, we are conditioned to accept what we hear, especially when it comes from a respected source.
Asking "Why?" or "Why not?" is a great way to surface invalid assumptions and to challenge long standing practices that have ceased to be valuable.
Most of us have heard the saying "Curiosity killed the cat". But not everyone is aware that the full saying is "Curiosity killed the cat, but satisfaction brought it back".
Kids are curious about absolutely everything and will go out of their way to experiment and explore. As we mature, we create boundaries for ourselves. John Cleese's line from Silverado "Today my jurisdiction ends here" could be the mantra for many of the project managers I have met.
But such behavior, while safe for us, might reduce the creativity of our team and, like not asking "Why?", might prevent us from improving project outcomes.
If there's one thing which small children will prioritize, it is having fun. As we get older and our responsibilities increase, we lose sight of the importance of having fun in the work we do. While there are always going to be challenges with projects, seeking opportunities to make our work enjoyable will reduce our stress and increase the engagement of our team members.
So when managing projects, its okay to NOT act your age!
When we consider the benefits of non-solo working approaches such as pair programming or mobbing, the ones which normally come to mind are related to improvements in the speed or quality of delivery. The old adage "two heads are better than one" applies as we are usually able to get more work completed faster and with fewer defects. And by injecting variety by having participants alternate between different roles frequently, we also reduce the likelihood of fatigue.
But an HBR article this week on the topic of disengagement caught my attention. The author suggested that finding someone to hold us accountable increases the likelihood of our completing an activity. She highlights the benefits of body doubling where we work in the physical or virtual presence of another. By working with someone as opposed to by ourselves, it reduces the chance of procrastination and distraction.
While I hadn't thought about this before, it makes perfect sense. By pairing up with someone else who can see what we are working on, it is a lot harder for us to tune out. The discussions we will have with our partner will also help to keep us focused and alert so long as both of us are not likely to get distracted by the same thing - this is where strategic pairing where we pick partners based on diversity of thought and background might help.
But without psychological safety, we will be less likely to explore creative ways of getting the work done and we might also lack the courage to provide direct, compassionate feedback to our partner. This is quite likely when the people we work with are at different levels of seniority, experience or influence than us.
Many of the same practices which apply to building psychological safety within a team could be applied in the context of pairing. We could take some time before we start to work with a new partner to define a few ground rules for how we will work together including how we will provide feedback. At the end of a pairing session, take a few minutes to share our perceptions of how the session went and what we might want to adjust going forward. And solicit and be willing to share our working anti-patterns so that we can watch out for one another.
So while there are many benefits to be gained by engaging in non-solo work, psychological safety is a prerequisite for realizing most of them.