Project Management & Commercial Development

Description

SCRUM is widely adopted in banking IT departments, but its application runs into constraints specific to the sector: compliance sign-off, regulatory acceptance cycles, dependencies on legacy systems. This two-day course teaches the framework as defined, then explicitly works the friction points with the banking environment. It follows one project case from beginning to end.

Learning objectives

By the end of the course, participants will be able to:

• Locate the roles, events and artefacts of the SCRUM framework
• Hold a role within a SCRUM team and understand its limits
• Facilitate the ceremonies and obtain the value expected from them
• Build and refine a product backlog
• Estimate and plan an increment realistically
• Reconcile the agile framework with a banking institution’s compliance requirements

Teaching methods and resources

Structured input followed by application exercises on a banking project case running through the course. Ceremony simulations, backlog writing workshops, collective estimation exercises. Reference materials on the SCRUM framework and a team diagnostic grid. Validation quizzes at each stage.

Course programme

1. Locating the framework and its foundations

• Distinguish predictive and empirical approaches
• Understand the three pillars: transparency, inspection, adaptation
• Identify what SCRUM prescribes and what it leaves open
• Spot the contexts where the framework is not suitable

Practical work: positioning quiz on project situations. Discussion of cases where the agile framework adds nothing.

2. Understanding the roles and their boundaries

• Locate the responsibilities of product owner, scrum master and team
• Address the frequent confusion between project manager and product owner
• Organise the relationship with stakeholders outside the team
• Identify the signs of a role poorly held

Practical work: allocation of roles on a banking project case, then analysis of the overlaps identified.

3. Building and refining the product backlog

• Write backlog items the team can actually use
• Define acceptance criteria and the definition of done
• Order the backlog by value and risk
• Organise refinement without spending excessive time on it

Practical work: writing a product backlog for a real banking need, then cross-review between subgroups.

4. Running a sprint

• Facilitate planning and obtain a realistic commitment
• Hold the daily scrum without it becoming a progress report
• Conduct the review and gather useful feedback
• Run a retrospective that produces actions

Practical work: simulation of a complete sprint in accelerated time, with the four ceremonies in sequence and a collective debrief.

5. Making SCRUM work in a banking environment

• Reconcile increments with regulatory acceptance cycles
• Handle dependencies on existing systems
• Document enough to satisfy audit without burdening the team
• Report progress to a traditional project governance

Practical work: building a reporting arrangement compatible with traditional project governance. Presentation and discussion of the compromises.

Description

Transformation projects rarely fail for technical reasons: they fail because their organisational complexity was not assessed before resources were committed. This two-day course provides the methods for making that assessment upfront: stakeholder mapping, identification of dependencies between workstreams, and detection of success conditions that are not in place.

Learning objectives

By the end of the course, participants will be able to:

• Assess the organisational feasibility of a transformation project
• Map stakeholders and their actual positions
• Identify dependencies between workstreams before they block progress
• Spot missing success conditions and escalate them
• Locate a project within the organisation’s portfolio and priorities
• Formulate a recommendation to proceed, postpone or abandon

Teaching methods and resources

Methodological input illustrated by real transformation projects, both completed and halted. Mapping workshops, dependency analysis exercises, case studies. Organisational feasibility assessment grid and stakeholder matrix. Peer exchange between participants.

Course programme

1. Understanding what makes transformations fail

• Distinguish technical, organisational and political causes
• Spot the warning signals already present at framing stage
• Locate the sponsor’s role and the consequences of their absence
• Identify projects launched for the wrong reasons

Practical work: guided analysis of two transformation projects, one completed and one halted. Identification of the tipping points.

2. Mapping stakeholders

• List the actors concerned beyond the official sponsors
• Distinguish stated position from real interest
• Identify useful opponents and fragile supporters
• Build a differentiated engagement strategy

Practical work: stakeholder mapping of a banking project, positioned on an influence-interest matrix.

3. Identifying dependencies

• Spot dependencies between workstreams, systems and teams
• Distinguish blocking dependencies from deferrable ones
• Identify resources shared with competing projects
• Organise dependency tracking over time

Practical work: building a dependency map for a programme comprising four workstreams. Identification of the critical path.

4. Locating the project in its environment

• Position the project within the portfolio and its priorities
• Assess the absorption capacity of the teams involved
• Identify the applicable regulatory and continuity constraints
• Anticipate the effects on existing processes

Practical work: assessment of the absorption capacity of a business unit on which three projects converge.

5. Concluding and recommending

• Formulate a recommendation to proceed, postpone or abandon
• Document assumptions and success conditions
• Defend a postponement before an impatient sponsor
• Organise the periodic review of the recommendation

Practical work: drafting a recommendation note, then presenting it to a simulated steering committee.

Description

Planning is neither producing a Gantt chart nor filling a product backlog. This two-day course covers the planning knowledge areas and subsidiary plans, in both predictive and agile approaches, and works above all on choosing between them according to the project context.

Learning objectives

By the end of the course, participants will be able to:

• Build a complete project plan and its subsidiary plans
• Draw up a realistic schedule and identify its critical path
• Estimate effort and duration while making assumptions explicit
• Choose between predictive, agile or hybrid approaches according to context
• Plan resources, quality, risks and communication
• Keep the plan current without spending disproportionate time on it

Teaching methods and resources

Methodological input followed by application exercises on a case running through the course. Schedule-building workshops, estimation exercises, approach comparisons. Subsidiary plan templates and an approach selection grid. Validation quizzes by knowledge area.

Course programme

1. Framing before planning

• State the project scope and its exclusions
• Build the work breakdown structure
• Identify deliverables and their acceptance criteria
• Handle unarbitrated scope requests

Practical work: building a work breakdown structure for a banking project, then cross-review.

2. Building the schedule

• Sequence activities and identify dependency links
• Estimate durations and make the assumptions explicit
• Determine the critical path and available float
• Handle imposed date constraints

Practical work: drawing up a schedule with critical path identification, then analysis of the effect of a delay on a given task.

3. Estimating effort and cost

• Compare estimation techniques and their fields of validity
• Estimate collectively to reduce individual bias
• Build a reasoned contingency reserve
• Revise an estimate during the project

Practical work: collective estimation of a work package using two different techniques, then comparison of the variances.

4. Drawing up the subsidiary plans

• Plan resources and handle assignment conflicts
• Define a quality arrangement proportionate to what is at stake
• Build the risk register and the associated responses
• Organise project communication

Practical work: drafting two subsidiary plans of the participant’s choice on the running case, followed by presentation.

5. Choosing and combining approaches

• Identify the characteristics that point towards predictive or agile
• Build a coherent hybrid approach
• Plan on a rolling horizon without losing the overall view
• Keep the plan current in a sustainable way

Practical work: reasoned selection of an approach for three projects with contrasting profiles. Collective discussion of the criteria used.

Description

A project team brings together people who did not choose one another, for a limited period, with no line authority held by the person leading them. This two-day course addresses that particular situation: how to assemble the team, support its move towards maturity, and resolve deadlocks without being able to fall back on hierarchical authority.

Learning objectives

By the end of the course, participants will be able to:

• Assemble a project team around the skills genuinely required
• Support the team through its successive maturity phases
• Allocate roles and clarify what is expected of each member
• Resolve deadlocks without escalating to the hierarchy
• Conduct difficult conversations within the team
• Sustain engagement over the length of a long project

Teaching methods and resources

Input illustrated by real team situations. Simulations, role plays on difficult conversations, role allocation workshops. Team maturity diagnostic grid and skills matrix. Peer exchange between participants.

Course programme

1. Assembling the team

• Identify the skills genuinely required, beyond the usual profiles
• Negotiate resource assignment with business departments
• Handle partial assignments and their effects
• Organise the arrival and induction of new members

Practical work: building a skills matrix for a given project, then a simulated assignment negotiation with a business department.

2. Supporting the move to maturity

• Locate the successive phases of team formation
• Recognise the storming phase and go through it rather than avoid it
• Set the working rules collectively
• Adapt the leadership style to the maturity reached

Practical work: diagnosis of a team’s maturity phase from described situations. Selection of the appropriate leadership style.

3. Clarifying roles and expectations

• Allocate responsibilities without overlap or gaps
• Express expectations in verifiable terms
• Handle gaps between the role assigned and the role actually held
• Organise delegation within the team

Practical work: drawing up a responsibility matrix for a work package, then identifying the ambiguous areas.

4. Resolving deadlocks

• Distinguish technical disagreement, relational tension and skills gap
• Conduct a corrective conversation without line authority
• Handle a member who withdraws or opposes
• Escalate at the right moment and in the right way

Practical work: role plays on three deadlock situations, with a collective debrief on how the conversation was conducted.

5. Sustaining engagement over time

• Maintain motivation on a long or repetitive project
• Recognise contribution without a remuneration lever
• Handle team fatigue and periods of overload
• Organise project closure and the exit of members

Practical work: building an action plan for a team losing engagement, described in a case. Presentation and discussion.

Description

Generative AI tools are already used in agile teams, often without a shared framework. Used well, they speed up customer discovery, experimentation, backlog refinement and test design. Poorly governed, they expose sensitive data and produce fragile deliverables.

This two-day course follows the agile cycle in five stages: Discovery, Experimentation, Delivery, Reflection and Scaling. For each stage, the course uses banking cases to show what AI can contribute, what must stay with humans, and how to govern its use.

How much to hand over: a decision grid

The practical question is not “should we use AI?” but “to what degree?”. The course relies on a two-axis grid: the impact of an error and how hard the output is to check.

• Automate when an error costs little and shows up quickly: meeting minutes, rewording.
• Assist when an error costs little but is hard to spot: the team reviews.
• Assist with expert review when an error is costly but checkable: a specialist signs off.
• Let humans decide when an error is costly and hard to check: AI serves as reference support only.

Learning objectives

By the end of the course, participants will be able to:

• Explain how AI supports customer discovery, experimentation and continuous delivery in an agile cycle
• Apply AI tools to real agile situations in banking
• Use AI outputs to prioritise and make team decisions, without handing it the trade-offs
• Determine the right level of delegation for each task using an impact / verifiability grid
• Assess ethical and organisational issues: bias, hallucinations, transparency, privacy and team engagement
• Define an AI usage charter and a roll-out plan for their team

Teaching methods and resources

Hands-on workshops with generative AI tools, using anonymised backlogs and sprint data. Tool demonstrations by the trainer. Systematic comparison between AI-assisted output and human analysis. Materials provided: a table of uses by cycle stage, the delegation grid, a risk / control matrix, a reusable prompt library and a usage charter template. Experience sharing between participants.

Course programme

1. Discovery: understanding needs with AI

• Understand how a language model works, what it can do and where it fails
• Synthesise interviews and cluster customer verbatims
• Distinguish assistance, automation and autonomous agents
• Confirm with the business that the needs identified are real

Practical work: AI-assisted analysis of pain points raised by advisers on a loan journey, then comparison with the team’s own analysis.

2. Experimentation: framing and testing hypotheses

• Formulate hypotheses and measurable success criteria
• Produce mock-ups and test variants
• Split epics into deliverable items
• Keep the choice of which experiments to fund with the team

Practical work: design of two versions of a sign-up screen and of the test protocol with a panel.

3. Delivery: refining the backlog and producing tests

• Write and rework user stories and their acceptance criteria
• Detect duplicates, ambiguities and dependencies
• Generate test cases and check their coverage
• Keep backlog trade-offs and acceptance of deliverables with the product owner

Practical work: test cases generated for a change to regulatory reporting, then coverage check and identification of missing or incorrect cases.

4. Reflection: steering and continuous improvement

• Analyse velocity and spot signs of drift
• Summarise daily stand-ups and prepare the sprint review
• Prepare and run a retrospective with AI support
• Decide improvement actions as a team

Practical work: AI-assisted reading of velocity drift on a DORA workstream, then comparison with the team’s analysis.

5. Scaling: governing and rolling out

• Place each use on the delegation grid
• Frame the five risks: bias, hallucinations, transparency, privacy, team engagement
• Build a prompt library approved by compliance
• Write the team’s AI usage charter and measure real gains

Practical work: drafting an agile team’s AI usage charter and a roll-out plan over three sprints.

Five risks to frame before equipping a team

• Bias: test outputs on varied cases; never let AI alone triage customer requests or profiles.
• Hallucinations: require a source for every figure or regulatory reference; human review before anything is shared.
• Transparency: flag in the backlog and deliverables what was produced or assisted by AI.
• Privacy: only tools approved by IT and compliance; no client data or banking secrecy in unapproved tools.
• Team engagement: agree usage together in retrospectives; AI equips the team, it does not replace it.

Two deserve particular attention. Hallucinations: a model can produce a regulatory reference that looks right but is wrong, so every such reference needs a source and a human check. Privacy: client data and banking secrecy should only pass through tools approved by IT and compliance.

Description

A bank holds a great deal of information about its clients: accounts, loans, meetings, complaints. It is often scattered across several tools and in advisers’ memories. Customer relationship management (CRM) means organising it to know each client better, anticipate their needs and keep a traceable record of commercial actions.

This two-day course takes an operational view of CRM. Every concept is applied in a real CRM: HubSpot CRM, chosen because it is quick to learn and its core features are available without a paid licence. Participants work on a training portal loaded with fictitious data. The practices taught carry over to the CRMs used in banking, including Salesforce and Microsoft Dynamics 365.

A common thread: the business banking branch of a regional bank

Throughout the two days, participants take over the portfolio of a fictitious business banking branch: 60 clients and prospects, a growth target on equipment loans and transaction flows, and open complaints. Step by step, they build the branch’s CRM set-up, from the client database to the dashboard presented to the regional director.

Learning objectives

By the end of the course, participants will be able to:

• Explain what is at stake in banking client relationships: life cycle, client value, attrition, advice and record-keeping duties
• Structure a client database in a CRM: contacts, companies, properties, segmentation and data quality
• Build and manage a sales pipeline with stages, probabilities and forecasts
• Organise client follow-up: activities, tasks, reminders and complaint handling
• Define client relationship KPIs and track them in a dashboard
• Frame CRM use in line with the GDPR and banking secrecy

Teaching methods and resources

Short presentations alternate with hands-on work in HubSpot CRM, on a training portal prepared by the trainer and loaded with fictitious data. Each module ends with an exercise on the common thread. Materials provided: step-by-step guide, client data dictionary template, segmentation grid, banking pipeline template and KPI sheet. Participants share their experience.

Course programme

1. Client relationship fundamentals in banking

• Position CRM: client life cycle, key moments, omnichannel journey
• Measure client value, product holding, satisfaction and attrition
• Link commercial relationships, the duty to advise and record-keeping
• Get to know the HubSpot CRM interface: objects, records, views and navigation

Practical work: mapping a business client’s journey, from onboarding to the renewal of its credit lines, and identifying the touchpoints to record in the CRM.

2. Structuring the client database

• Design the data model: contacts, companies and associations
• Create custom properties: segment, adviser, turnover, product holding
• Import data, handle duplicates and set data quality rules
• Segment the portfolio with lists and filtered views

Practical work: importing the branch portfolio into HubSpot, removing duplicates and building three priority segments.

3. Managing business development

• Configure a deal pipeline suited to a bank lending cycle
• Define stages, exit criteria and win probabilities
• Prepare an account plan for a strategic client
• Read forecasts and set the team’s priorities

Practical work: creating the branch’s equipment loan pipeline, entering ten opportunities and running a pipeline review in pairs.

4. Following up and retaining clients

• Log meetings, calls and emails in the client history
• Plan team tasks and reminders and track their completion
• Handle complaints with tickets, in line with ACPR Recommendation 2024-R-02
• Spot attrition signals and trigger retention actions

Practical work: handling a client complaint from receipt to closure, then drawing up a follow-up plan for clients at risk of leaving.

5. Measuring, improving and governing use

• Choose KPIs: conversion rate, handling time, product holding, attrition
• Build a dashboard and use it in a regular management routine
• Govern personal data: purposes, retention periods, data subject rights
• Prepare team adoption of the CRM: data entry rules, roles and support

Practical work: building the branch dashboard and presenting results to the regional director, followed by a group debrief.

Why HubSpot CRM for the practical work

The features used during the course (contacts, companies, properties, lists, deals, tasks, tickets and dashboards) are part of the free CRM, so each participant can repeat the exercises after the session. The course does not depend on the vendor: time is set aside to transfer the practices to the CRM already in place at the participant’s institution. Helios Advisory is neither a partner nor a reseller of HubSpot.

Description

A new offering rarely fails because of poor execution. It usually fails because it meets a need that clients do not have, or not in the form imagined. Lean Startup, the method formalised by Eric Ries from lean thinking and Steve Blank’s customer development, tests these assumptions early and at low cost, before the resources of a full project are committed.

This two-day course applies the method to a financial institution, where innovation has to work within compliance, security and data protection requirements. Participants learn to state their assumptions, design quick tests with real clients and decide on evidence: carry on, pivot or stop.

A common thread: a mobile cash management offering for micro-businesses

Throughout the two days, participants support the team of a fictitious retail bank that is considering a cash management app for very small businesses. They build the offering’s Lean Canvas, prepare client interviews, design a minimum viable product and present their results to a simulated investment committee.

Learning objectives

By the end of the course, participants will be able to:

• Explain the principles of Lean Startup and where it sits alongside predictive project management and agile methods
• State an offering’s value and growth hypotheses and identify the riskiest ones
• Run customer discovery interviews without leading the answers
• Design a minimum viable product and its test protocol, with success criteria set in advance
• Choose metrics that support decisions and decide whether to pivot or persevere
• Build compliance, security and data protection requirements into experiments

Teaching methods and resources

Short presentations alternate with small-group workshops on the common thread or on a participant’s own project: canvases, client interview role plays, test design and a review before a simulated committee. Materials provided: Lean Canvas and Value Proposition Canvas templates, client interview guide, MVP design sheet, learning dashboard template and pivot-or-persevere decision grid.

Course programme

1. The principles of Lean Startup

• Understand why new offerings fail: market risk before execution risk
• Place the method: lean heritage, customer development, validated learning
• Work through the build, measure, learn loop
• Position Lean Startup against predictive project management, Scrum and design thinking

Practical work: diagnosis of the common-thread project, then listing what the team believes it knows without having checked it.

2. Stating and ranking hypotheses

• Describe the offering with the Lean Canvas: problem, segment, value proposition, channels, revenue
• Refine the fit between needs and offering with the Value Proposition Canvas
• Tell value hypotheses apart from growth hypotheses
• Rank hypotheses by importance and level of uncertainty

Practical work: Lean Canvas of the mobile cash management offering and choice of the three hypotheses to test first.

3. Getting out of the building: customer discovery

• Prepare an interview guide focused on the problem, not the solution
• Ask about past behaviour rather than intentions
• Avoid confirmation bias and polite answers
• Summarise interviews and update the hypotheses

Practical work: interview role plays with micro-business owners, followed by a group summary of the lessons learned.

4. Designing and testing the minimum viable product

• Choose the right type of MVP: landing page, clickable prototype, concierge MVP, Wizard of Oz
• Set a quantified success criterion before launching the test
• Run the experiment within a controlled framework: compliance and legal sign-off, GDPR, information for test clients
• Keep the cost and duration of the test low to learn fast

Practical work: designing two MVPs for the common thread and writing their test protocols.

5. Measuring, deciding and scaling up

• Tell actionable metrics apart from vanity metrics
• Read a cohort analysis and the acquisition, activation, retention, revenue, referral funnel
• Decide whether to pivot or persevere, and recognise the main types of pivot
• Fund innovation in stages and link the approach with agile delivery and portfolio management

Practical work: learning dashboard for the common thread and a pivot-or-persevere review before a simulated investment committee.

Lean Startup and Lean Six Sigma: two uses of lean

Lean Six Sigma improves existing processes by reducing waste and variability. Lean Startup applies when the offering, the client or the business model is still uncertain. The two approaches complement each other: the first makes what already works more reliable, the second avoids investing in what has not yet proved itself.

Description

A project can meet its scope, budget and deadlines and still fail: the solution is delivered, but users do not adopt it, work around the new processes or go back to old habits. The expected benefits then never materialise.

This two-day course gives project managers the essential tools to build change management into their work: analysing impacts, engaging stakeholders, anticipating resistance, communicating and training at the right time, then measuring adoption. It draws on recognised models, including Kotter, Lewin and the ADKAR model.

A common thread: rolling out a new tool across a branch network

Participants support the fictitious rollout of a new loan processing tool across the fifty branches of a regional bank. Advisers are attached to the old tool, branch managers fear a drop in sales and the timetable is tight. Module by module, participants build the change management plan and integrate it into the project schedule.

Learning objectives

By the end of the course, participants will be able to:

• Explain why projects fail for lack of adoption and what change management involves
• Use the main change management models and choose the one that fits the context
• Analyse the project’s impacts on business lines, processes and people
• Map and engage stakeholders, starting with the sponsor
• Build a communication and training plan integrated into the project schedule
• Understand and address resistance, then measure adoption and embed new practices

Teaching methods and resources

Short presentations, a case study running over the two days, small-group workshops and role plays on resistance situations. Participants can apply the tools to their own project. Materials provided: impact analysis grid, stakeholder matrix, communication and training plan template, deployment readiness checklist and adoption tracking table.

Course programme

1. Understanding change

• Tell project management apart from change management, and link the two
• Understand individual reactions to change: the change curve
• Discover the reference models: Lewin, Kotter, ADKAR
• Place change management within predictive, agile and hybrid approaches

Practical work: diagnosis of the common-thread project and identification of adoption risks.

2. Analysing impacts and stakeholders

• Assess impacts on processes, tools, roles and skills
• Identify affected groups and their level of impact
• Map stakeholders by influence and stance
• Define the role of the sponsor and change champions

Practical work: impact grid by group and stakeholder matrix for the rollout.

3. Communicating and training

• Build a communication plan: messages, channels, timing, senders
• Tailor messages to different audiences
• Design a training plan timed close to go-live
• Organise the network of champions and super-users

Practical work: communication and training plan integrated into the project schedule.

4. Addressing resistance

• Recognise forms of resistance and their causes
• Listen to and answer objections
• Involve users to turn opponents into contributors
• Escalate and resolve difficulties with the sponsor

Practical work: role plays with a branch manager opposed to the project and a worried adviser.

5. Deploying, measuring and embedding

• Prepare go-live: readiness criteria, on-the-ground support
• Measure adoption: usage, proficiency, satisfaction, results
• Take corrective action after deployment
• Embed new practices and capture lessons learned

Practical work: adoption tracking table and three-month embedding plan, presented to a simulated steering committee.

For project managers, not specialists

This course gives the essential tools to those who lead a project and must secure its adoption, without being change management specialists. It complements the “Planning Predictive and Agile Projects” and “Building and Developing a Project Team” courses. ADKAR is a trademark of Prosci; Helios Advisory is neither a partner of nor affiliated with Prosci.

Description

A project has a start, an end and a deliverable; a product lives as long as it creates value for its users. Many organisations, including banks, are changing their model: moving from a series of projects funded one by one to long-lived product teams managed by value. This shift changes roles, funding, planning and performance measurement.

This two-day course compares the two disciplines and shows how to combine them: product life cycle, discovering needs, vision and roadmap, backlog management, value metrics, and the place of projects in a product-oriented organisation. It helps project managers and product managers clarify their responsibilities and work better together.

A common thread: a bank’s mobile app

Participants follow a fictitious bank that managed its mobile app through successive projects: redesign, adding payments, new authentication. Releases pile up, priorities change at every committee and users complain. Participants design the move to product management and define the place of the projects that remain necessary, such as a regulatory migration.

Learning objectives

By the end of the course, participants will be able to:

• Distinguish project and product: purpose, life cycle, funding, success criteria
• Clarify the roles of project manager, product manager and product owner
• Set a product vision and build an outcome-oriented roadmap
• Discover and prioritise user needs, then manage a backlog
• Manage a product by value with suitable metrics
• Combine projects, products and portfolio in an organisation in transition

Teaching methods and resources

Short presentations, a case study running over the two days, small-group workshops and comparison of participants’ own experiences. Materials provided: project versus product comparison table, roles and responsibilities matrix, product vision template, outcome-oriented roadmap template, prioritisation grid and examples of product metrics.

Course programme

1. Project and product: two different logics

• Compare purpose, horizon, deliverables and success criteria
• Understand a product’s life cycle, from launch to retirement
• Compare project funding with funding long-lived teams
• Identify situations where each logic fits best

Practical work: diagnosis of how the common-thread mobile app is currently managed.

2. Roles and responsibilities

• Define the responsibilities of the project manager, product manager and product owner
• Place the sponsor, the project office and the development teams
• Avoid overlaps and grey areas
• Organise day-to-day cooperation

Practical work: roles and responsibilities matrix for the app’s new organisation.

3. Vision, discovery and roadmap

• Set a product vision and measurable objectives
• Discover needs: interviews, usage data, tests
• Build a roadmap oriented to outcomes rather than features
• Prioritise by value, effort and risk

Practical work: product vision and twelve-month roadmap for the mobile app.

4. Managing a product by value

• Manage and refine the backlog with stakeholders
• Choose product metrics: usage, satisfaction, retention, value created
• Decide on the basis of data rather than requests
• Report to committees without reverting to a deliverables logic

Practical work: product dashboard and trade-off between competing requests.

5. Combining projects, products and portfolio

• Identify the projects that remain necessary: regulatory, migration, infrastructure
• Coordinate projects and product teams on the same scope
• Adapt portfolio governance and funding
• Lead the transition to a product-oriented model

Practical work: the bank’s transition plan and presentation to a simulated management committee.

Two complementary disciplines

The course does not present product management as a replacement for project management: the two coexist in most organisations. It complements “SCRUM Fundamentals”, “Planning Predictive and Agile Projects” and “Lean Startup: Innovating While Reducing Risk”.

Description

Project managers regularly face situations where the right decision is not obvious: pressure to report better progress than reality, a gift from a supplier, a conflict of interest, confidential information, a trade-off between team members. In those moments, clear values prevent decisions that weaken the trust, reputation and sometimes the compliance of the organisation.

This one-day course is based on the four values set out in the Project Management Institute’s Code of Ethics and Professional Conduct: responsibility, respect, fairness and honesty. It turns them into concrete behaviours and a decision method, using dilemmas drawn from project life.

A common thread: the dilemmas of a banking project

Participants follow the fictitious manager of a compliance programme in a bank. Within a few weeks, he has to deal with a committee expecting a “green” status, an invitation from a supplier bidding in a tender, a mistake by his team discovered late, and a request for access to customer data outside the authorised scope.

Learning objectives

By the end of the course, participants will be able to:

• Explain the four core values and their role in running projects
• Tell mandatory standards apart from aspirational behaviours
• Recognise risk situations: conflicts of interest, pressure, sensitive information
• Apply a structured method to analyse a dilemma and decide
• Communicate transparently, including bad news
• Promote a culture of trust and responsibility in the project team

Teaching methods and resources

Short presentations, small-group analysis of dilemmas, role plays and structured debates. Each case is tested against the four values, then debriefed as a group. Materials provided: summary of the four values and associated behaviours, ethical decision grid, case collection and a list of questions to ask before deciding.

Course programme

1. Why values matter in project management

• Understand the impact of behaviour on trust and project success
• Discover the PMI Code of Ethics and Professional Conduct
• Tell mandatory standards apart from aspirational ones
• Link values, internal rules and compliance obligations

Practical work: listing the difficult situations participants have experienced.

2. Responsibility

• Own your decisions, commitments and their consequences
• Acknowledge and correct your mistakes
• Protect confidential information
• Report behaviour that breaks the rules

Practical work: the case of the mistake discovered late in the common thread.

3. Respect

• Listen to and take account of other viewpoints
• Negotiate in good faith and manage conflict
• Respect others’ property, rights and culture
• Maintain a working climate free of abuse of power

Practical work: role play of a conflict between two team members.

4. Fairness

• Make impartial, objective decisions
• Identify and disclose conflicts of interest
• Ensure equal access to information in tenders
• Avoid favouritism and discrimination

Practical work: the case of the invitation from the supplier bidding in the tender.

5. Honesty

• Seek and tell the truth in communications
• Report progress accurately, even when unfavourable
• Avoid creating false impressions by omission
• Keep your commitments

Practical work: preparing an honest status report for a committee expecting a “green” status, followed by a debrief.

Also useful for certification candidates

The values studied are those of the PMI Code of Ethics and Professional Conduct, which PMP and CAPM credential holders commit to follow. The course is independent of PMI: it does not prepare for or award any exam.

Description

Big data projects rarely fail for lack of technology. They fail because the use case is vague, data quality has been overestimated, roles between business, data and IT teams are poorly defined, or the prototype never reaches production. Managing them requires project management skills adapted to these specific features.

This three-day course gives project managers the landmarks they need to manage a big data project: understanding architectures and vocabulary, scoping value, organising the team, choosing a delivery approach, controlling governance, security, compliance and costs, then industrialising and measuring results.

A common thread: a data platform for fraud detection

Participants manage a fictitious data platform project in a bank: bringing together transaction, digital channel and customer data to improve fraud detection and customer knowledge. They scope the project, build the team, plan deliveries, deal with compliance issues and prepare the move to production.

Learning objectives

By the end of the course, participants will be able to:

• Explain the characteristics of big data and the main architectures: data lake, data warehouse, cloud platforms
• Scope a project from use cases and measurable benefits
• Organise the team and roles: data owners, data engineers and scientists, architects
• Choose a suitable iterative, value-driven delivery approach
• Control data governance, quality, security, compliance and costs
• Prepare industrialisation and measure the value created

Teaching methods and resources

Short presentations, a case study running over the three days, small-group workshops and experience sharing. No coding is involved: participants work on the project manager’s decisions. Materials provided: big data glossary, use case scoping canvas, roles matrix, roadmap template, risk analysis grid and go-live checklist.

Course programme

1. Understanding the big data landscape

• Characterise big data: volume, velocity, variety, veracity, value
• Understand architectures: data lake, data warehouse, unified platform, cloud
• Place distributed processing and storage tools
• Tell descriptive analytics, predictive analytics and machine learning apart

Practical work: mapping the data sources and target architecture of the common thread.

2. Scoping the project and its value

• Start from business use cases and prioritise them
• Assess data availability and quality before committing
• Define expected benefits and success metrics
• Build the business case and the initial scope

Practical work: scoping the fraud and customer knowledge use cases, and choosing the first scope.

3. Organising the team and the approach

• Define roles: sponsor, data owners, engineers, scientists, architects, security
• Link business, data and IT teams
• Choose an iterative approach: proof of concept, minimum viable product, successive releases
• Plan and track a project with high uncertainty

Practical work: roles matrix and a roadmap in three increments.

4. Governance, compliance, security and costs

• Organise data governance and quality
• Comply with the GDPR and, for banks, the principles for risk data aggregation
• Frame artificial intelligence uses and their regulatory requirements
• Secure data and control infrastructure costs

Practical work: risk analysis of the project and treatment plan with compliance and security.

5. Industrialising and measuring value

• Move from prototype to production: operations, monitoring, maintenance
• Put data and model industrialisation practices in place
• Support business adoption
• Measure value and decide on next steps

Practical work: go-live checklist and presentation of results to a simulated steering committee.

A course for managing, not coding

The course is for project managers and managers who oversee data projects without being technical specialists. Participants who want hands-on skills can take the courses in the Data Governance and Analytics area, from SQL to Data Factory.