What are the most common mistakes made with task management frameworks?

Managed a program where the scope was clear, the budget was insufficient and the resources were also insufficient. Years later realized that the program was underestimated.

Including a ranking of “must haves” and “wants”. Additionally knowing if it is an Executive’s special project and or the priority of the effort.

Common pitfall is 'out of scope' tasks being undertaken under the framework umbrella. Particularly likely in multidisciplinary environments whereby plant maintenance or engineering tasks that have previously been rejected for whatever reason are now 'sneaked in under the radar.' Firm detailed scope and sometimes firm conversations are required in order to identify and include / exclude.

The best way to communicate a project's vision is with a conversation with the team who's doing the work. In this conversation, you'll want to encourage others to ask questions so that they fully understand what it is the project needs to be successful. And for those who will be doing the work, don't undervalue the simple questions. I've seen teams feverishly working toward project milestones just to find out they missed a few key functionalities at the last minute. If they had an agreed upon list of what was needed up front (yes, Scrum Masters are OK with defining things upfront as long as their's room to change and adjust!), they could have planned their work better to avoid the stress of meeting the deadline.

It seems that the lack of clarity comes from missing the very first step is to understand the need. Listen, listen, listen. Then ask probing questions. Then mapping out the needs, get a clear full picture.

Biggest issue is defining the priority against other efforts as well as day-to-day maintenance items. As a rule of thumb assume resources only have 30% flexible time.

To get yourself into the prioritization mindset ask yourself this: "Do I want to take ten steps in ten different directions or ten steps in one direction?" Prioritization helps you do the latter. By focusing on the high value tasks and completing them before other tasks are started, gives you an opportunity to say "Hmm...is this good enough?" If yes, you've just saved your business time and money!

One of the main causes of the poor prioritisation sometimes comes from neglecting your client or end user constraints and issues. It is obvious that the techniques like MoSCoW method, or the Pareto principle are very helpful but without considering your client, or outside of your boundaries constraints you will fall short because unforeseen matter made a task in a lower rank while it should be monitored closely or been given a higher priority

Humans are famously bad at estimation! And for some reason, most of us disregard or don't consult historical or empirical data. The best way to overcome our overly optimistic and forgetful tendencies is to break our tasks down into super small units of work. For some reason, it's easier for us to estimate something that will take us one hour versus one day versus one week. Some might argue that breaking tasks down into hour or daily units is too much overhead. Well, in my experience, it's only helped the team move faster since they were crystal clear on the steps forward. (See #1 Lack of clarity)

Estimating a level of effort is incredibly difficult because there are so many unknowns and there’s a pressure to be accurate. As a Scrum Master, my goal is to have a discussion about those unknowns. Discuss dependencies and different strategies. Are there milestone questions, research or spikes necessary to continue? What are risks? The outcome I’m striving for is alignment, transparency and conversation. As much as we want to be right and accurate with estimates, we need to create flexible environment to be wrong and learn too. If we don’t make a safe space to practice estimating then it’ll never get better.

Estimation often considers the effort itself vs the portfolio and as noted where the effort falls within an agreed priority frame work.

Again it goes back to prioritizing and the adage your measures drive your management. If it is important others will want to know. If no one wants to know, park or kill the effort.

One thing that I feel really helps is having regular meetings to ensure things are moving in the right direction and on the right track. This helps catching gaps and misunderstandings.

Change is difficult, no matter what the topic is. I like to lean into the Kubler Ross Change Curve depicts 5-stages of coping starting with denial, anger, bargaining, depression, and acceptance. It’s natural to have negatively charged feelings when presented with change. If we go into a transition with understanding about feelings and emotional needs, we may get to acceptance faster. In denial and anger stages, I give grace that there may be vocal resistance. It’s ok. It’s your Team sharing their concerns. If we looked at it like brainstorming and finding solutions, we may not be stuck in negativity. Over time, our defenses drop and we start to bargain and mourn the loss of “the old way”. It’s in these stages where you can support

Change management must come with a clear understanding of “why” and “so that…”. Once the driver and motivation is understood change management is a function of execution.

Allocating tasks to people that don’t want to do them. This catches me out in every large change effort. It will always show up. So it helps to have a project leader set a tone for safely flagging that it is not something you want to do, so that the task can be reframed, redistributed or removed. Often we build too many tasks anyway! Trust the people that want to do the work to find and fill the gaps.

Change is alway a tough thing, “the unknown”, however change is part of improvement, so sell it that way. Gain buy in, be open and honest. Answer questions, if you don’t know find out. If you cannot say why, be honest and say that. Change is only scary if the reason and outcome are unknown to the people it affects. Don’t be creative with a the story. Be straight and as honest and open as you can. It’s like a jigsaw, remove some of the pieces and hours are wasted filling in the gaps that are always wrong, because we tend to look at the worst.

What you need to work on the most might not be for whom you are performing the work. Example you are working on an operational work tracking system for a specific department. The focus time and again is on that departments unique challenges. Little time is spent on the front end data entry or aquiring data from outside requestor. We will fix that later. The push is to jump right into the meat. We need this process up and working. What you end up with is a resort on an island with most of the worker effort going into shuttling into and off the island. A robust front end that reaches into the initiating departments where the request happens eliminates the manual translation into the new system. Is some one translating? Not effective design.