Critiquing My Raid Log Template

Recently, we introduced a feature called RAAID comments to the project board. Have we successfully met the requirements of a RAID log template that can be used for almost any project?

Why (AA) Actions & Assumptions?

Traditional RAID logs will have either of these, not both. However, from discussions with project managers (PMs), both elements are important to record. Actions for significant things that someone has done and might replace or enhance our tasks tool one day. Assumptions, regardless of the cause, need clarification as soon as possible, and this should be recorded and acted upon.

Not recording either actions or assumptions was viewed as problematic. Assumptions are infamous for their correlations with making an a** out of you and me.

Basic Recording & Viewing

This is made easy, a primary objective of FinStarty's overall usage. The comment type is selected, and write your comment and the first step is taken.

These are displayed in the order they are made and are easily filterable on the type of comment you have made.

It is simple to update and edit these comments, which can only be updated by the original commenter. Other project management tools allow edits by any user with access to the project; creating confusion.

Risks

Risks could have been transferrable to a Risk Register, for now, risks are kept scoped to the project that identifies them.

Escalating risks. The mechanism for this works with the parent-child relationships that Finstarty uses. For example, if I identify a risk in writing a blog and don't feel able to respond to the risk. It can be elevated to a content management project.

And if the Content Manager thinks that it's acceptable for the blog writer to complete a risk response they can cancel that escalation, or respond or escalate themselves.

Risk Response

Response Type, Priority, Response Description, Ownership (Assigned To) & Estimated Cost of the risk are all recorded.

Probability, Risk Category, Risk Status and the capability to add a project to manage the risk directly aren't available. The most missed are the Probability score and status. The probability of risks occurring helps create a sense of urgency regarding the risk, and knowing when it is complete prevents it from being analysed when it is no longer required. Both should have been marked as must-have features of the risk response section of the tool.

Being able to create a project for the risk is a could have, but for bigger risks that prompt a project, it would give context to that project which will help that project set is must have more effectively.

Elapsed risks are something that is not handled and that should be addressed in a follow-up.

Actions, Assumptions, Issues & Decisions

A large omission, right now I can not clarify an assumption or know the status of an action. Also addressing any of the issues or the agreement of decisions or objections.

These glaring omissions in hindsight are brought on by not fully writing out the scope of the project and becoming very focused on one element in this case risk-responses, which I still think could be improved.

Writing out the must-haves would likely have prevented this! Several project management frameworks reference gatekeeping project stages from planning to implementation. There are a couple of additional considerations for FinStarty project management here.

Dependencies

The standard dependencies function for FinStarty is generally acceptable; however, different types of dependencies can exist. The most common type is listed as FS below, while other dependency types have their specific uses. I suggest that these alternative types can sometimes indicate a failure to break down projects into manageable chunks. If only one task in a project depends on another project being completed, there's no need to create a separate project.

In FinStarty, however, you can create a child project that includes this dependency, while the parent project can be un-completable until its essential child projects are finished.

• Finish-to-Start (FS): A task cannot begin until the preceding task is finished.
• Finish-to-Finish (FF): A task cannot be finished until the preceding task is finished.
• Start-to-Start (SS): A task cannot begin until the preceding task has started.
• Start-to-Finish (SF): A task cannot be finished until the preceding task has started.

Final Word

This is a good template to begin with, and once the responses are completed for the missed elements this RAAID template will stand any project manager in good shape.

With the identified risk response fields to be added to the overall tool, it will be highly efficient and could lead to the creation of a fully fledged risk register with the two project management tools rolled into FinStarty making life much easier than maintaining a custom spreadsheet or tools that require you set them up as standalone boards.