Once the scope and a draft of the plan are defined, we need to star the project risk analysis.
The idea of risk is strictly related to the idea of a project: a project without risks doesn't exist. For this reason along the whole project duration, we need to apply the correct techniques of risk management.

When we do a correct risk management, in order to reduce/eliminate the risk we found, we often need to reconsider some decisions we took during the definition/planning phase.

For this reason it is clear that deleting the risks since the beginning of the project its quite important in term of added value. Indeed, in this phase the cost of one change is still very low, since the status of many document is still open and many decision are still to be taken.

This big TO-DO list should help us in the initial phases, since it gives some ideas to find and reduce the risks related to the most importat project areas (scope, planning, resources). Maybe many of you will take it as obvious things, but, at the end, it is usually on this obvious things that we find the biggest problems.

Scope

• Identify the minimal set of deliverables that we are going to complete, avoid to overcharge the project with the promise of accessories functionalities.
• Specify in clearly the scope of the project and the intermediate deliverables. In doing this remeber to use understandable terminology avoiding any ambiguity. Remeber also to include in your document even what you are not going to do.
• Avoid any expression as "if necessary", "it's preferrable", "if possible" and similars: such expression specify possibilities. You need to clearly decide if a functionality is in or out of the product/project scope.
• Define in advance consistent change management processes and present them for approval to all the structure that will be touched by such processes.
• Each time a change to project scope is requested, verify if there are enough available funds.
• Negotiate and document clearly all project interfaces. Quite often major problems arise when we need to deal with the contact of our project toward other projects/products.
• Remember to always consider impact on the project of external and environmental problems.
• When it is possible (and practical) avoid new technologies. Usually it is always better to consider reaching project objectives with well-known technologies (no experiments unless needed).
• If possible, buy instead of develop. Usually we should avoid the "do-by-myself" state of mind and use as much as possible work already done by others.
• Plan to build prototypes, models and simulations to clarify as soon as possible unclear subjects.
• Involve users as soon as possible in the test. Then repeat test as much as possible.
• If the project is running in an international environment, take particular attention in translating project documents in the most relevant languages (usually english and language of the hosting country).
• Keep up-to-date plans ad project documents.

Planning

• Reduce to a minimum the number of practical critical path in the plan.
• Modifiy the tasks, so that the dependencies from other tasks are reduced at a minimum.
• Plan first high priority tasks and the ones whose outcomes are more uncertain.
• Avoid to put the same resources to work simultaneosly on two critical tasksi.
• If possible, define a resource pool (e.g. programmers) that do not belong to any team and can be moved, based on project needs. When you use this trick, be sure that basic knowledge is guaranteed.
• If there are long tasks, divide them in shorter and more controllable ones.
• If possible get more tasks running in parallel. Usually when staffing of one task is quite heavy, it is always possible to get more tasks running in parallel.
• if the project is a long one, try to use the release concept (incremental method) so that you will end up with a sequence of shorter projects.
• Prepare releases in advance.
• When planning, consider to use standard tools and methods which are familiar to whom is going to partecipate in the project.
• Be careful in estimating tasks linked to the use of a new hardware or to a specific training.
• Schedule periodic project review.
• Take attention to holydays, training and other events that may influence the planning.
• Use effective and accurate time tracking tools and be sure that they are used in the correct way.
• If needed change or upgrade the technology, do this at the beginning of the project, so that work will be more efficient and drawback may be absorbed later.

Resources

• Define as soon as possible names and associated roles.
• Try to limit the usage of the team in separate projects, in maintenance work or in support or other tasks that might create resource conflicts. Document everything that you are not able to solve.
• Do not plan for overtime.
• Modify the plan in order to reduce the charge on resources already overloaded.
• For critical tasks use the best resources and do not overcharge the task with un-useful ones.
• if you identified critical or risky tasks, provide to them resources already well-known as "problem solver".
• Wherever possible, try to automatize the work.
• Identify, even outside of the project, experts that cover all the needed skills. In case the situation will become critical it is important to have an identified pool of expert to which we can refer.
• Minimize the "dependency from a single resource" or from a small group. This can be partially  achieved using, where possible, peer review and documenting the tasks that are being done.
• If you need to use subcontractor or external outsources, try to use the ones you already used in the past. Remember then, in preparing the contracts, to specify clauses which are consistent with the master plan.
• Get used to involve clients both in resource and in planning related issues.
• Try to forecast in advance the staff needs in case special events occurs.
• Using work-shop, train team members to forecast project risks related to their activities.
• If existing, handle rigorously outsourcing. Be sure that SLA's are always respected.
• Check how team leaders utilize their resources and, to a certain extent, move the ones less charged to different teams (you can use for this Earned Value analysis ).