Cobrar por adelantado en los códigos de gastos

Este artículo forma parte de nuestra colección "From the Trenches". Describe los procedimientos recomendados para definir la estructura de código de cargos de la organización para el sistema de administración de proyectos o el sistema de parte de horas.

Para descargar la versión Word de este artículo, consulte Carga anticipada en los códigos de cargo.

Para ver más artículos, consulte las notas del producto "Desde las trincheras".

Cobrar por adelantado en los códigos de gastos

A menudo se me pide que ayude a las organizaciones a definir su estructura de código de cargo, ya sea para su sistema de administración de proyectos o para su sistema de parte de horas. Aunque es cierto que cada organización es diferente y las diferentes necesidades dan lugar a diferentes tipos de cargos, hay algunas prácticas comunes que hemos encontrado a lo largo de los años que son universales.

Pregunte menos, no más

A nadie le gusta la burocracia, por lo que cuanto más compleja sea una estructura de código de cargo, menos probable será que las personas realicen informes precisos. Imagine, por ejemplo, que hago una lista de 10 000 códigos de cargo en una lista plana larga entre la que elegir. Es posible que tenga que desplazarse durante una hora y examinar cada entrada posible en una lista desplegable antes de encontrar la opción correcta exacta para esta hoja de horas o actualización de proyecto en particular. A continuación, tendría que desplazarse por el resto de la lista para asegurarse de que no encontró algo que no fuera un poco más exacto.

No seamos tontos. Nadie hará eso. Tomarán la primera entrada que parece razonablemente cercana y elegirán eso. En caso contrario, todas las horas terminarán a cargo de "999:Miscellaneous".

Así que haz que tu lista sea simple. Idealmente, no debe requerir el desplazamiento en absoluto, pero debe ser visible en una sola pantalla o quizás con un clic más. Esto significa que solo está eligiendo entre 20 y 30 opciones posibles como máximo. En este caso, menos es más.

Si la administración está determinada a obtener mucho más detalles, recuérdales que es mejor obtener más precisión y menos detalles que más detalles y menos precisión.

No preguntes lo que ya sabes.

He visto muchas estructuras de código de cargo en las que hay un código de cargo idéntico para cada departamento o proyecto. Sin embargo, si ya se le pide a la gente que elija el proyecto y estamos haciendo una entrada para reuniones por ejemplo, entonces sé que el elemento de línea debe ser "reuniones en este proyecto", por lo que ¿por qué contaminar la lista de cargos con varios elementos de reunión? La misma lógica se mantiene con los departamentos. Si tenemos una lista de empleados que pertenecen a cada departamento, ya sabemos en qué departamento están. Por qué contaminar la lista de cargos con "Reunión del departamento de ventas", "Reunión de departamento técnico" y "Reunión del departamento de marketing". Solo tiene que hacer un elemento llamado "Reunión" y podemos deducir del departamento del empleado y del proyecto para el que están en lo que fue la reunión.

Resolverse para mejorar la resolución

Elegir un nivel de resolución adecuado para el proyecto y el parte de horas es un desafío común. Piense en el nivel en el que desea administrar las cosas con estas condiciones: 1) Debe haber más valor en los datos que en el tiempo para recopilarlos, por lo que si pasa todo el día informando sobre su día, ¿cómo podrá hacer algo? 2) Trabaje en un nivel en el que esté preparado para tomar decisiones. 3) Cuanto más complejo sea entrar, menos probabilidades tiene de obtener datos precisos. 4) Cuando sea posible, consigue que todos trabajen en el mismo nivel de resolución para que no administres un grupo en tareas de 10 minutos de duración y otro en tareas de 3 días de duración. Para muchas personas, ser capaz de informar de 3 a 5 líneas de detalle para un día determinado es un montón de detalles.

Condición de los datos

Algunas personas harán que el usuario final responda a las mismas preguntas una y otra vez. Por ejemplo, hemos visto sistemas con una columna para "R&D", lo que significa que este cargo es o no es un cargo apto para un crédito fiscal de R&D. Pero deberíamos poder asociar la idoneidad a la propia tarea en lugar de a cada línea del parte de horas de cada persona. Además, ¿qué haría si algunos usuarios pensaran que era apto y algunos usuarios pensaban que no lo era? Este escenario probable también se reproduce en ejemplos como "Design-eligible for R&D" y "Design-not-eligible for R&D". Esto duplica el número de códigos de cargo para que no se devuelva ningún valor. Solo tiene que hacer que alguien en R&D marque cada valor desplegable como apto o no y no tendrá que seguir pidiendo a los usuarios finales que intenten averiguarlo cada semana.

Jerárquica

Los mejores sistemas de proyecto y parte de horas permiten una visualización jerárquica de los datos. Si no tiene otra opción que tener muchas opciones posibles, crear una jerarquía puede facilitar la ingesta de muchos datos. Piense en 5-10 elementos como máximo para elegir en cada nivel. Y no te sientas tentado a hacer docenas de niveles. La creación de una jerarquía de 3 a 4 niveles debe ser capaz de cubrir la mayoría de las opciones. Después de todo, 10 elementos por nivel en un sistema de 4 niveles son 10 000 posibles cargos. ¿Su proyecto es más complejo que eso?

Mostrarme menos

Cuantos menos preguntas y opciones ofrezca a los usuarios, mejor estará. Si hay algo que pueda responder en segundo plano, intente no preguntar a los usuarios en su parte de horas. El objetivo no es recopilar la mayoría de los datos posibles, es recopilar una imagen lo más precisa posible y lo hará mejor si aísla a los usuarios finales de datos, preguntas y opciones que no hacen ninguna diferencia con ellos.

¿Qué hará con esos datos?

A menudo me dicen los tipos de administración intermedia que necesitan "mucho más detalle" de lo que estoy sugiriendo y mi respuesta siempre es la misma: "¿Qué harás con él?" El propósito de recopilar datos del parte de horas basados en tareas es tomar mejores decisiones empresariales, por lo que a menudo les preguntaré a los administradores intermedios qué decisión empresarial no pueden tomar ahora que creen que harían mejor si tuvieran más detalles. Cuando empiece a examinar la información de esa manera, verá que probablemente necesite menos de ella. Puede ser suficiente averiguar solo el número total de horas dedicadas a reuniones, en tránsito o en tareas de sobrecarga que averiguar cuál era cada una de esas tareas.

Profundice más... pero solo cuando se debe

Cuando empiece a realizar un análisis del parte de horas para averiguar a dónde van todas las horas, está obligado a encontrar algunos resultados desproporcionados. Donde encuentre un porcentaje inusualmente alto de horas que desafían las expectativas, profundice un poco más. Pero no demasiado profundo. Agregue una capa más de detalle para ese cargo y asígnele unas semanas para ver qué datos obtiene. La tentación será expandir un código de cargo único como "reuniones" en 50 códigos de cargos nuevos con cada tipo posible de reunión que pueda ocurrir. Intente resistir esta tentación y, en su lugar, cambie ese código de carga de 1 a 5 o 6. Si no obtienes los detalles o sigues teniendo resultados desproporcionados, profundiza un poco más.

Mantener una casa limpia

Las listas de cargos tienden a aumentar el tamaño, pero nunca a disminuir. Es una buena práctica revisarlos periódicamente y eliminar la hinchazón. Si lo hace, es más probable que siga obteniendo información más precisa y pueda identificar las áreas en las que pierde tiempo.

Conclusión

La administración de código de cargo, ya sea para la programación del proyecto o el sistema de parte de horas, puede marcar la diferencia entre un sistema eficaz en el que se pueden contar los datos o un sistema con demasiada definición y no suficiente precisión. Al diseñar la estructura de código de cargo, se recomienda empezar con menos, no más. Es mucho más fácil agregar más detalles más adelante si es necesario que deshacer más detalles y simplificarlo para los usuarios abrumados.

Autor

Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. Tiene una licenciatura en economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar los capítulos de Montreal, Toronto y Quebec del Grupo de Usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.

Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca

Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación de EPM de HMS (https://www.epmguidance.com/?page_id=39).