Una manera uniforme de priorizar con el método MoSCoW
La elección e implementación de un nuevo software puede ser todo un trabajo. Las empresas que quieren tomar una buena decisión, deben saber exactamente lo que pueden esperar del software. Establecer las prioridades es, por tanto, primordial, pero este proceso no siempre es fácil. Por ello, Daig Clegg en 1994 ideó el método MoSCoW. Las consonantes de este acrónimo representan los diferentes tipos de deseos y requisitos que una empresa debería distinguir: Must-have (debe-tener); Should-have (debería-tener), Could-have (podría-tendría) y Won’t-have/Would-have (no-tendría).
Must-have (Debe-tener)
Los must-have son los requisitos mínimos que un software tiene que cumplir. Sin el cumplimiento de estos requisitos, se considera que el proyecto no ha tenido éxito. Por ejemplo, si una empresa se interesa primero por un sistema ERP porque su programación manual de la producción provoca errores semanalmente y, por lo tanto, conlleva pérdidas de tiempo, el módulo de planificación de la producción será un must-have.
Should-have (Debería-tener)
Los should-have en un proceso de orientación, son aquellas funcionalidades que resultan altamente deseables. Sin embargo, el software también puede demostrar su valía sin estas funcionalidades. La adición de los should-have generalmente se encargan de conseguir un mayor retorno de la inversión (ROI). También puede tratarse de funcionalidades que no tienen una prioridad tan alta en el momento, pero que será necesaria en un periodo de tiempo relativamente corto. Una empresa que ahora puede convertir los pedidos por correo electrónico en órdenes de producción de forma relativamente rápida puede seguir considerando la integración del correo electrónico como una should-have de proyección de crecimiento.
Could-have (podría-tendría)
A los could-have también se les conoce como nice-to-have. Estas son cualidades que gustaría añadir si entran dentro del rango de tiempo y dinero. Sin embargo, cuando suponen un esfuerzo extra, no tiene sentido contemplarlas. Por ejemplo, en el caso de una empresa de producción con una clientela baja de B2B, un could-have podría ser la integración de EDI. El intercambio directo de datos puede acelerar el proceso de pedido y facturación, pero trae consigo un crecimiento realmente significante de los pedidos.
Won’t have/ Would-have (no-tendría)
Los won’t have son más bien deseos utópicos, o deseos que en el momento de la orientación no merecen aún la pena invertir en ellos. Por ejemplo, esto puede ser involucrar la recogida de pedidos a través de realidad aumentada. Es una tecnología muy interesante, pero para la mayoría de las empresas este sólo supone un coste enorme. A los won’t have también se les conoce como would-have, porque una empresa podría implementarlos bajo ciertas condiciones en el futuro.
Cambio de situaciones y prioridades de trabajo
Los deseos y requisitos nunca son estadísticos. Se diferencian por empresa, situación y momento. De esta forma, se puede prevenir que los deseos y requisitos de una empresa cambien de categoría después de un tiempo. Por ejemplo, al principio una empresa puede tener un pequeño almacén. Entonces, a los recogedores de pedido no les importa ir a un punto central para recoger el siguiente pedido. En ese momento, la recogida por voz es un could-have o, incluso, un won’t-have. Sin embargo, tan pronto como la empresa crezca y el almacén se vuelva mucho más grande, la recogida por voz puede convertirse en un should-have o, incluso, en un must-have.
