I have been "promoted" from a software developer position to a project management role in a solo little project (about 200h). All the development work will be done by me, and also I'll talk to the client, document the project, make the estimates, etc.
I've read the that the worst mistake new PM make is they don't manage project risks. The problem is that I don't know where start. How to detect the risks? What I have to do with them? Any example?
Risk management in solo project will be pretty different than risk management in typical projects.
Simplifying things a bit a risk is something which can possibly go wrong, although you can't be 100% sure about that. Odds of materializing a risk can be as high as almost certain or very, very low and of course everything between those two. The impact of the risk will also vary meaning that we sometimes are willing just to accept that a specific risk become real and do nothing about that.
Anyway typically we identify risks, then we assess them so as to learn which risks have the highest negative impact and then we try to mitigate those few which are biggest threats for the project.
Now, the specific of a solo project:
Identifying risks. Typically we invest much effort to make risk identification a collective activity, meaning we want to learn what everyone in the team considers a risk. Usually PM won't be aware of low-level technical risks until they're called by developers and developers rarely care about organizational risks. In a solo project it should be much easier as you're one and only project team members so join knowledge of the whole team is basically your knowledge. Another nice thing is that you should be aware of different perspectives of a project (technical, organizational, business, etc.) which will make it easier to point risks which are on the border of two different areas, e.g. client doesn't understand the way we work which can affect the project as we need their input in planning sessions during every iteration. Basically you should try to list any potentially negative situations, well the reasonable ones at least, which can affect your project.
Assessing risks. Again, risk assessment should be easier in a solo project as basically all the knowledge regarding how probable it is for the risk to materialize or how much the project will be hurt if that happens should eventually be in your head. I say eventually as correct assessment may require some inquiries from you to verify goals of stakeholders etc. There is also a chance (a risk I should say) that being the only person in the team you will undervalue or overvalue specific risks and you will have no one to challenge you. On the other hand you will definitely avoid futile discussions over risks' impact as it would be just your arbitrary decision. Remember to assess risks on regular basis.
Mitigating risks. This is basically what we do to avoid risks or reduce their negative impact once they materialize. And this part actually doesn't differ that much.
You can also read my old article on basics of risk management which can be helpful
What questions do you or others have that are still not answered? What assumptions have you or others have made that have not yet been tested? What can be done better? Where you have a prediction, what is not 100% certain? What do the post mortems indicate on previously completed, similar projects? What is keeping you up at night?
Finally, listen carefully to your stakeholders. They will not say, we have these risks. They will clearly tell you what they are afraid of and what the threats are in very roundabout ways, however.
Risk management is a part of everything you do. Every action you take, every problem raised, every decision made...risk.
I'd recommend talking to some of your Development and PM peers that had simillar projects, be this by the delivery model or by technology and see their lessons learned or their risk logs.
One of the "risk" that I have found occurring is not stepping back to take an overall view of the project, especially when the project is in full swing and you deep in its execution.
I don't know any other way around this other than strict self-discipline in doing a weekly report and status report. The status report must be as close to the facts as possible. I am saying this as it is difficult to do. It is much easier to assess it via third hand.
Start by making a list of everything that could go wrong with the project in terms of missing deadlines, being more expensive and not being able to deliver the desired end-product.
Then decide how bad it would be if each of those risks happened and what is the chance of them happening.
For those that have a high chance of happening and a big impact, plan, in advance, how you would address that risk.
Then keep an eye out for those risks happening. Make sure to report to your stakeholders when a risk has about a 50% chance or greater of happening.
It is the advance planning for risk occurrences that makes the biggest difference in risk management.
