Project Management Central

Please login or join to subscribe to this thread

Topics: IT Project Management, Risk Management
How to identify risks?
Network:553



I have seen this with almost all the projects that programmers (developers, testers, architects, etc) do not like highlighting the risks well in advance. This becomes a major challenge.
During stand-ups I do prefer asking what risks do you see. Sometimes, it takes lot of time and effort to push them to speak up.
How can I ensure that all the internal stakeholders and participants do highlight the risk well in advance that we get ample time to resolve those?

In one such project, I did think through and found out one major risk which could put the entire project delivery at stake, but everyone else jumped in to say it is not that a major risk and can be avoided.
Later on, it became a road-block.
At that moment, I could have gone back and stated I did highlight this but that would not have had any impacts.
I did highlight this in retrospectives.
Developers, architects did concur and assured they would let us know the risks well in advance.
But I still do not see that happening.

Is there a different and proven way for finding out the risks pretty early in the process?
Sort By:
Network:221



Some recommendations you may find useful to improve the risk identification:
- establish an open and trusted environment for your team members, that allows for honest communication
- reduce complexity though slicing of tasks in manageable tasks (sprints) that provides transparency on project progress and state of the artifacts
- allow for sufficient time to "think", meaning starting late allows to see risks more clearly and how to mitigate
- establish a project mindset and values for all team members that includes an understanding that continuous risk identification is a responsibility of each team member
- Do not focus only on stand-up meetings asking for risk. Embed this "risk questions" in your daily ongoing conversation with your team members. Many team members talk about risks in their "normal" conversations. To illustrate a bit what I mean, the famous "smoking-corner" is always a good place to hear the "truth".
Network:356



brainstorming...
Network:76486



There is no trick.
Suggestions from Peter are good, stand by the coffee machine or where informal conversation take place.
One on one talk are often effective
Network:553



Thanks a lot for the response!
I will try with one-on-one and informal conversations and see the changes that come out.

Probably, having those into the templates and discussing those with the team to find out the criticality and resolution would be effective.
Network:648



Change the question. Don't ask, "what are the risks?" Ask each person in the room, "What about the project keeps you up at night?"

At the last PDC I attended, Terri Carbone led us through this process - there's more to it, in her book Winning Strategies for Executive Leaders. I've started using it at work and I'm getting better responses and more ownership of risks.
...
1 reply by Vincent Guerard
Aug 10, 2017 9:52 PM
Vincent Guerard
...
That is a question I love to use.
Network:367



Few suggestions : first of all ensure whether all the team members are on same page with respect to definition and meaning of risk ( futuristic, uncertain ,if it happens it may impact the project positively or negatively ). secondly facilitate risk identification practice by brainstorming area or category wise (eg.testing , release or documentation etc). Also mentor them to think about the full format of a risk statement for eg. Root cause, the actual Risk, impact (quantification would be more welcome).
Network:76486



Aug 10, 2017 10:46 AM
Replying to Aaron Porter
...
Change the question. Don't ask, "what are the risks?" Ask each person in the room, "What about the project keeps you up at night?"

At the last PDC I attended, Terri Carbone led us through this process - there's more to it, in her book Winning Strategies for Executive Leaders. I've started using it at work and I'm getting better responses and more ownership of risks.
That is a question I love to use.
Network:402



Project assumptions is one of the way to identify probable risks.
Offline discussion with team member also can give understanding of risks knows.
What I experienced every one hardly report, raise any risk due to lack of awareness of Risk Management process. Most of the time team thinks that risk will be additional work to them.
By spreading continuous awareness and better understanding of process, where it will help team or organization at the time of risk occurrence will change teams approach towards risk reporting.
Network:245



I completely agree with Aaron and its an excellent point. The developers and team members/architects would always tend to believe their programs would work perfectly and, risks go against their logic
Ask these questions instead and you can categorize them appropriately

1. What makes them working till late night?
2. What makes the customer scream at us at certain points in time?
3. Why do the requirements always change after getting frozen?
4. Why do the system users/stakeholders are not available when we need them?
Many more....
Network:64



I agree with VIncent and Peter.

One thing is, if you have daily progress / status reporting, then...perhaps you can ask in the enxt day stand-up call...like what are the Impediments that team is facing.

I suggest that breakdown your work into small tasks and start measuring them.

If you notice dip in percentage achieved or so, then you will come to know not only risks but also can have de-risking mechanism/s in place.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I've had a perfectly wonderful evening. But this wasn't it."

- Groucho Marx

ADVERTISEMENT

Sponsors