This week’s blog is going to be a little more practical. My goal is to make your Digital operating model simple and achievable as I know the more complex we make our systems and processes, the more likely they are to fail. Get the basics right and success will follow.

This week I return to talk about, what is in my experience, a major reason why projects fail. I’m not going to talk about prioritisation, I am going to talk about choices. Choices about what work is undertaken and more importantly what isn’t.

I read a lot of posts in various forums with a common thread being the need for structured governance over projects. Organisations may create an Enterprise Program Office (EPO) or Project Management Office (PMO), or other groups specifically to manage their key strategic initiatives. They tend to see things in a binary way. Something is either a PMO project or it’s not.

Organisations have limited project governance resources so the thresholds requiring PMO governance are usually quite high, and not everything that falls outside of a PMO’s purview is necessarily “non-project.” The challenge that this creates is, that with all the organisation’s governance processes focused on these PMO projects, the other non-project work is left largely ungoverned.

However, functional units are routinely charged with managing and delivering work that is of much greater size, risk, and complexity than a typical operational task, but it does not necessarily require the full rigour of an enterprise PMO governance process.

Statistics from the Standish group CHAOS report reveal that most projects fall into this category, being small to moderate in size.

These initiatives that fall in-between the cracks of full project governance and operational tasks get called many things across organisations (e.g. operational initiatives, non-PMO projects, enhancements, and BAU projects), but they’re something I’ve taken to call “small initiatives”.

For me, the term “small initiatives” captures some of the inherent characteristics found in these types of projects: they are typically small, emergent, team-specific, and operationally vital yet generally perceived as being strategically unimportant. As such, top-level leadership has limited visibility of them when they are approving and prioritising major projects.

Without this visibility, leadership approves projects with no insight into how resource capacity is already stretched thin by existing demands, and much of the capacity they think teams will deliver to major projects is fractured by the small initiative demands within those units.

It’s the equivalent to what happens with household consumer debt: if you’re not tracking the small stuff, you’re bound to overspend and compromise your ability to get the big stuff done.

With over half of the projects being identified as “small” or “moderate” in size, even incremental improvements in project visibility will translate into a major improvement in the organisation’s portfolio management practices.

Curse of multitasking

In Lean delivery models like Kanban, there is a very good reason that they all indicate that organisations should limit the amount of “work in progress.”

While the individual cost and impact of each small initiative may be perceived to be small, the hidden impact of these is significant in the form of the impact of context switching and multitasking.

The fact is that nobody multitasks.

“Multitasking is a myth. In reality, it’s rapidly switching from one task to another, and then back again. And every time you make that switch, you pay a ‘tax’ on both your time and your energy. For that reason, it’s almost always more efficient to monotask: Focus on one thing and move on when you’re done, so you don’t pay unnecessary switching taxes.”


In experiments published in 2001, Joshua Rubinstein, PhD, Jeffrey Evans, PhD, and David Meyer, PhD, conducted four experiments in which young adults switched between different tasks, such as solving math problems or classifying geometric objects. For all tasks, the participants lost time when they had to switch from one task to another. As tasks got more complex, participants lost more time. As a result, people took significantly longer to switch between more complex tasks. Time costs were also greater when the participants switched to tasks that were relatively unfamiliar. They got up to speed faster when they switched to tasks, they knew better.

For highly complex specialist activities, that context switching cost can mean the loss of as much as 25 minutes, before a person can regain their focus and be fully productive. When you extrapolate that over the life of a large investment, the overall costs are significant.

Small initiatives come in many forms (e.g. service requests, incidents, officially sanctioned projects as well as a category of “unofficial” projects that have been initiated through other channels).

With no organisational visibility of this work, they tend to only become visible when there is a need for shared resources. What this means, is that if you don’t have a process to manage these activities, at the enterprise level, your scarce digital resources may be being approached for various non-strategic initiatives, to the detriment of your key high-risk investments. This is driving a hidden cost overhead that is undermining your organisation’s ability to deliver on its strategic objectives.

For the functional team, this might not be a significant issue as they tend to self-manage the workload. The major impact is on your digital workforce where all your digital initiatives including PMO projects and small initiates come together, relying on the same skilled people.

Many organisations try and manage this by “ringfencing” or otherwise allocating staff to the project. If organisations can afford to have separate workforces, then that’s a great option, but for most organisations, that’s not a realistic option. Then there are those roles, such as infrastructure engineer or architect, that may not be needed 100% of the time on a PMO project. Can you afford to have them sit around doing nothing when they aren’t needed?

The other hidden cost impact of multitasking is the lowering of quality and increased mistakes. It’s only natural the more your brain is forced to skip between complex tasks, the more you will miss essential detail. That lowering of quality will also have a significant effect on your major investments, not just the cost of rectification, but the lowering of confidence and cohesion of the team.

Clearly, this is an issue that needs to be managed.

Success is about choices, not prioritisation

The key to gaining control of this issue is to gain visibility of this work so that the organisation can make some choices.

After all, this is what executives are there for, to make the choices so the organisation achieves its strategic goals.

The first tip is not to try and prioritise small initiatives, but to make a yes/no choice. Is this something we see value in doing and have the capacity and capability to achieve or not?

This is a key choice because organisations often prioritise all this work, and then leave it to hopefully work itself out. This leads to lobbying, escalation, and distraction, inevitably leading to the loudest voice getting their work done. These are negative behaviors in an organisation that undermines good governance. If you know there is no chance of the people being available to do a piece of work, say ‘NO’ immediately, removing the distraction.

The other mistake I see organisations make is to try and set up a similar process to that used for PMO projects. That is already a major workload for the PMO and the executive. Adding a similar decision-making process for smaller work is not sustainable. Similarly, if it relies on subject matter experts or others to subjectively assess and decide, it is taking these valuable people away from their key role.

Creating Visibility

Using data provides a simple repeatable activity, reducing the administrative burden and enabling faster turnaround on decisions. It has the added value of not creating a scapegoat in the digital workforce. You know what I am talking about, “I cannot get my bug fixed because IT says they are busy, if only……” The role of the executive in this circumstance is to agree on transparent assessment criteria based on your organisation’s goals and vision to drive decision making.

Once executives agree on the criteria, they must all own and support the choices that are made through their application.

With that in mind, the first stage of the process is:

  • Decide on classification criteria for different types of work: (PMO Project, small initiative, operational task)
  • Baseline resource allocation for each type. That will give a broad indication of how much work can be approved, informing the yes/no line. This can be exceedingly high level at this early stage, but ensure you have a mechanism to adjust as you learn more.
  • Decide the criteria to drive the choices to be made and where the yes/no line will be drawn
  • Define a simple appeals process for work that gets a ‘NO’. This is important as your initial criteria will likely reject high-value innovative work

The second part of the process is to make the visibility of these small initiatives seamless and enduring and make the choices transparent. That includes the tracking for delivery.

This is also where a digital mindset helps.

I recommend using low code capabilities such as Microsoft PowerApps, Oracle Apex or if you have them in your organisation platforms like Salesforce or ServiceNow, to automate data capture and decision making. Avoid using IT Service Management tools as not every small initiative will have an IT component, and this isn’t about managing the IT team.

Using the criteria, you define in stage 1, building a simple digital capability to enable staff to submit requests and automatically apply the rules will significantly reduce the admin overhead and provide staff with immediate feedback on their request. But keep it simple at first. Don’t overthink the rules or the data you need to capture, that just makes it more complicated while you learn what you need. The point at this stage is to make it easy and low effort to engage and not incur significant administrative costs for the items that you will inevitably say ‘NO’ to.

At this stage the choices for each small initiattive, should be limited to:

  • YES, engage with the required groups to schedule an appropriate executing date
  • NO, but we will place it on the backlog in case we have an opportunity. (make sure you keep the backlog small. the larger the list the more time you will spend administering it, for very little value)
  • NO, thank you for your idea, but this isn’t something we will pursue.

Including a retrospective of the rules as part of the appeals process, will help to refine the rules.

The data collected allows an organisation to have a wider portfolio view of work underway and through improved tracking and visibility, ensure that value is being generated for the effort. This also enables organisations to allocate time to innovative piece of work that would normally struggle for time, through adding ‘innovation’ as an assessment criteria.

Increased visibility is becoming increasingly relevant in a remote working scenario, where monitoring progress and productivity is impossible without visibility into the work being undertaken.

Whatever mechanism you use to provide visibility must enable those who are tracking the work to update their initiative progress. That reduces the central administrative burden, making the entire process more sustainable.

If you don’t make these choices at the enterprise level, then organisations are forcing their digital teams or other shared resource groups to make the choices for them.

Next Steps

That is a very brief overview of the process to create a small initiative portfolio. There is obviously more detail that is required as you implement but creating visibility will help you manage your workloads and ensure you are getting the best value from your efforts.

If you would like to talk more about how to take a portfolio approach to small initiatives, how to get started with data-driven diction making, or how you can leverage low code capabilities to automate processes, contact me via the link below.