Today I volunteered to help with an awesome event.
Taking small risks and failing fast is the best risk management strategy around.
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Why Risk Management Rocks
Categories:
Risk Management
Categories: Risk Management
|
The "It's All About Science Festival" was the first of it's kind in my city.
Since I love science and support the promotion of the public understanding of science, I volunteered to help out with the event.
I was just a grunt, volunteering my time and back to help get exibitors set up and carrying heavy equipment and tables for the displays.
Still, it's difficult to take my project management hat off.
In the process I was reminded of an important fact today.
Contingency Planning Is A Must
The venue was set.
Plans had been made.
Exhibitors had assigned tents to set up under, the food vendors were in a good spot, and when the public came to the event everything was set up for ease of access and flow of the crowd.
Had everything gone to plan, I probably wouldn't be writing this post.
But it didn't.
It rained.
We haven't had rain in a long time, we're in a drought. But it rained.
They Had A Contingency Plan
Sort of.
There was ample space inside to accommodate the majority of the exhibitions.
And that was good.
But that's where the contigency planning stopped *I think*.
This resulted in several key problems and lessons learned for the future.
I am not trying to blame the organizers, the event still went very well and they worked very hard.
But this is also an opportunity to reflect on lessons learned so the next event is even better.
Exhibitors Were Confused
There were no assigned spaces for inside the building. So exhibitors were confused and didn't know where to set up.
The resulting layout was not optimal in several ways.
First, exhibitors weren't clear on what the main entrance would be. There were several entry points possible.
Because they had moved from outside to the inside, we all hauled everything through a side door.
Many assumed this would also be the entry point for the public.
It wasn't.
Because of this miscommunication and lack of contingency planning, many exhibitors were set up in exactly the wrong direction.
When the public walked in, they saw the exhibition tables from the rear.
The user experience was 1) walk in 2) be confused about where to go
Food Vendors Were Isolated
Had this project gone to plan, the food vendors would have been set up in an optimal spot for the crowd.
Because we were now inside and food vendors had trucks they were selling from, they couldn't set up where the people were.
And now they were set up way on the other side of the building from the front entrance too, and where some of the larger exhibitors were still set up outside.
I pointed out that if we could get the food vendors to drive around to the front and set up, it would be a better situation for them and the hungry masses.
Alas, because this eventuality was not anticipated, other less mobile and huge exhibitions were blocking entry to the best contingency location for the food vendors.
So in the end this resulted in a hungry crowd. Many of them probably left prematurely to go get something to eat elsewhere because they never even saw the food vendors. And many were likely dissatisfied by the lack of available food and beverages.
And of course this had a major impact on the vendors' sales - making them dissatisfied and less likely to come back next year.
In The Moment
Although it could have been handled better with some planning, there were some bright spots.
Two of the exhibitors who hadn't moved inside were still set up outside.
Over on the side of the building away from the front entrance and flow of the crowd.
I saw them and also noticed two empty spots available right next to the front entrance where the foot traffic would be high.
One hadn't moved because he had a rather large solar panel display that had to stay on the parking lot, and I think the other was just too nice and didn't want to be a bother.
I tried to find the event coordinator to verify that it would be acceptable for them to move since the spaces were (apparently) open.
I was unable to find her, so I just made an executive decision.
I asked both of them if I could help them relocate to the two open spaces. They accepted, and we got everything hauled over to the new locations.
As a result, they had a massive amount of foot traffic and interest they wouldn't have otherwise gotten.
And we even got better southern exposure for the solar panels!
Lesson Learned: Risk Management Rocks!
I think many people don't do much contingency planning because they fear it's a waste of time.
After all if it hadn't rained that contingency plan would have been a waste, right?
Wrong.
That's like saying car insurance is a waste if you never get into an accident.
Being prepared for the most likely and most impactful risks is never a waste.
It's just good project management.
|
Posted on: July 28, 2012 09:26 PM
| Permalink |
Comments (2)
Take Small Project Risks To Avoid Big Ones
Categories:
Risk Management
Categories: Risk Management
|
Let me explain..
Vallidated Learning Through Small RisksI identify strongly with the Lean Startup concept of validated learning, and I think every project is just like a startup. Especially in the beginning, validated learning is much more important than just cranking out a product for the sake of it.
If you think your customer will love something and you have the capability of demonstrating it in a visual way very quickly, do it!
The learning you gain from the experience, even if the customer hates it, is worth it.
Avoid Creating Your Own Big RisksToo many project managers create their own large risk of producing a product no one will use.
That's the biggest risk of all.
Trying to avoid the small risks. Being afraid to make mistakes. Being afraid to be wrong.
These are the attributes that result in big risks. And the project manager induces these herself.
What ways can you take small risks proactively to learn more quickly and avoid the big risks?photo by Explore The Bruce |
Posted on: February 27, 2012 10:32 PM
| Permalink |
Comments (0)
The Power of External Dependencies
Categories:
Risk Management
Categories: Risk Management
| Sometimes, external dependencies want to make me shake my fist in rage.
But that's not how it should be. A critical factor when planning a project should be a risk analysis, not only for the project as a whole but also for individual autonomous groups within the project when there is collaboration going on between the following:
Emotional ResponsesHowever, here's what will happen when you propose a risk related to a depedency external to your immediate group:
Let's get past the emotional responses now. We want to openly acknowledge areas outside our control, that is the important thing. Transparent StructurePerhaps you don't carry these external dependencies as risks (although I would) but use them to build a structure into your plan which makes these dependencies obvious. Making these external dependencies transparent would be a part of my mitigation plan in the risk management process. Why make them transparent? A primary reason is so that if an external group's deliverables slip on the schedule and you are dependent on those deliverables, a red flag is triggerred and an appropriate response can be acted on. One reason why I advocate carrying these touch points as risks is precisely so that a risk response plan can be formulated ahead of time, and if the risk becomes an issue you can act on a solid plan that wasn't just thrown together in the heat of the moment. ExampleIf a vendor is developing something new that is an input to your development process, try to structure the work so that the pieces dependent on the vendor are separated from other work. You might plan a separate release just to incorporate the vendor's new technology. If you don't do this, late or incomplete deliveries from the vendor will get pieced into your development life cycle and reworked, reworked, reworked as new updates arrive. If you call the external dependent deliverable separately in your schedule, there is something you can point to if and when things go bad. This is not to place blame; in my book blame has very little use. No, it's to make it crystal clear which group needs to have their feet held to the fire so we can deliver this project on time. |
Posted on: September 29, 2010 08:05 AM
| Permalink |
Comments (0)