Accelerated Digital Learning

# PRACTICAL APPLICATION / 45 minutes, teams of 4-5 people

#1 From the perspective of the Digital Pillar programme presented today, what could be the concrete needs of your school?

Determine what the concrete needs are for the school to become an innovative school. Use SWOT analysis if appropriate.
Then turn the needs into concrete initiatives. Use

# 2 How could these needs be prioritized?

To prioritise, I suggest using the MoSCoW technique described below.

Action Plan

MoSCoW is a prioritisation technique. It can be used in a variety of ways, including deciding which tasks need to be completed first in complex projects or initiatives.

The technique divides the work items into four distinct sections according to their priority. These sections are called areas because they contain different types of tasks to be completed within projects and initiatives.

The domains are independent of each other.

WE MUST IMPLEMENT NOW

is non-negotiable

can only be implemented with basic features (minimum required elements to be defined)

without this requirement met: cannot deliver on time, illegal, risky, cannot deliver the project

WE MIGHT BE ABLE TO IMPLEMENT SOMETIME

is important, but the requirement is not vital now

we may not like to leave out this element, but even without it the solution is still a viable project

additional analysis or another solution may be needed; e.g. managing expectations, some inefficiency, an existing solution, etc.

WE WISH TO IMPLEMENT

desirable, but not as important as it should be

only implement if there is time and extra budget

WE CAN'T IMPLEMENT RIGHT NOW

this is not the time to include this requirement now

not in the budget

could be nice to include, but leads to no real impact

What can happen if these requirements cannot be met?

If the answer is "change approach", then there is no way around it, the project/initiative must be stopped.

The two areas can be differentiated from each other by reviewing the degree of regret caused by non-compliance in terms of the value of the project or the number of people targeted.

These are the requirements that the project team agreed it would not meet. They are recorded in the list of priority requirements, where they help to clarify the purpose of the project and avoid re-entry "through the back door" at a later date. This helps manage expectations that some requirements simply won't make it to the delivered solution, at least not this time.

To implement this technique, you must first list all the requirements for the project/initiative and then perform the following steps:

Step 1: Assign each condition to one of the four priority categories.

Step 2: Assess the value of each requirement by assigning a score from 1 to 10. This score reflects how vital each requirement is to the success of the project/initiative. If you give a high number (9-10), this requirement has a high priority for your project, while a low number (1-3) means it is unnecessary or very low on your priority list.

Step 3: Perform an evaluation based on the results from Step 2 to determine if a task should be included in an iteration.

The assessment criteria depend on where the requirements fall in the respective categories:

MUST DO (highest): The team must implement this requirement in the current iteration.
COULD DO (high): The team should implement this requirement, but it may be deferred to a future iteration if necessary to meet the project/initiative deadline.
WE WISH TO DO (medium): Implementing this requirement makes sense from the organization/community perspective. It could have significant value to stakeholders, but there are no specific dates or deadlines to be met by implementing it.
CAN'T DO (lowest): This task is usually not required by the project and should be excluded from planning processes.

Step 4: Prioritise the work items based on the results obtained in step 3, using metrics such as cost/benefit or other alternatives, depending on the needs of your organization. An example of a prioritization metric used with MoSCoW is the critical level of a task.

Page updated

Report abuse