Mandatory projects: What’s the benefit?!

Mandatory projects are annoyingly common in organisations.  They include projects to meet an external compliance requirement – a change in government legislative policy for example.  They also include risk avoidance projects.  These are less obviously ‘mandatory’ as ultimately, they arise dependent on a management decision about what risks are bearable.  Common examples are updates to software or technology to keep in line with new versions. 

I was listening recently to a CIO tell her team that no business case was required for a major infrastructure project because “It was mandatory”.  Are you reacting with the same horror and disbelief to this as I did?  This is either ignorance about the purpose of a business case or a standard power play being made by a technical department that believes they should lead the business – that they know best!

OK, then, what is the purpose of a business case?  And, more specifically, what is its purpose when it is written for a mandatory project?

The purpose of the business case

Let’s consider both the process of creating the business case as well as the output.  Business case development is the perfect platform for building a coalition of support from key stakeholders.  It is during this process that stakeholders’ values and agendas are surfaced, explored, challenged, and common ground found.  Without this activity, the business case document is truly not worth the paper it is written on.

The output, the business case as a document must face two tests from two different governance groups.  The first scrutiny must determine whether the project is ‘worthy’.  Does it return sufficient value to its stakeholders to make it worth investing in?   This is generally an easy assessment to make.  If the stakeholders want it; if they value what it will cause in terms of altered capability – it’s worthy.

The second assessment is much harder and is the reason why benefits as a concept prove so difficult to get agreement on.  The other purpose of the business case is to allow comparisons to be made between projects; to assess which has greater worth – which is the better project amongst the plethora of competing projects?

Consider the case that you can only invest in the performance improvement of just one athlete.  Should it be the world-class swimmer, Sally, or the Olympic runner, John?  You can’t get them both to run or to swim and the winner takes it all.  You are going to have to find a metric that captures something in common between the two – a measure that allows you to make comparative judgments of value between the two competing contenders.

For projects, it’s just the same.  One project offers a reduction of process time by 30% for a business process.  Another provides an opportunity to gain revenue from marketing a new product.  To make a choice, it is no longer reasonable to list what the stakeholders see as good – the changes in operational performance and new markets – now the comparative values probably will get to be described in terms of risk-adjusted financials.

 A benefit lexicon is established by an organisation for exactly this purpose.  But what exactly do you use when the process improvement project is competing against one designed to rebrand the organisation?  You can pretend you can determine the projects’ financial values – but it’s a scam – and you know it.  So, perhaps a deeper abstraction into strategic alignment, or competitive advantage?   Who is the better athlete, or the better bet, Sally, or John?  Why exactly are you investing in them anyway?

What about mandatory projects?

Now take the situation that one of the projects is mandatory.  The need for a business case appears to have fallen away.  If it’s mandatory there is no choice.  It must be done, so worthiness and competition are no longer factors.  Right? 

This is the well-worn argument of those who see that being mandatory is an open sesame to running a project without the ‘inconvenience’ of governance.  And they are so wrong!  Even for mandatory projects, it is just as important to build a coalition of support.  It turns out, one person’s understanding of which solution meets the mandatory condition is not commonly shared by all!   And here lies the rub, and this is why a business case is essential for every mandatory project.  If a project is being run because of compliance or risk avoidance, there are no benefits.  It is being run because the risks associated with not doing so are unacceptable.  

As there are no benefits, the organisation is no better off after the project than it was before.  This means that the criteria for the best solution for a mandatory project, the best project, is the one that delivers a solution at minimum cost.  Surprised?  Surely not! 

However, if a project is going to use the impetus and energy that being mandatory injects to improve performance or capability, if it is going to deliver benefits as well as avoid the risk or deliver compliance, the original purposes of a business case are reinstated.

The trouble with mandatory projects

The fundamental threat posed by mandatory projects to organisations is that they create opportunities for projects to deliver improved outcomes, such as being better, simpler, or faster, “while they are at it.” In other words, since there is no oversight or governance, projects may take it upon themselves to make improvements and deliver benefits without approval from stakeholders. These additional “and-while-you-are-doing-this” improvements lead to increased costs and out-of-control projects.

To steer clear of these issues, declaring a project as mandatory necessitates a strong business case, showcasing its cost-appropriateness. Moreover, if there’s a chance to boost capabilities amidst organizational changes, the business case must justify the extra costs as a worthy investment, yielding returns that outweigh the additional expenditure.

Fostering a culture of responsible oversight and vigilant governance is crucial to mitigate the substantive cost risks posed by mandatory projects.  Furthermore, any potential improvements must be assessed and justified through a rigorous business case.

Stakeholder-led business case development

Over the last few years, I keep thinking that the penny has finally dropped – it’s the stakeholders that count!  People in projects talk about stakeholders, even the project management associations talk about stakeholders, yet when you listen carefully, you start to wonder.  Are the ‘why’ and ‘how’ of stakeholder engagement really understood? 

One area you’d think was undeniably a stakeholder intensive process is the development of the business case.  Surely this is critical to the stakeholders and the investors in the project?   But no! Today, business cases are often written by specialists in writing business cases, or worse, the project manager, and often in parallel or even after the project has started.

One relatively recent improvement is that you find a whole section entitled ‘Stakeholders’ in a good business case.  Yes, it has an entire section!  But often, the content and purpose are problematic.  It should neither be a list nor where stakeholder analysis is written up.   What it should do is provide evidence in support of the three functions of any business case.

What are these three?

Projects, portfolios, and programmes: The real role of the managers

Portfolio management is not just multi-project management

Some portfolio managers, especially those with strong project backgrounds, interpret their role as being a multi-project manager. They see it as their responsibility to make sure that all the projects are completed satisfactorily. That just isn’t so—that is the remit of each one of the project managers. Others see their role primarily as reducing conflict for resources. They do this by prioritising and re-prioritising access to labor and kit, leading to an endless game of juggling as each solution generates the next bottleneck.

Neither of these views is correct. The real job of project portfolio management is to maximize the throughput of projects that implement the deliberate strategy of the organization.

Are you creating the space for meaningful engagement?

Yet again, Gift of the Givers is on the front line in providing humanitarian support – this time in Ukraine. 

Six years ago, I had the good fortune to hear Dr. Imtiaz Sooliman give a key-note presentation at the PMSA conference in Durban. It is a presentation I will never forget, not only because of the amazing things that the Gift of the Givers are doing but also because of the project lessons and project learning he conveyed. I think the project profession could greatly benefit from hearing more about how these types of organisations make the impossible happen.

Dr. Sooliman is a captivating presenter. Hearing his story about how he came to take on the role of humanitarian champion here in South Africa and globally (in places like Afghanistan, Syria, and Chechnya) is inspirational. I was at the Durban conference talking on stakeholder engagement, and his discussion about how the Gift of the Givers set up their aid projects had many resonances.

Stop looking for a superhero project manager

I have a memory passed down via family members that as a 9-year old when I was asked what I wanted to be when I grew up, I responded that I wanted to be an expert!   I’m sure my parents find it a very irritating response and would have preferred an answer like doctor or engineer or lawyer!

Whatever I meant at that time, I am pretty clear now, that this is just not possible. Today there is so much information, so many insights and experiences that we need access to as project managers–this cannot possibly dwell in the body and spirit of one person. Karen Stephenson captures it perfectly in her phrase,“I store my [know-how] knowledge in my friends”.

Addressing “Why now?” in the business case

We tried that before!

There are so many good ideas in every organisation!  Most you never get to hear about.  Inertia, change weariness, and poor politics account for much of this waste.  But there is another killer weapon: “We’ve tried that already!  It doesn’t work!”

You’ve used, I’ve used it—such a showstopper.  In one go, you’ve asserted your prescience, your historical rectitude, and just a smidgeon of arrogance.  Not bad for seven words!

The CEO of the company I worked for had a rule: Every recruit for the first 100 days was required to ask questions and suggest ideas.  During these first 100 days, new staff have new and excitingly different perspectives.  Of course, they and you want them to integrate with the company, but this is when they also want to be seen to make a difference.  Over time they become more and more part of the company, absorbing its culture and history.  They adopt the company’s stories and beliefs.  Once fully integrated, they become part of the narrative, and this window of opportunity is lost.

Of course, they do ask annoying questions like, “Why on earth do you do it that way?”; “Why haven’t you done it this way?”, “Have you tried doing this?” But the crucial part of the CEO’s rule was; “Every question and every idea had to be listened to and considered fully by everyone in the company”.  The one response that was forbidden was, “Nah, we tried that before!”.  Nothing kills creativity and innovation than that particular wet blanket, especially when it’s delivered, as it so often is, with a sigh and a pitiful look as if to say, “You don’t think we didn’t think of that!”

But the truth is that just because it didn’t work last time does not necessarily mean it’s not right now.

Benefits come first

You’ve done it! I’ve done it!  It seems so natural.  You start the story at the beginning, and you then follow the narrative until you come to an end – and you find out who did it and why.

That’s fine for a novel, even if it is a little traditional for some modern authors, but it’s a terrible way to write a business case.  Choose a template for a business case, and there it is:

• Statement of the problem
• Analysis
• Discussion of possible options
• Recommendation
• Details of your chosen option

It’s a novel!  And you are the detective, trying to find out what crime has been committed.  Wrong, wrong, wrong, wrong!

Stakeholder DIS-engagement

Have you ever been invited to contribute to an initiative? Attend a meeting? Complete a questionnaire? Been interviewed? 

Then weeks later, you thought – what happened there?  How was my input used? I wonder, was my input used at all?  What happens next? It’s not a pleasant feeling – it’s almost a feeling of being duped. Experiencing this, you could be forgiven for being wary about giving your valuable time again.

The Accidental Mentor

For many of us, mentoring is not something we have been trained in but is something we fall into.  You wake up one day, and somebody has asked you to be their mentor. Or even more surprising, you overhear a conversation – “Louise is my mentor”!  And you think, am I?  When did that start? Am I any good!

When I came across the wonderful initiative, The Mentoring Club, and decided to sign-up, I had to ask myself: What kind of mentor am I, and how can I truly be of value to the people I connect with?

From my experience, there are many reasons for being involved in mentoring – as a receiver or giver.  It won’t be a big surprise that the purpose of the mentoring changes the nature of the relationship between the mentor and the mentee and the conduct of the mentoring itself. 

Culling projects: A critical portfolio process

With most organisations reporting more projects that they can resource, stopping projects which are addressing yesterday’s problems may be even more important than not starting those projects designed to address today’s.

In a review of 15 client portfolios, the UK project consultancy group, CITI reported that in annual portfolio prioritisation more than one-third of the projects and programmes approved were carried forwarded from previous years, with 20% having survived two annual review processes.  The question perhaps to ask is – does this reflect a real need for long-term projects or is it that management decision making around stopping something is just so much harder than approving a project to start?

Significant portfolio management attention has been paid over the last few years to developing improved governance processes around the front-end selection and prioritisation of projects.  But portfolio monitoring and control is a much greyer area and often confusion arises between the governance responsibilities at the portfolio and project sponsorship levels.

Great project managers have great networks

Much research over the last twenty years has attempted to identify the characteristics of successful project managers. However, more recently, this has been questioned and replaced with a more interesting debate. What makes for successful project management? The argument goes that even the ‘best’ project manager acting alone without support from the organization and appropriate collaboration with peers and other stakeholders is unlikely to be successful.

In our own research on the characteristics of successful project managers, we found that the high performers were much more likely to have extended personal and professional relationships within and outside their organizations. It wasn’t just that they had more expertise to draw upon, but also that when they needed to interact with stakeholders, to further the goals of their projects, they were more likely to have pre-existing relationships to draw upon. They built up and valued ‘social capital’ in ways that less experienced project managers were unlikely to do.

Great project managers have great networks

What makes a good benefits analyst?

Some years ago we published the results of a survey on what were the key skills and competencies of a portfolio business analyst.  Even then we struggled to find a suitable and commonly used job title for those analysts involved in supporting the development of business cases and benefits management plans.  We have come across so many names – business case analyst, benefits analyst…

Five years later and benefits management remains an aspiration rather than a reality in most organisations.   Heather van Wyk presented on her experiences in benefits management at the EMEA PMI Congress in Berlin.  She relates how, when she quizzed the audience, only a handful of participants felt that businesses were successful in implementing effective benefits processes.

Want more pace in your projects? Governance is the key

Increasing the pace of delivery of projects takes a lot more than just working faster.  For most projects the biggest time-thief is decision-making.  It’s not the effort, it’s the elapsed time it takes to appraise the various stakeholders of the issue, get a consensus and then transmit their response to the project. If you really want to increase pace of delivery, then it is the elapsed time-stealers that have to be streamlined… and of these, the most important? Governance.

Going solo: The project management way!

Last year I watched my daughter make her first solo flight in a light aircraft.  That means she took off in an airplane on her own, and landed it. She was just 16 and had ten hours training.  The first I knew it was happening was when the instructor said quietly to me,  “You might want to stay around to watch this lesson!”.

Photo by Martin Adams on Unsplash

If you haven’t experienced going solo in a airplane, this is pretty much how it works. After you’ve made three perfect landings in a row, the instructor casually remarks: “Not bad, why don’t you do the next three circuits on your own?”  They then climb out of the airplane leaving you alone with the engine running and ready to go.  At that moment the airplane seems tremendously quiet, the right-hand seat looks tremendously empty and the runaway looks tremendously short!

From right-size governance to agile governance

If you’re working in a structured project environment with a project office, the chances are that you are using a right-size governance approach.

What does that mean?  Essentially, the level of management attention and oversight varies appropriately, depending upon the characteristics of the project, such as size and complexity, or the level and significance of the impact of the project on the organisation. 

Is Agile a planning-free approach?

The introduction of Agile as a software product development approach is having a significant and positive impact upon the way IT projects are delivered. However, in our coaching interventions, we are finding some confusion among project managers. Some experienced project managers quickly learn how to adapt and integrate Agile practices into their toolset. It is just another approach, which used appropriately in the right projects increases their ability to deliver. Others move straight to denial; change-weary, they avoid or downplay the usefulness of the Agile framework– “It’s nothing new.” That is their loss! Of greater concern are the more junior project managers who, faced with Agilists, lose their bearings. “What is my role in this?” “How does the governance work?” “How do I plan?” And most worrying–“Do I need a plan?”.

Research Project: Leadership and organisational agility

The Significance of Organisational Agility

In the contemporary business landscape, organisational agility has become a prevailing theme. Management literature abounds with the buzzword, depicting an agile organisation as one that is lean, innovative, customer-centric, flexible, adaptable, and swift in responding to changes. Embracing agility necessitates not only a shift in organisational structures but also flexibility in leadership styles and the individuals assuming leadership roles under varying circumstances.

Research on Leadership Agility

Building upon the work of Katheryn Wells & Tim Kloppenborg and Anantatmula & Kloppenborg (2021) on the critical leadership competences for the roles of Scrum Master and Product Owner, the aim of this further research is to explore, in the South African context, the critical leadership competences for these two roles and, in addition, which leadership styles promote self-empowered teams.

We are interested in gaining input from people working in and around Agile projects.

Research context

The video below aims to prompt your thinking about leadership and sets the context for the research. We do encourage you to have a look at this before completing the survey.

The Survey Questionnaire

Now you have had a look at the video, consider:

• Which of these leadership approaches are relevant to you?
• What good and bad leadership practices have you observed in your organisation?
• What do you think is the most important leadership skills when working in Agile teams?

The questionnaire is in Excel format and should take about 5-10 minutes to complete. It provides lists of competences grouped into three levels:

• Value of responsibility

• Value of Relationship

• Value of respect

These are the levels and competences that have been identified in the initial work in the USA. We would like your views on which of these you think are most important to three roles:

• Scrum Master
• Product Owner
• An empowered team member

And we would also love to hear what you feel has been missed. Do let us know your thoughts in the free format comment boxes provided.

Please email your completed Excel sheets to Louise Worsley, lworsley@pi3learning.com

agile-leadership-survey.sa_-1Download