Talk:Risk register
(→Content) |
Keyser-sözer (Talk | contribs) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | '''Keyser-sözer responses to reviews in bold''' | ||
| + | |||
== Hermaeus Mora == | == Hermaeus Mora == | ||
=Structure= | =Structure= | ||
| − | *The language is clear and easily understandable. A couple commas may be missing and in the first section paragraph 3 "The risk register cannot only be used as a motivating risk management tool" could be formulated as "The risk register can be used not only as a motivating risk management tool;" apart from that it's good. | + | *The language is clear and easily understandable. A couple commas may be missing and in the first section paragraph 3 "The risk register cannot only be used as a motivating risk management tool" could be formulated as "The risk register can be used not only as a motivating risk management tool;" apart from that it's good. '''I have added more rests to my text, thanks for the advice.''' |
| − | *There's just one figure, more could be added as the article grows. | + | *There's just one figure, more could be added as the article grows. '''There are more figures now, hopefully good for the visualisation of the article.''' |
*References to links are nicely made, the article uses a book, this should be referenced in the traditional wiki way <nowiki><references /></nowiki>. | *References to links are nicely made, the article uses a book, this should be referenced in the traditional wiki way <nowiki><references /></nowiki>. | ||
| − | *A category from APPPM is added which is nice, maybe add a few more e.g. Uncertainty, Risk etc. | + | *A category from APPPM is added which is nice, maybe add a few more e.g. Uncertainty, Risk etc. '''More categories added, good advice.''' |
*Layout seems to be ok for now, abstract, introduction to the tool and its applications and an introduction to how the tool should be used. | *Layout seems to be ok for now, abstract, introduction to the tool and its applications and an introduction to how the tool should be used. | ||
| Line 11: | Line 13: | ||
*The article is obviously not finished yet (778 words as of the writing of this review) So the review can only regard the initial part. | *The article is obviously not finished yet (778 words as of the writing of this review) So the review can only regard the initial part. | ||
*The article clearly falls under the 'in-depth description of a particular method' category. It relates deeply to project management and, judging by the links attached, is based on fresh data. | *The article clearly falls under the 'in-depth description of a particular method' category. It relates deeply to project management and, judging by the links attached, is based on fresh data. | ||
| − | *The abstract is good in length and shows a fair purpose behind the tool. It could however include a few sentences about the tool itself, short summary, instead of a rather strong opinion that it's "THE optimum [...] tool within project management". | + | *The abstract is good in length and shows a fair purpose behind the tool. It could however include a few sentences about the tool itself, short summary, instead of a rather strong opinion that it's "THE optimum [...] tool within project management". '''I have made the summary less opinionated.''' |
| − | *As mentioned before any book references should be added along with additional categories in APPPM wiki for further reading. | + | *As mentioned before any book references should be added along with additional categories in APPPM wiki for further reading. '''Categories and references have been added.''' |
| + | |||
| + | '''All points relevant, solid feedback that I have taken on board.''' | ||
= Review - WinWin = | = Review - WinWin = | ||
| Line 19: | Line 23: | ||
'''Structure''' | '''Structure''' | ||
| − | * The overall feeling of the article is very positive. The language is precise and easy to understand. However, there are a few spelling mistakes and grammar mistakes, which will surely disappear in the editing process. | + | * The overall feeling of the article is very positive. The language is precise and easy to understand. However, there are a few spelling mistakes and grammar mistakes, which will surely disappear in the editing process. '''Continued in same writing style and I have fixed mistakes.''' |
| − | * At the moment there is only one figure in the article. Using more figures will definitely have a positive effect on the visualization as the article gets further along. | + | * At the moment there is only one figure in the article. Using more figures will definitely have a positive effect on the visualization as the article gets further along. '''I have added more figures.''' |
* Good use of references. | * Good use of references. | ||
* The layout seems to be fine for now. | * The layout seems to be fine for now. | ||
| Line 29: | Line 33: | ||
* The fresh data is a nice touch. | * The fresh data is a nice touch. | ||
* The abstract has a suitable length for this kind of article. Definitely a plus. | * The abstract has a suitable length for this kind of article. Definitely a plus. | ||
| + | |||
| + | '''Good feedback possibly a little lacking but the article was also lacking so there isn't much to review. More critical feedback would have been appreciated.''' | ||
| + | |||
| + | = Review by Dutten = | ||
| + | |||
| + | Dear Keyser Sözer, | ||
| + | |||
| + | I enjoyed reading your wiki article; it’s always interesting to be exposed to new methods. I understand that you are not completely finished with your article – so don’t take my comments to harsh. If you wish, you can comment on my comments, and I will then answer/elaborate. | ||
| + | My comments are divided into general comments, and text specific comments, see below. | ||
| + | |||
| + | ==General comments== | ||
| + | *What is the risk register in detail? I think you are going to write this in later stage | ||
| + | *You write very long sentences which I think is difficult to understand '''I have tried to shorten the length of sentences.''' | ||
| + | *You are missing your reference list in the bottom - you can make it by using the following code : | ||
| + | <nowiki>=References = | ||
| + | <references/></nowiki> | ||
| + | *I think your figure on the right ''Example of a Risk Register used by SURF'' is too small. By using this code, and changing the number 550, you can change the size. | ||
| + | <nowiki>[[File:RiskRegister2010.jpg|550px|thumb|right|Figure 2. Example of how creativity is necessary through all project phases]] | ||
| + | </nowiki> | ||
| + | |||
| + | '''Both very helpful points that I have followed through with, thanks for telling me how to implement the changes.''' | ||
| + | |||
| + | ==Text specific comments== | ||
| + | ===Risk Register=== | ||
| + | The uncertainty surrounding any decision or action that may negatively affect a project’s success can be defined as a risk and knowing how to classify and document these risks is essential to the success of any project. | ||
| + | *Is risk only linked to the decisions and actions you make? Isn’t there also risks not affected by your decisions and actions? | ||
| + | *You only mention classify and documentation is essential. Don't you need to identify the risk before you can classify and document? '''Changed according to this feedback.''' | ||
| + | |||
| + | This is because risk uncertainty can be difficult to control and predict; being able to communicate risk likelihood and categorisation to a project team in an efficient way allows the team to evaluate risks together and identify to what extent they can prevent these risks from happening. | ||
| + | *I dont really understand what you mean by categorising the risk. Do you mean the level of impact? '''I have reworded this section as I understand your point.''' | ||
| + | |||
| + | Documenting risks from an early stage streamlines a team’s goals and their perception of the project, working as a communication tool and a risk management tool simultaneously. The risk register is the optimum risk management tool within project management when it is used correctly within a management project. | ||
| + | *I don’t see how documenting risks can streamline a team’s goals? '''I believe it can, working against the same risks means working towards the same goals.''' | ||
| + | *’’within project management when it is used correctly within a management project.’’ I don’t entirely get this part here. '''I have also reworded this part.''' | ||
| + | *The whole introduction is missing references. '''I have added references.''' | ||
| + | *Maybe add a headline called summary or introduction to your first part of the article, since now it seems like the headline for the first text is the title of the article '''I have not done this, I do not believe this is required.''' | ||
| + | |||
| + | ===What is a Risk register=== | ||
| + | A risk register is the baseline document of the process of managing risk (reference Winch); it is a means of visualising a project’s risks within a table or template so that risks can be better understood and dealt with by project managers. | ||
| + | *You mentioned earlier, that it was the team that dealt with the risk, now it is only the project managers? '''I have fixed this part.''' | ||
| + | |||
| + | It allows risks, their likelihood and preventive measures for each risk to be recorded [2]. The risk register should be in a centralised location for information to be stored and updated with respect to the risks that are effecting the company; it is key that the risk register is used constantly throughout a project process. | ||
| + | *Again I think this is a very long sentence. Maybe divide between between ‘’company’’ and ‘’it’’ | ||
| + | |||
| + | As can be seen in Graham Winch’s risk process diagram (insert Winch diagram), throughout the lifecycle of how a risk is dealt with, the risk register is the tool that should be constantly updated and referred to. | ||
| + | Generally, risk registers are created within a company's intranet or online database where the register can be updated by any member of staff and can be seen by any relevant project stakeholders. The register would then be made using database or spreadsheet software. A risk register could also be made offline however, being drawn on a whiteboard at a company meeting for example as a quick and efficient tool for motivating the meeting. The register must always be in a visual format however; visualisation is key to the success of the risk register tool. | ||
| + | *I think this whole text block is much better, in regards to understandability and interest, compared to the previous text. | ||
| + | |||
| + | Whenever an important decision is made within a project, the risk register is referred to. Whenever something unfamiliar is being dealt within a project, again the risk register should be referred to. This is how the risk register should be used, as a familiar tool that any member of a project team can come back to ensure they can make the right decisions with a clear and focused mindset and without the need for a boss or authoritative figure being at hand; it therefore also reduces the time needed for project teams to carry out tasks, improving the efficiency of workers. | ||
| + | *Very long sentence. However, I think it’s good, so just find a spot to separate the sentence. That would improve it a lot. '''I have done this and have tried to do this throughout the article.''' | ||
| + | |||
| + | The risk register cannot only be used as a motivating risk management tool; it also has further uses as a documentation tool. Documenting information that is flowing into a project is incredibly important to manage risks affecting a current project but it also works as means of storing historical data. Ensuring that information is quickly available to you may be entirely necessary if a past client requires information about a past project [3]. Having a shared risk register would provide access to this information. | ||
| + | *I think this need more clarity, I suppose you mean information about risks, but here it seems like just general project information. '''I have left this part alone, re-read this section, I believe it makes sense.''' | ||
| + | |||
| + | It is also crucial in preventing future failures as risk registers become more and more effective as they are used more frequently within a company. Information about the uncertainty of a previous risk would allow a project manager to make a more educated decision about how to deal with the risk and would increase their own knowledge about these risks. | ||
| + | |||
| + | ===Defining Risk=== | ||
| + | To use the risk register correctly, it is essential that the risks associated with the project are identified properly using a risk management plan [4]. A risk management plan should consist of utilising the help of relevant stakeholders and project team members to gather all risks prior to the risk register being created. Consulting everybody before the risk register is created increases the efficiency of the risk register; everyone who uses it is involved in its creation and all relevant risks should be covered and correctly recorded if everybody has an input from their respective departments. | ||
| + | USE WINCH BOOK FOR THIS PART | ||
| + | *You call this part defining risk, but to me it seems more like a ‘’Implementation advice’’ '''I have changed the title of this section''' | ||
| + | |||
| + | '''Very useful feedback, I wish I had had the rest of the article for this user, the feedback is very detailed.''' | ||
Latest revision as of 18:12, 29 November 2014
Keyser-sözer responses to reviews in bold
Contents |
[edit] Hermaeus Mora
[edit] Structure
- The language is clear and easily understandable. A couple commas may be missing and in the first section paragraph 3 "The risk register cannot only be used as a motivating risk management tool" could be formulated as "The risk register can be used not only as a motivating risk management tool;" apart from that it's good. I have added more rests to my text, thanks for the advice.
- There's just one figure, more could be added as the article grows. There are more figures now, hopefully good for the visualisation of the article.
- References to links are nicely made, the article uses a book, this should be referenced in the traditional wiki way <references />.
- A category from APPPM is added which is nice, maybe add a few more e.g. Uncertainty, Risk etc. More categories added, good advice.
- Layout seems to be ok for now, abstract, introduction to the tool and its applications and an introduction to how the tool should be used.
[edit] Content
- The article is obviously not finished yet (778 words as of the writing of this review) So the review can only regard the initial part.
- The article clearly falls under the 'in-depth description of a particular method' category. It relates deeply to project management and, judging by the links attached, is based on fresh data.
- The abstract is good in length and shows a fair purpose behind the tool. It could however include a few sentences about the tool itself, short summary, instead of a rather strong opinion that it's "THE optimum [...] tool within project management". I have made the summary less opinionated.
- As mentioned before any book references should be added along with additional categories in APPPM wiki for further reading. Categories and references have been added.
All points relevant, solid feedback that I have taken on board.
[edit] Review - WinWin
Structure
- The overall feeling of the article is very positive. The language is precise and easy to understand. However, there are a few spelling mistakes and grammar mistakes, which will surely disappear in the editing process. Continued in same writing style and I have fixed mistakes.
- At the moment there is only one figure in the article. Using more figures will definitely have a positive effect on the visualization as the article gets further along. I have added more figures.
- Good use of references.
- The layout seems to be fine for now.
Content
- The preliminary content seems to be very relevant to the course. The paragraphs are nicely written but could profit from a few summarizing sentences.
- The fresh data is a nice touch.
- The abstract has a suitable length for this kind of article. Definitely a plus.
Good feedback possibly a little lacking but the article was also lacking so there isn't much to review. More critical feedback would have been appreciated.
[edit] Review by Dutten
Dear Keyser Sözer,
I enjoyed reading your wiki article; it’s always interesting to be exposed to new methods. I understand that you are not completely finished with your article – so don’t take my comments to harsh. If you wish, you can comment on my comments, and I will then answer/elaborate. My comments are divided into general comments, and text specific comments, see below.
[edit] General comments
- What is the risk register in detail? I think you are going to write this in later stage
- You write very long sentences which I think is difficult to understand I have tried to shorten the length of sentences.
- You are missing your reference list in the bottom - you can make it by using the following code :
=References = <references/>
- I think your figure on the right Example of a Risk Register used by SURF is too small. By using this code, and changing the number 550, you can change the size.
[[File:RiskRegister2010.jpg|550px|thumb|right|Figure 2. Example of how creativity is necessary through all project phases]]
Both very helpful points that I have followed through with, thanks for telling me how to implement the changes.
[edit] Text specific comments
[edit] Risk Register
The uncertainty surrounding any decision or action that may negatively affect a project’s success can be defined as a risk and knowing how to classify and document these risks is essential to the success of any project.
- Is risk only linked to the decisions and actions you make? Isn’t there also risks not affected by your decisions and actions?
- You only mention classify and documentation is essential. Don't you need to identify the risk before you can classify and document? Changed according to this feedback.
This is because risk uncertainty can be difficult to control and predict; being able to communicate risk likelihood and categorisation to a project team in an efficient way allows the team to evaluate risks together and identify to what extent they can prevent these risks from happening.
- I dont really understand what you mean by categorising the risk. Do you mean the level of impact? I have reworded this section as I understand your point.
Documenting risks from an early stage streamlines a team’s goals and their perception of the project, working as a communication tool and a risk management tool simultaneously. The risk register is the optimum risk management tool within project management when it is used correctly within a management project.
- I don’t see how documenting risks can streamline a team’s goals? I believe it can, working against the same risks means working towards the same goals.
- ’’within project management when it is used correctly within a management project.’’ I don’t entirely get this part here. I have also reworded this part.
- The whole introduction is missing references. I have added references.
- Maybe add a headline called summary or introduction to your first part of the article, since now it seems like the headline for the first text is the title of the article I have not done this, I do not believe this is required.
[edit] What is a Risk register
A risk register is the baseline document of the process of managing risk (reference Winch); it is a means of visualising a project’s risks within a table or template so that risks can be better understood and dealt with by project managers.
- You mentioned earlier, that it was the team that dealt with the risk, now it is only the project managers? I have fixed this part.
It allows risks, their likelihood and preventive measures for each risk to be recorded [2]. The risk register should be in a centralised location for information to be stored and updated with respect to the risks that are effecting the company; it is key that the risk register is used constantly throughout a project process.
- Again I think this is a very long sentence. Maybe divide between between ‘’company’’ and ‘’it’’
As can be seen in Graham Winch’s risk process diagram (insert Winch diagram), throughout the lifecycle of how a risk is dealt with, the risk register is the tool that should be constantly updated and referred to. Generally, risk registers are created within a company's intranet or online database where the register can be updated by any member of staff and can be seen by any relevant project stakeholders. The register would then be made using database or spreadsheet software. A risk register could also be made offline however, being drawn on a whiteboard at a company meeting for example as a quick and efficient tool for motivating the meeting. The register must always be in a visual format however; visualisation is key to the success of the risk register tool.
- I think this whole text block is much better, in regards to understandability and interest, compared to the previous text.
Whenever an important decision is made within a project, the risk register is referred to. Whenever something unfamiliar is being dealt within a project, again the risk register should be referred to. This is how the risk register should be used, as a familiar tool that any member of a project team can come back to ensure they can make the right decisions with a clear and focused mindset and without the need for a boss or authoritative figure being at hand; it therefore also reduces the time needed for project teams to carry out tasks, improving the efficiency of workers.
- Very long sentence. However, I think it’s good, so just find a spot to separate the sentence. That would improve it a lot. I have done this and have tried to do this throughout the article.
The risk register cannot only be used as a motivating risk management tool; it also has further uses as a documentation tool. Documenting information that is flowing into a project is incredibly important to manage risks affecting a current project but it also works as means of storing historical data. Ensuring that information is quickly available to you may be entirely necessary if a past client requires information about a past project [3]. Having a shared risk register would provide access to this information.
- I think this need more clarity, I suppose you mean information about risks, but here it seems like just general project information. I have left this part alone, re-read this section, I believe it makes sense.
It is also crucial in preventing future failures as risk registers become more and more effective as they are used more frequently within a company. Information about the uncertainty of a previous risk would allow a project manager to make a more educated decision about how to deal with the risk and would increase their own knowledge about these risks.
[edit] Defining Risk
To use the risk register correctly, it is essential that the risks associated with the project are identified properly using a risk management plan [4]. A risk management plan should consist of utilising the help of relevant stakeholders and project team members to gather all risks prior to the risk register being created. Consulting everybody before the risk register is created increases the efficiency of the risk register; everyone who uses it is involved in its creation and all relevant risks should be covered and correctly recorded if everybody has an input from their respective departments. USE WINCH BOOK FOR THIS PART
- You call this part defining risk, but to me it seems more like a ‘’Implementation advice’’ I have changed the title of this section
Very useful feedback, I wish I had had the rest of the article for this user, the feedback is very detailed.
