Easy in theory, difficult in practice

Whether you have taken a foundational project management course which covered practices for predictive approaches or you were studying to take the PMP exam, you are likely familiar with schedule network diagrams. However, like many tools and practices in the PMBOK framework, just because we learn about them doesn't mean we will use them.

If you skip creating network diagrams, you could miss out on these benefits.

1. Building a network diagram is a fun team building exercise. Whether you do it on a white board using sticky notes or in a virtual collaboration platform, it provides a good opportunity for team members from different functional areas to figure out how we are going to get from start to finish.
2. It increases the team's buy-in to the project's timelines. By contributing towards the creation of the diagram, there is a greater sense of ownership in the final schedule.
3. It captures the scheduling logic in an easy-to-understand and explain fashion. Walking a stakeholder through a detailed Gantt chart, especially when there are multiple parallel network paths can be an exercise in frustration for both you and your audience!
4. It makes it easier to notice if you have a scheduling error. Once a few hundred tasks are entered into a scheduling tool and dependencies have been added, locating a missing activity can be like trying to find the proverbial needle in a haystack. On the other hand, navigating activities in a network path on a network diagram is more intuitive and missing activities and unnecessary or missing dependencies can be identified quicker.
5. It makes schedule creation more efficient. If you have ever witnessed a project manager struggling to enter data into a scheduling tool in front of their team, you will appreciate the reduced waste which is generated when the same project manager can take a completed network diagram and enter it offline into the tool and then share the final product with the team.

In some situations, skipping a network diagram might make sense.

If your project lends itself to a fully adaptive approach and work item sequence is changing frequently, while you might need to incorporate an understanding of dependencies when prioritizing the backlog or queue of work, a network diagram would get out of date very quickly. If the project is simple and has a minimal number of network paths, a network diagram might be overkill. Finally, if your project is very similar to a historical one and you can reuse the schedule from that previous project with minimal effort, a network diagram might be unnecessary.

But other than these situations, the benefits of producing a network diagram as the primary input to your project schedule will be well rewarded.

For those of you who are Do It Yourself (DIY) pros, you may not consider this a significant accomplishment, but not usually being a DIY'er, I am quite pleased with having installed ceramic wall tiles for the first time ever. In this particular case, the tiling was backsplash for our main bathroom sink area. Once the work was completed, a friend who had provided a lot of hands-on assistance and tool support suggested that there might be some delivery lessons I could harvest from this home improvement project so thanks Brendan for inspiring this article!

Measure twice, cut once

Part of the project involved the installation of trim at the left, right and top sides of the backsplash area. Having purchased an eight foot length of aluminum trim, we needed to cut it to fit and we needed to use a mitre box to get a 45 degree angle so the top left and right corner pieces would join cleanly. Although my friend measured the lengths and used that information to prepare for the cuts, he had me double-check the measurements on the trim length to confirm they were correct before starting to saw.

When you face a critical decision on a project, there can be a benefit in having your recommendation vetted by a trusted, independent party. While project decisions are made with imperfect information, this additional review can help to reduce the impacts of biases which you or your team might have.

Invest in good resources

My friend happened to have a half tub of premixed grout left over from his last project. When I checked the grout it was soft but fairly dry. While I could have tried to rehydrate it, this would have been a risky move as neither he nor I knew for certain how much water would need to be added. While there is some latitude for the consistency of the grout, adding too much water would have resulted in a runny grout which would run off and not set whereas too little would have resulted in a grout which wouldn't adhere well to the gaps between the tiles.

Given this, even though I only required a small amount, I chose to purchase a new tub. While it was costly, by doing so I was able to avoid one risk and had the confidence to do the grouting by myself thanks to the assistance of a few YouTube videos.

With projects, it can be tempting to work with what you can get with minimal effort and cost. Such short-term thinking might translate into longer term pain, so it is worth the effort to lobby for the right resources for those activities which present the greatest risk to successful delivery.

Keep your constraints in mind

My friend did not have a tile cutter and wanting to reduce the complexity and costs of the job, I needed to determine a tile size and backsplash layout which would work without the need for cutting. This constraint guided me to accept a stacked tile layout rather than a brickwork style.

Blue sky planning might result in a creative, ideal solution, but incorporating constraints ensures that plans are realistic.

While my project was quite small and simple, it still provided some useful lessons which could be applied to more complex contexts.

Regardless of what type of work your team does, work boards can be a helpful tool. But just because they can be helpful doesn't mean they are always implemented well.

The most common mistake is when teams don't keep their work boards up to date with the actual status of work that is being done. Increasing transparency is a great way for stakeholders to understand what is going on and to increase their level of trust in teams. But if the information being presented is out of date or inaccurate, it reduces the team's credibility and increases the likelihood of these stakeholders asking for separate, redundant status updates. When a work item changes status the work board should be updated immediately. For example, if the team has capacity to pull a new work item from their work queue, the item should be moved on the board just before work actually commences on that item.

Another challenge relates to whose responsibility it is to keep the board up to date. The moment it becomes the job of a coordinator or lead to do so, we reintroduce the overhead of having someone chase team members for status updates. I have seen Scrum Masters who will take time out during a daily Scrum/standup event to update the team's work board after a team member has mentioned that it doesn't accurately show the status of their work items. Everyone on the team is responsible for updating the work board based on the work they are doing.

If the work board columns are aligned with the roles of team members, that is not ideal. A work board's columns should reflect the progressive value being added to a work item till it is complete and very rarely would this evolution map cleanly to the team member's individual roles. The Goldilocks' principle also applies to the columns. Have too few, and stakeholders may not get sufficient visibility into work item status and work items might stall for longer than desired without impediments being addressed. Set up too many and it encourages silo-thinking on the part of team members and can result in increased work in progress.

Having a dedicated blocked column is also not a good idea. Blocked is not a normal step in the evolution of a work item and by moving partially completed work items over to a separate column it can affect flow as a natural tendency of a team might be to pull more work items from the queue rather than unblocking the stalled work item. A better approach would be to highlight blocked items within their active work columns.

The next sin relates to work item aging. Ideally, once the team has completed a reasonable number of work items, they will be able to determine what is a reasonable amount of time for a work item of a certain size to remain active. If there isn't some way for the team and stakeholders to see how long a work item has remained in an active column (i.e. something other than Not Started or Done), then it is hard to proactively determine whether it has been aging longer than it should.

Finally, cluttering a work item card with too much information increases the potential for stakeholder confusion and for inaccurate data. At the bare minimum, a work item card should contain the description of the work to be done, key dates (e.g. requested, started), whether it is blocked or not, and which team members are working on it. Anything beyond this can be helpful, but also increases the effort required for team members to keep information current and accurate.

Work boards can be a powerful tool to help a team visualize their work flow, but as always, with great power comes great responsibility.

A couple of months ago I wrote an article regarding quiet quitting by project team members. While there are many reasons why someone might choose to physically be present but mentally check out, I felt that there were a limited number of root causes. Similarly, there are many triggers for someone participating in the Great Resignation, but these can likely be traced back to a handful of reasons.

The topic of psychological safety is never far from my thoughts and I wanted to understand how much it factored into people's decisions.

I decided to run a one week informal poll on LinkedIn from those who had quiet quit or recently resigned asking them what was their main reason for doing so. I provided respondents with four choices: insufficient compensation, a lack of professional growth, low/no psychological safety and an other category.

Unfortunately, I only received thirty-three responses to the poll so it is by no means conclusive, but 42% chose the low/no psychological safety option with 30% picking other, 18% a lack of professional growth and only 9% indicating insufficient compensation.

The results would appear to support the theory that compensation is a hygiene factor. While everyone would like more, so long as we are being given fair pay for our work, it is unlikely to be the primary cause for checking out. The higher scores for professional growth also make sense from a Maslow's hierarchy perspective as those address motivation goals such as self-esteem and self-actualization.

Respondents who chose the other category provided reasons such as a lack of autonomy or poor culture.

But the underpinning for nearly all of these might be low psychological safety.

If a team member feels safe, they will not be afraid to lobby for greater control in their way of working, support for career growth, and increased compensation. They will also feel comfortable raising concerns about organizational cultural dysfunctions knowing that their peers and reporting manager will protect them from blowback. They will be more likely to adopt the mantra of it being better to beg for forgiveness than to ask for permission. They won't bear the daily emotional and mental burden of having to pretend to be something they are not.

A decade ago, Google's Project Aristotle identified psychological safety as the underpinning for improved team performance. Similarly, its absence might be the underpinning for quiet (or loud) quitting.

The term "technical debt" is familiar to many in the delivery world, especially those working on technology initiatives.

Ward Cunningham had originally used the well known concept of financial debt as a metaphor for the consequences of decisions made with imperfect or partial information. The term has been mistakenly used by some to refer to poor product quality resulting from teams cutting corners but that was not its original intent. For those of you who would like to hear Ward's explanation of how he came up with it, you might want to view this YouTube video.

A few days back, when responding to a LinkedIn post about fixed and growth mindsets, and what are the prerequisites for someone to possess a growth mindset, I felt the same metaphor could be used to describe the mental models and preconceived notions which we build up over time. Purposefully restricting where we get information shouldn't be considered "debt" so I'm focusing on misconceptions or blind spots which arise naturally.

Unlike financial debt, it is impossible to avoid knowledge debt. The human mind seeks to fill gaps in our understanding and our biases, past experience and anecdotal evidence are all leveraged to do this. What is important is whether we choose to pay down this debt.

To do so requires us to accept that we shouldn't be certain about anything. Once we have the humility to accept that, we are likely to be more curious about views which differ from ours and more open about learning from sources outside our echo chambers.

Here's one example from my past.

In my early childhood, I had decided that I did not like eggplant and that all dishes made from it were slimy and inedible. As such, till my twenties, I went out of my way to avoid eggplant. After I got married, my wife wanted to make an eggplant-based meal one day and I wasn't thrilled. Knowing that she generally had good culinary tastes, I was curious as to how she could eat eggplant without gagging and decided to humor her by trying some. Sure enough, I enjoyed it. Looking back, I can regret all the missed opportunities to enjoy eggplant parmesan, grilled eggplant, eggplant lasagna and other dishes, but at least I was able to do so from that time forward.

So how are you going about working down your knowledge debt?