Decision Making on a High Pressure Project

This is a guest article by our own Luke Wassenaar

Extracting valuable content without disrupting delivery.

As a junior project deliverer sent to the other side of the world to implement a project, there was a long laundry list of situations running through my head surrounding what could go wrong. A flight from Australia to the U.K. gives you a lot of time to think! Although more senior deliverers would be accompanying me sporadically throughout the four-week implementation period, I was to start the first half-week alone.

I knew what I was doing; it was not the first project that I had been on! However, when a senior deliverer came on site, halfway through week one, he had questions about why I was doing certain things. For example, why was I sending a meeting agenda to the key management staff before the meeting, and not creating the day’s agenda with them (co-authorship)?

Using co-authorship and getting key management input into the day created a sense of investment for the management team. They had been involved in the creation of the agenda, so were partially responsible for ensuring that everything set for that day was completed. It was a great piece of advice from the expert and, although a small micro-change in the day, it had a large effect on the success of the project.

There is a lot of valuable content that is kept inside experts’ heads that makes them highly valuable to a business. There is immense value in getting this information out of the experts’ heads and onto paper, to use the information and train others to be just as effective.

Basic delivery information is often turned into consumable content, such as manuals and checklists, but it is the minor details and decisions in key situations that differentiate the expert deliverers from everyone else. You can only access these acute details when experts are undertaking a delivery themselves, as the context of high-value delivery actions is often difficult to remember at a later date. For this reason, we want to ensure that this accurate information is not missed, and that we have it recorded. However, when delivering with a client, there is pressure to deliver what the customer wants, rather than using the time to create learning content for ourselves.

There is a decision that needs to be made. Do I stop to create learning materials? Or do I stick to the pre-planned implementation and meet the required deadline? The latter results in accurate insights being left ‘on the table,’ so to speak.

There is a saying, “If it is worth doing or saying twice, it is worth never saying at all.” In other words, if we can take the time to create some content now, we will save time in the future by not needing to continually explain the same thing. But should the customer have to suffer in the process?

The BBIT tools have been helping capture valuable delivery content for years. These tools provide a consistent framework to gather the key effects, needs, and actions that experienced deliverers do subconsciously (and junior deliverers never do). These tools capture the skills being performed by an expert and the context of the situation. We can use such tools ‘just enough’ to capture the skill and context, while still delivering the intended effects immediately, filling out the remaining tool or framework at a later stage.

Alternatively, the tools can be used to capture multiple conflicts that junior deliverers experience when implementing: writing down the choices they must decide between every day, not letting it stop the momentum or plan they have for the day, and providing the opportunity to fill out the tools later to present to a more senior deliverer to analyse and give feedback on.

Using one of the core BBIT tools, the cloud, we can display the conflict we have described below.

We read the cloud as follows:

1. Why is it so difficult to extract valuable delivery content without disrupting delivery, when delivering on site?
2. In order to extract valuable delivery content without disrupting delivery, we must maintain momentum during the day.
3. In order to extract valuable delivery content without disrupting delivery, we must ensure accurate content is not missed.
4. In order to maintain momentum during the day, we must deliver and create content afterwards.
5. In order to ensure accurate content is not missed, we must create content and then deliver using that content.

Instead, experts use simple tools and structures; just enough to deliver immediately, tidy up later.

The greatest use of BBIT tools EVER!

After the initial advice from the expert, and some discussion, it was identified that, throughout the days on site, there were many instances where I was faced with decisions that, intuitively, I did not know how to make.

As I came across these decisions, I started to note the two actions that I was having to choose between. During the day, I would do the action I thought was best at that moment, or if I were very unsure, I would ask the opinion of the expert who was aiding me at the time. However, it was the acknowledgement and recording of these decisions that led to valuable delivery content being created and noted down, not only for myself in future, but for potential future deliverers.

These basic decisions are the ones that very often an expert deliverer does not even think about because it has become second nature to them. Because of this fluency, expert deliverers do not create any delivery content around these micro-decisions/problems, as they do not think it will be useful to new resources. They internally think that it is glaringly obvious what should be done. Yet, that is not necessarily the case for someone new. By having me note down all the decisions that I was having to make throughout the day, as a junior lead deliverer, they got an insight into just why ‘new’ deliverers were not getting the results that they, as experts, did and could identify what was missing from the learning and delivery content that was currently being used to teach new people.

One of the major decisions that arises when delivering a project on the other side of the world is how to communicate with important stakeholders. The stakeholders do not know what is happening, so I should keep them updated. However, I do not want to overwhelm them with everything that is happening on the project because they are unlikely to care. So, I have a cloud. See below.

Initially, I was sending an email update to certain stakeholders once a week and updating them on how the project was going and the times that I expected certain milestones would be completed.

After going through my cloud in one of the middle weeks of the implementation and communicating using templates and proven tools, the expert identified what they would have done. Once this had been identified, I then built an email template, highlighting a range of different areas, such as risk status, overview, project update, intervention, actions necessary, etc. It was easy to fill in, as the deliverer, but it also gave the stakeholders an easy-to-digest update of how the project was going.

The template was sent out to stakeholders twice a week. Stakeholders could easily look at just the risk status (which was one of the first items on the template), and from that make a judgement call as to whether or not it was necessary to look over the whole update or deem themselves satisfied that the project was under control and happy to leave it to run its course.

By using this method, we avoided having to carefully craft messages, as we just filled in the pre-created template. We were also able to give accurate updates to the stakeholders to make it clear that the project was under control. If things were not going to plan, we could state what we were doing on site to ensure that we were getting back on track quickly.

This is just one example of how the use of the BBIT tools passed on knowledge from an expert to a more junior deliverer, increasing both the expert’s delivery skills and the junior’s reputation in the eyes of important stakeholders.