Project and Programme Management

Harnessing Ethical AI in Project Leadership: Navigating the Intersection of Technology and Integrity

Posted on by holnor

Artificial Intelligence (AI) is rapidly transforming project management, offering faster decision-making, efficient workflows, and advanced predictive capabilities. However, integrating AI into project governance requires careful consideration of the ethical complexities involved. Embracing ethical AI practices is crucial for the success, sustainability, and inclusivity of the projects we lead. This article explores the importance of ethical considerations when using AI in project governance, highlighting risks, opportunities, and actionable strategies for project professionals to lead with integrity.

The Risks of Bias in AI Algorithms

One of the primary concerns with AI implementation is the potential for bias. AI algorithms learn from historical data, which can expose projects to inherent biases. If the data reflects societal or organisational inequalities, these biases can propagate in AI-driven decisions. For example, if an AI resource allocation tool relies on historical data that disproportionately assigned leadership roles to a particular demographic, it may reinforce these patterns. This can undermine efforts to foster diversity and inclusivity within project teams, affecting morale, creativity, and productivity.

To mitigate this risk, project leaders must critically evaluate the data sources and design of AI systems to ensure fair and unbiased decision-making. This involves probing vendor assurances, conducting periodic audits of AI outputs, and maintaining oversight protocols to identify potential biases early in their manifestation. Ways of achieving this include:

Transparency in AI Decision-Making Mechanisms

Ethical AI solutions must operate transparently. Stakeholders, including project sponsors, team members, and regulatory bodies, need clarity on how decisions are made by AI systems. Black-box algorithms—those whose logic is obscure or incomprehensible—pose significant challenges in this regard.

Transparent AI systems enhance governance compliance and build trust among stakeholders. Project managers should advocate for explainable AI (XAI), which allows users to understand and challenge the rationale behind AI-driven recommendations or actions. Championing clear documentation of AI decision-making processes ensures that AI functions as an enabler, not a potential disruptor. To achieve this requires:

  • Clear Explanations : Providing clear and accessible explanations of how AI models work and the factors that influence their decisions.
  • Documentation : Maintaining detailed records of AI model training, data sources, and decision-making processes.
  • Feedback Mechanisms : Establishing channels for stakeholders to provide feedback and raise concerns about AI-driven decisions.

Building Stakeholder Trust in AI-Driven Governance

Trust is the foundation of any effective governance process, and AI’s role in project leadership requires heightened sensitivity to this principle. Stakeholders may harbor scepticism or fear that AI dehumanises decision-making, jeopardising their agency, fairness, or even job security.

To foster trust, project professionals should engage stakeholders proactively through open communication about AI systems’ capabilities, limitations, and safeguards. Training and upskilling initiatives can also empower teams to work effectively with AI, instilling confidence in its utility while reinforcing that human oversight remains a priority. Showcasing success stories where AI-driven governance has yielded tangible project benefits—while adhering to ethical norms—can further enhance buy-in among stakeholders.

Steps to garnering trust in AI and therefore adoption include:

  • Open Communication : Maintaining open and honest communication about the use of AI in projects.
  • Pilot Programs : Starting with pilot programs to test and refine AI solutions before widespread implementation.
  • Human Oversight : Emphasising the importance of human oversight and judgment in all AI-driven processes.

Balancing Automation with Human Oversight

AI offers powerful automation capabilities that can streamline processes. However, over-reliance on automation risks ethical oversights, where adherence to speed or efficiency comes at the expense of fairness and nuance in decision-making.

Balancing automation with human oversight is essential for ethical project management. AI should augment judgment, not replace it. Project professionals play a critical role in auditing AI-driven recommendations, revisiting decisions that impact people or stakeholder groups, and ensuring that the “human touch” remains a vital part of governance frameworks. Instituting review protocols where AI decisions are periodically validated by human stakeholders can help achieve this balance effectively. Over-reliance on AI without human review can lead to errors and unintended consequences. Project leaders should:

  • Define Clear Boundaries : Establish clear boundaries for AI’s role in decision-making.
  • Human Review : Ensure that critical decisions are always reviewed by human experts.
  • Continuous Improvement : Continuously evaluate the effectiveness of AI systems and make adjustments as needed.

Advocating for Ethical AI Practices in Projects

Project Portfolio Management (PPM) professionals have a unique responsibility to advocate for ethical AI practices across projects. This involves embedding ethics as a guiding principle in project charters, governance frameworks, and stakeholder engagement strategies. Encouraging organisations to adopt AI governance guidelines or frameworks—aligned with global standards—ensures that integrity remains at the forefront of innovation.

Moreover, ethical AI in project leadership requires a multi-disciplinary approach. PPM professionals should collaborate with data scientists, ethicists, and compliance officers to embed ethical practices into the design, implementation, and scaling phases of AI tools. Creating forums for ongoing dialogue about AI ethics within project teams and sponsoring organisations can provide a platform to address emerging challenges and share lessons learned.

A Call to Action for Project Leaders

The incorporation of AI into project governance presents enormous opportunities. However, the ethical stakes are high. Biases in algorithms, opaque decision-making, and diminished trust can derail even the most technologically advanced initiatives.

Project professionals are custodians of the responsible application of AI technologies. By championing transparency, fairness, and accountability, project leaders can ensure that AI systems serve as enablers of progress, equity, and excellence. Ethical AI is a cornerstone of good governance. Let us harness its potential wisely to lead projects that deliver meaningful and inclusive outcomes for all stakeholders.

Harnessing the Power of AI in Project Governance: Driving Better Decisions, Reducing Risks, and Achieving Goals

Posted on by holnor

Introduction

In today’s fast-paced and complex project management landscape, effective governance is the key to ensuring projects are delivered on time, within budget, and according to established objectives. As the scale of projects grows and variables multiply, project governance teams are increasingly turning to artificial intelligence (AI) to gain a competitive edge. By leveraging AI-driven tools and analytics, organisations can transform traditional governance processes, redefining how risks are managed, resources are allocated, and progress is monitored.

Enhancing Risk Management with AI: Predicting Challenges Before They Arise

Managing risk in large-scale projects can resemble navigating through a dense forest with limited visibility. AI serves as an advanced compass, leveraging historical data, trends, and patterns to predict potential obstacles. AI tools analyse past project outcomes, market trends, and a variety of external factors to anticipate risks and flag potential issues early on. Whether it’s identifying supply chain vulnerabilities, potential resource shortages, or compliance risks, AI empowers governance teams with actionable insights, enabling mitigation strategies to be implemented before risks escalate into project roadblocks.

Predictive Analytics: Transforming Forecasting Into Precision Science

AI’s predictive analytics capabilities are revolutionising project governance by enabling more accurate forecasting of critical variables such as costs, timelines, and resource utilisation. By analysing historical project data in conjunction with current inputs, AI algorithms generate highly reliable forecasts, helping project managers make data-driven decisions. The days of relying on gut instincts and broad estimations are giving way to a new era of precision management, where data ensures that plans and execution are closely aligned and surprises are minimised.

Real-Time Dashboards: The Evolution of Project Monitoring

One of the primary responsibilities of project governance is to track performance against goals and ensure compliance with organisational standards. AI-powered real-time dashboards are not just tools to visualise data but are transformative platforms that offer deep insights into key performance indicators (KPIs). These dashboards can integrate data streams from multiple sources, simplify complex scenarios, and provide stakeholders with instant updates on project health, resource allocation, budget adherence, and risks. Moreover, AI-driven features such as anomaly detection can highlight deviations and foster proactive corrections—keeping projects on track with minimal manual oversight.

Challenges Along the Way: Adapting AI to Legacy Project Governance Systems

As promising as AI might be, integrating it into existing project governance frameworks comes with its share of challenges. Legacy systems, many of which are rigid and outdated, can make it difficult for organisations to reap the full benefits of AI tools. Data silos, resistance to change, and the need for upskilling teams to understand and apply AI insights are common hurdles. Organisations will need to invest not only in technology but also in change management programs to ensure successful adoption and alignment with their governance practices.

Success Stories: Real-World Applications of AI in Project Governance

Despite these challenges, several industry leaders have already paved the way, showcasing what’s possible when project governance aligns with AI-powered solutions. For instance, in the construction industry, predictive analytics tools are helping firms forecast project costs and timelines with unprecedented accuracy. Similarly, AI-enabled risk assessment software is aiding financial institutions in managing compliance risks in complex projects, while manufacturing companies are using real-time monitoring systems to track supply chains and resource availability.

The Future of AI in Project Governance: A Shift from Reactive to Proactive Management

As organisations around the world embrace digital transformation, AI presents an unparalleled opportunity to redefine project governance. By offering predictive insights, real-time monitoring, and data-driven decision support, AI helps project managers and governance boards focus more on strategy and value creation. However, the journey to successful integration will require carefully navigating implementation challenges, fostering a culture of openness to innovation, and ensuring the right mix of technology and talent.

Ultimately, the integration of AI into project governance is poised to be a game-changer, helping organisations achieve their strategic objectives more effectively while embracing a culture of informed and responsive decision-making. Organisations that embrace this transformation now stand to lead the way in shaping the future of project management.

Agile from the Professional Services Perspective

Posted on by holnor

IMG_2574

Recently I was asked whether Agile is a viable proposition for Professional Service Organisations (PSO) to use in the management of projects? If so, what factors need to be taken into account?

Before answering this, it’s important to note that while Agile is a framework for Software Delivery, it is not a project managment methodology. This is a common misunderstanding. It is crucial to understand this when dealing with multi-discipline and multi-team projects.

In Scrum, (an Agile approach) an ideal team is made up of between 6 and 8 co-located members, all focused on the delivery of a product. If that product is independent of all other products then Agile is sufficiently structured to act as a quasi project management methodology. However, for all other types of project it is insufficient. Agile ignores all of those project management tasks required to ensure each team is working in a manner that supports and facilitates the work of the other dependent teams. It also ignores all those activities such as business case development, status reporting and change management that, while not delivery tasks per se, can be the difference between project success and failure.

That said, it is still true that from the perspective of a PSO Agile is the optimal mode of solution delivery. It allows for certainty in the engagement; as the customer is actively involved on a daily basis. It significantly reduces the gaps in engagement. For example, where the solution is handed over for UAT and the team waits for feedback before being able to finish. This in turn allows for greater resource utilisation and this means each project is potentially more profitable.

So why don’t all PSO’s use Agile all the time? Simple – often the customer can’t or won’t commit to the level of engagement required. You know the story, the key people needed to make decisions and sign off on the solution all have day jobs which prevent them from being available when they need to be. This means that the project stalls, or worse yet, takes the wrong direction when working on an ambiguous requirement. This is the typical scenario when dealing with smaller customers in particular.

An additional complication to the above comes with the customer’s lack of an internal IT function. Why is this a problem? Well, it prevents a project being truly Agile, as they will not have the capacity to automate the delivery of the solution into production (i.e. continuous integration/continuous delivery – CICD). CICD is a mandatory element of Agile projects which is often overlooked. Furthermore, if you don’t do it, then you aren’t truly Agile.

The PSO can set up CICD to deliver into an interim environment (usually a test environment); then manually release into production. This is a hybrid solution that will allow development to continue while the customer tests what has been delivered. Of course, in smaller projects the CICD overhead just isn’t worth it, as end to end the project is only going to be 1 or 2 sprints in duration (2-8 weeks). That is unless the customer wants to become Agile. In that case, setting up the automation mechanism becomes a proejct in its own right.

One other obstacle for a PSO using Agile to deliver a project is the contract itself. Many customers will view the initial statement of work as being a fixed price, no matter how you word it. The result is a rigidity in the project that prevents the team reacting to change in the way that Agile promotes. The change process has to be formal out of necessity for the PSO. It is the only way that a PSO can hold the customer to account for spurious changes, delays and the resulting cost overruns.

 

 

Agile in Mixed/Outsourced Environments

Posted on by holnor

IMG_2312

In 2011 I wrote a dissertation on Agile and outsourcing. After analysing all of the data I had collected along side that publicly available from various sources including Microsoft, Ambysoft (http://www.ambysoft.com/surveys/) and The Agile Alliance the only conclusion I could reach is that Agile and Outsourcing were incompatible. The fundamental obstacle was the contract between the vendor and the client.

Things have come a long way since then and it is possible to run projects in an agile manner. But only if the client understands the level of commitment required on their part. Having been on both sides of the contract I am finding that there is still a disconnect here. Often the expectation is that an Agile project can be run with the same level of customer engagement as a project run under a waterfall methodology, with a greater degree of success.

I exclude body shop engagements from the above as in those cases the reality is that the customer isn’t paying for the delivery of a project they are paying for the use of a specific type of resource/expertise.

So when are outsourced Agile projects successful? When the vendor is responsible for the delivery of the solution and has full commitment from the customer to be available at the agreed level. It all lies in the structure of the contract. The contract needs to be balanced and clear about the responsibilities of both parties and state the consequences from a delivery perspective if any of those responsibilities are not met.

Agile also does not work under a fixed price contract as the core tenet of Agile is the ability to deal with change. and fixed price is the antithesis of change.

Failure to acknowledge any of this is a recipe for disaster.

 

 

Embracing Creative Destruction to Get Ahead

Posted on by holnor

IMG_3023.jpg

In this recent post by Rohan Rajiv are some novel insights into what traditional companies need to do to get ahead of their rivals. While his focus is on the technology sector and how to compete against the big tech companies the lessons are valid for all. In particular the idea that the innovation curve is no longer contiguous.

The idea that innovation has jumped ahead and that there is a chasm between the market leaders and the traditionally solid performers should resonate no matter what industry you are in. It is just more evident in technology.

So, how does Rohan suggest that this chasm be bridged? By accepting that many of the tried and tested ideas that have made us reasonably sucessful will no longer to continue to bring success. Once this is understood it is easier to identify novel ways of challenging the status quo. Not all of them will work but those that do will accelerate business success. If a company takes a learn fast approach (see my earlier post for more on this idea) then the ideas that don’t work will encourage a culture of entreprenuerism within the company that will further accelerate success.

Over the years I have worked with a number of non-tech companies on transformation projects. The most successful of thes have seen the internal conversations revolove around how to manage the transition away from the traditional business model (e.g. we sell data products) to a new paradigm where the company is selling a technology based and data driven partnership with the customer.

Rohan’s over arching theme of “creative destruction” is one that the top tech firms have embraced wholeheartedly. For example Microsoft have stopped being Windows centric in the development of its productivity suite with updates oten being provided to other plattforms (iOS in particular) first. The idea is that they want a piece of every device out there. This is a variation of what Amazon has done with it’s market place. They want a piece of every online transaction and don’t care if they sell the product or someone else does.

Applying creative destruction in our professional and personal lives is not something that comes easy. However, if we are realistic, the days of a person holding a job for life are long gone and  there will be times in which it is essential for us to reinvent ourselves in order to stay relevant within constantly evolving industries.

A classic example of this is traditional manufacturing in western countries. Repetitive low skill jobs are either been performed by robots or have been moved off shore to countries with cheaper labour rates. The remaining manufacturing jobs are high tech and higly skilled. The result is a significant jump in unemployment while people retrain or find alternative low paid work (if it exists).

So no matter who we are and what we do, unless we embrace change we will find it increasingly difficult to keep up. Or as Rohan sums up “what got us here won’t get us there.”

 

BBC DMI failure

Posted on by holnor

The failure of the BBC’s DMI programme is a prime example of why it is so important for senior IT management to insist on having fully engaged, committed and responsible business stakeholders. If that isn’t happening then the programme manager / CTO needs to put the programme on hold until the right people are involved from the business.

http://www.cio.co.uk/blogs/editor-in-chief/bbc-trust-board-must-accept-blame-in-digital-archive-disaster/

The Agile Project Manager – Does it exist

Posted on by holnor

Recently I attended a seminar on “Agile” software development. One of the statements made by the presenter was to the effect that once agile is implemented properly an organisation will quickly realise that they don’t need project managers. The reason… the close, frequent interaction between the business and developers means that the management of a project is handled almost as a by product.

I’m not convinced by this thinking, unless it is restricted to the simple case of a small project with a fully committed and engaged product owner. In more complex situations (e.g. Multiple agile development teams working on a project in parallel) someone is needed to keep everything lines up and remains on track. Sounds like a project manager (PM) to me…

So in this situation, what makes a Project Manager an Agile one? How can you recognise one? First and foremost an agile project manager will be able to facilitate two competing needs

  1. help the project accept and adapt to change
  2. prevent change impacting the project delivery

This is the challenge in agile, where it is possible to do everything the client asks but not everything they ask for should be done. If you only have a product owner and the scrum master then in complex environments the former is likely and without the checks and balances that a disciplined project manager brings to the table then projects will fail.

I do believe the nature of project management will change. With more and more projects being delivered using agile or lean methodologies it has to. The focus for a project manager will become ensuring the delivery of the right thing at the right time whether that is requirements, designs, code or a functioning product. This is essential when the paradigm is iterative.

Project managers will live and breathe the mantra “if you don’t need it now… it can wait” and every will focus on Just In Time delivery. Or it will once vendors and customers figure out how to work effectively together using agile…

Lessons Learned – not a one off activity

Posted on by holnor

So many times I have been involved in projects where once the solution has been delivered a project manager, sponsor or vendor will say “now we need to review the project and record the lessons learned”. The idea being that the lessons can then be used to ensure those mistakes aren’t repeated, or that things that really worked well can be replicated on subsequent projects.

Sounds good, right? Wrong! Why should the next project be the beneficiary of your hard won lessons? A lessons learned log should be maintained throughout the life of a project. The log should be reviewed and discussed within the team regularly and include stakeholders or their representatives from the business. That way you can:

  1. prevent poor behaviour recurring
  2. identify good behaviour and encourage it to be repeated
  3. capture key business drivers that have been highlighted by any issues that have arisen
  4. highlight areas of conflict between business areas (e.g. Sales v marketing) and the best mechanism(s) for resolving the conflict.

By doing this throughout the life of a project, the project becomes self correcting as those individual experiences are shared with the team. This reenforces behaviours, establishes trust within the team and with the business and ultimately helps improve the chances for the successful delivery of the project. At the end of the day delivery is what it’s all about.

Communication – a lesson I learned in Starbucks of all places

Posted on by holnor

Sitting I Starbucks a Saturday or so ago having a quiet coffee and reading the paper. It was the last place I was expecting to learn this lesson. A group of 6 young kids (ages ranging from about 4 to 6) and their mothers came in to the store, pushing and shoving and generally having fun as kids do. The striking thing about this group though is that every single person had a hearing impairment including the adults.

The thing that struck me was that if they wanted to “talk” to someone they had to establish eye contact. Because of this everyone paid attention to each other and the conversations were clear and concise. There were no misunderstandings in regard to what was expected, what each of them wanted or indeed how they felt.

In this day and age where communication is becoming more and more remote with less and less face to face interaction it made me sit up and take notice. I’ve lost count of the times over the last 6 months where email or IM communications have spiralled out of control over a subject or situation that could have, should have and ultimately were resolved by having a 5 minute face to face conversation.

There is a clarity of purpose and intent that can be conveyed in a look or the tone of the voice that is absent in written material. Without this the effort needed to gain the same clarity goes up exponentially with the complexity of the subject.

So next time you find yourself on your third email explanation of something “simple” maybe it’s time to pick up the phone, or better yet get up and go talk to them?

The Trouble with Metrics

Posted on by holnor

Over the years I have worked on a number of back office system projects. Typically they projects are aimed at delivering either cost savings or performance improvements (or optimistically both). Naturally management are eager to monitor and calculate how much of each is achieved. To that end they look to set up a number of measurements that will show the level of uptake, throughput, cost per unit etc.

When the system is designed to make it easier for someone to do their job you would expect that their productivity would increase… Makes sense right? But it’s not alway the case. For example implementing a system that makes it easier for a sales rep to capture the client details, record conversations and track follow up actions will only increase the productivity of the rep if their job doesn’t require them to meet the client face to face. It would be pointless therefore trying to measure the benefit of the new system and the performance of the rep on the basis of the number of phone calls the rep makes each day. If you do then the result of that will be to encourage sales reps to sit at a desk and make phone calls. Not a good result when what you really want from them is to be generating new sales and building relationships with clients so that they become repeat customers.

Therein likes the problem with metrics… Get them right and they will be able to tell you a story of how your business is performing, identify areas for improvement and highlight those activities that are contributing to good performance. Get them wrong and they have the unintended consequence of influencing peoples behaviour toward irrelevant tasks that should not be their focus.

A classic example of this is the UK government target that no patient should wait more than 2 days to see a doctor. The result… When you ring up to make an appointment many doctors won’t allow you to make an appointment that is more than 2 days in the future as it will distort their statistics. Additionally if there are no appointments available you have to ring back the next day in order to make an appointment for 2 days in the future (rinse and repeat until you get in early enough to beat the rush). They do this as the government is not interested in how many people are unable to make an appointment on their first, second, third (or more) attempt. But I’m almost certain this was not the behaviour that the government was trying to encourage. It’s just the unintended consequence of a poorly thought out and defined metric.

So when determining what metrics should be used to measure performance, you must determine (either for yourself or your client/customer):

  1. is the metric relevant (to the job and/or system)
  2. what behaviour is use of the metric likely to encourage (and is that what you want to happen)
  3. is the information the metric conveys actionable
  4. what are you going to do with the information

If the answer to any of the above is negative then it’s probably not the right metric to be using. On the bright side though, being able to identify this will make you look good and help avoid some of the post implementation pitfalls that beset many projects.