Leadership

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.

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.