Checklists and MoSCoW - Are Our Tasks Flawed?

Within FinStarty, we have tasks. The original idea was that these would be small, quickly completable actions that can be checked off and result in a completed project. During a recent project, not all requirements were met. One cause of this is that a list of required features was not produced in enough detail, and only the basics were completed. In the "Critiquing My Raid Log" post, these shortcomings were discovered.

Risks were handled well, responses & escalations were considered, but there is no way to confirm an assumption, allocate actions, follow up on issues, or track the status of decisions. The point being that only the initial action was created, the absolute must-haves, but nothing under these. These should have been obvious, except that when building, it's all too easy to overlook an element and get carried away with another, in this case, the Risk Reporting.

Enter MoSCoW

Must, Should, Could, Won't. That sounds simple, and on the surface, it provides more detail and a priority order than a simple checklist or task list, which is what FinStarty currently has.

Problem solved, projects to have a feature list and assigned priority, a list of musts, shoulds and coulds? Well, what happens when one of those becomes bigger and needs to be a project in itself? That's why tasks have a "Make Project" button, creating a child project. How do these differ from tasks? Extending that feature with a select option for the priority level could be a simple solution.

Tasks (Ideas) & Features Tool

What would happen to Tasks? Tasks are just tasks, things to check off a list and not features or requirements of the project. An unexpected use case of tasks is storing ideas related to projects; our content creation team uses tasks to store topic titles for review.

The Make Project Button is Flawed if priority levels are added to tasks. When a task/feature/requirement becomes a child project, it must retain a Priority Level relative to other child projects and features that are not converted into projects. The project model now has a priority level requirement. How the child projects are displayed could be about to change quite drastically to accommodate a framework that includes priority levels.

Should we use the MoSCoW framework?

Is the MoSCoW framework the right approach for prioritising features for developers, designers, and campaign managers? I'm not 100% sold.

Vision and mission statements are something I became quite fond of in my early projects; in truth, they worked well for me and my then manager. The vision of selling climbing frames across Europe, recruiting copywriters and translators, and creating a development workflow for our multilingual WordPress websites ultimately got us through. Specific tasks were assigned to individuals, completed, and websites were created; gradually, EU sales improved.

Vision and tasks it was quite simple, and it worked. Did this only work because it was a small team and we kept the tasks straightforward and the development routine?

Can MoSCoW be Kept Simple?

Yes, you could make them simple statements of facts for our RAAID log, perhaps something like:

• Record Risks & Responses
• Record Assumptions & Clarifications
• Record Actions and Stauses
• Record Issues & Effects
• Record Decisions

What if it's complicated? A sublist for each feature is the items sublist that must have, so these need to be identified too. We must record the risk response, but the probability is just something that we should have.

• Record Risks & Responses
  • Escalation
  • Impact Assessment
    • Cost / Time
  • Risk Owner
  • Mitigation Statement
  • Status
  • Deadline
  • Response Type
  • Risk probability

...and so on with the remaining elements creating this parent-child relation, the big main feature name and its components.

Won’t have this time..

This is something that bugs me: how are these things captured and executed later on after a project is closed down? You would need awareness of what they were and resurface them when the feature is revisited. Without automation, I can guarantee that these will be forgotten or reinvented, and neither is ideal, and the compounded growth effect is lost.

On the other hand, this can help prevent scope creep and keep projects deliverable and not become overwhelming.

Should Have vs Could Have

If must-haves are essential, without these, it is not usable. Should have features that cause significant performance issues for the website, which might make it feel slow, annoying, and result in a lower conversion rate. Could have is more like features that you wouldn't know that you miss, the cherry on top.

Future Development

Our RAID log development task list did include "Actions status" & "Action assigned to". They were not grouped, and focus was lost; the task list isn't as usable as required.

Task lists require more structure, creating a "Project Features Tool" using the MoSCoW framework, sounds more and more like a should have. Being able to highlight a must-have item before completing projects should improve the delivery of future projects.

What must be done first is to fix the main RAID log critiques, then MoSCoW.