Three common project hazards - ignore at your own risk

I was cycling through Southgate the other day and I started thinking about the instinctual risk profiling that I am required to conduct, while pedestrian dodging that treacherous stretch of shared pathway. In my mind, people are placed into risk categories based on the probability that I will hit them. Kids and groups of tourists are highest risk, followed by couples, single tourists and other cyclists, whilst the lowest risk are individuals (preferably in suits). Based on these categories I control my distance and speed while navigating through the maze.

If this kind of activity is second nature when riding a bike (or driving a car), then why do we so often ignore it or pay it less attention than it deserves in a project context? Oft-perpetuated fallacies are that all risks are bad or that we should try to reduce risks wherever possible. A common definition is that a risk is an uncertain event, which, should it occur, will have an impact on a project - this may even be a positive influence.

I hereby present some (bad) project risks of which I recommend thoughtful consideration:

The ‘A job is for life, not just for Christmas’ days are over

I’ve lost count of the amount of projects I’ve been involved with where key stakeholders have left the company prior to completion. With this departure a whole lot of intellectual property is also often waved goodbye, timelines are thrown out the window and worse yet, adequate attention is no longer given to the project.

In order to mitigate against loss of IP internally, Salsa uses a collaborative project management tool and ensures that it is used for all written communication and notes are kept for verbal, in-person meetings.

I cannot recommend strongly enough that an internal audit trail is kept of all key decisions and the rationale behind them. Formulate a strategy for knowledge transfer and ensure that the leaving individual is sucked dry of all their project knowledge.

Remaining staff are often left with the new burden of project responsibilities in addition to their existing full work schedules. This will place those project responsibilities at higher risk and can lead to delays and worst case, complete neglect. Consider an exception plan to bring the project team back to its optimal capacity.

Mid-project changes - proceed with caution

Salsa executes a detailed scoping process designed to capture the key requirements and facilitate their realisation in the most efficient and effective way. There is often significant design, functional and technical considerations that have been analysed and scoped to arrive at the recommended solution.

Changes requested later during the project lifecycle have a higher risk attached to them, as they have often not had the same level of scrutiny applied, as would have been the case during scope. For example, a call-to-action button may now appear to be better served higher up the page, but how does this affect the aesthetic of the page? Is it technically possible? What impact will changes have on the project cost and budget?

More people involved = more time required to reach agreement

Consider the number of hoops that you just need to jump through at certain periods in the project - some people may call these ‘meetings’ or ‘approvals’. Nothing delays a project like trying to schedule a meeting for 5+ stakeholders or waiting for 10 people to sign-off a design.

Also, seemingly non-critical delays in the early part of the project can come to a head during key decision making moments. In order to achieve the best possible outcome, as much time as possible should be given to highly prioritised items and not trivial issues.

Lastly, this may be one of those ‘nice to have’ ideals, but delegation is amazing. Choose a spokesperson and charge them with the responsibility for a group of stakeholders. Of course they will need to have buy-in from their clique, so it’s probably best if the representative sits towards the top of their hierarchical tree. If a committee of three (or more) can never agree, play some Rolling Stones ‘You can’t always get what you want’ in the background and explain to them the difference between wants vs. needs.