Planning poker is a fun, collaborative tool using a card game where each member of a team evaluates a task or decision by choosing a card corresponding to a specific value. The cards are revealed simultaneously, then discussed until a consensus is reached. This avoids influence bias and encourages collective participation in decision-making and the management of various priorities.

Planning poker is often used by agile project teams, but it can also be used to address other important issues within an organisation.

How can planning poker be used?

1. Prioritising tasks and projects
   Planning poker enables tasks or projects to be ranked according to their impact, urgency or complexity, by fostering a collective consensus. This helps to better manage priorities by taking into account different points of view.
2. Risk assessment
   The tool can be used to estimate the probability and impact of risks in a project, making it easier to take informed decisions on preventive action.
3. Allocation of resources
   Thanks to collaborative estimation, planning poker helps to better allocate resources according to the needs and capacities of the team, thereby optimising efficiency.
4. Strategic decision-making
   Planning poker can be used to evaluate strategic options by weighing up different factors (costs, benefits, feasibility). This makes decision-making more transparent and collective.
5. Continuous process improvement
   By assessing the performance of internal processes, planning poker makes it easier to identify areas for improvement, taking into account the opinions of all employees.
6. Estimating tasks in an agile project
   The main use of planning poker is to estimate the tasks in a project managed by an agile team. Each team member gives a numerical estimate (based on complexity points or units of time) to assess the effort required to complete a task. This collective estimate enables different points of view to be taken into account and uncertainty to be reduced by reaching a consensus, which is crucial for effective sprint planning and priority management.

The benefits of planning poker for an organisation

Using planning poker encourages collective participation, reduces decision-making bias and improves communication between teams. Its adaptable approach makes it useful in many contexts: prioritisation, risk management, strategic decisions, etc. By integrating this tool into your processes, you can optimise team commitment and improve the overall management of your organisation.

Small and medium-sized enterprises (SMEs) play a crucial role in the economy, but many of them face recurring challenges in terms of governance and strategic decision-making. Often, in the absence of resources or formal structures such as a board of directors or advisory committee, these businesses are forced to rely on the shoulders of their managers for all important strategic decisions.

A consultative and collaborative approach

It is in this context that Cross Boards are emerging as an innovative and collaborative solution. The idea is simple but powerful: to bring SME managers together in mutual advisory boards, where they can share experiences, critical perspectives and offer advice to each other.

Cross Boards are not just about filling an organisational void, but about transforming the way small businesses approach governance. This consultative approach encourages voluntary exchange between peers, allowing participants to benefit from constructive feedback and diverse expertise without the constraints associated with setting up a traditional board structure.

Adaptability

What particularly sets Cross Boards apart is their adaptability. They offer the possibility of modifying the composition of boards in line with the company’s changing challenges and objectives. This flexibility is essential if organisations are to remain reactive in the face of a changing environment, or when they are in a phase of evolution or transformation.

In incubation

At the time of writing, the Cross Boards solution is in the Prefix Incubator. The aim of this initial phase is to refine the concept, evaluate its effectiveness and adjust the processes based on feedback from participants. Ultimately, the aim is to extend this initiative to a wide range of entrepreneurs, define clear rules for participation and create a self-sustaining solution for SMEs.

If you are a business manager interested in the idea of benefiting from Cross Boards or contributing to its development, we invite you to get actively involved. Your participation could not only enrich your own expertise but also shape the future of SME governance.

To find out more, you can follow the solution in the Incubator.

Project portfolio management is often neglected, if not totally absent, in many organisations. The most common justification given is lack of time or the complexity of such an approach, whereas in reality it is often a question of a lack of awareness of the importance of this aspect in running an organisation.

Why does an organisation carry out projects?

An organisation can be represented schematically by a pyramid structure divided into three distinct parts.

Strategy. The top of the pyramid symbolises the mission, the reason for being and the strategic objectives of the organisation. These terms define the general direction and the framework within which the organisation operates.

Processes. Processes are at the heart of the organisation’s activity. They represent its business, its know-how, as well as the tacit knowledge and collective expertise accumulated over time. Continuous and repetitive, they generate value for the organisation and its customers. This value can take many forms, including financial benefits, reputation, comfort, social responsibility and sustainability.

Projects. Projects are temporary initiatives designed to stabilise or increase the added value generated by organisational processes. Acting as drivers of change, projects play a crucial role in an organisation’s ability to adapt to its environment and, consequently, to maintain or even increase the value generated by its processes.

Why manage a project portfolio?

Organisations often have a good command of their business processes, given that they represent their source of revenue. Without such effective management of all its projects, the organisation risks encountering difficulties in achieving its strategic objectives, innovating, adapting to its competitive environment and responding to changing market needs. This lack of project portfolio management can compromise its competitiveness and long-term survival.

What’s more, the financial and human resources needed to carry out these projects are often limited, as they are already largely used up by existing processes. Consequently, effective project portfolio management enables the organisation to optimise the allocation of its resources, prioritise initiatives that feed the strategy and maximise returns on investment.

How do you manage a project portfolio?

Defining strategy. Strategy is responsible for setting the broad direction and priorities of the organisation. In a well-managed organisation, all processes and the project portfolio are adjusted to meet this strategy.

Measuring consistency. Before authorising a project within the portfolio, it is important to measure its consistency with the organisation’s strategy. If a project is in line with the objectives and vision, it will make sense within the portfolio. If it is deemed too inconsistent, it will have to be adapted, put on hold or abandoned.

Prioritising projects. Prioritising projects is essential to ensure optimal management of the project portfolio. It ensures that limited resources are allocated wisely and that projects contribute effectively to the organisation’s overall objectives.

Project planning. It is crucial to plan the implementation of projects according to the availability of resources and their priority. This involves drawing up a realistic timetable, taking into account time constraints, team capabilities, available budgets and dependencies between projects.

Appoint a PMO. The PMO (Project Management Officer) will be responsible for overseeing the organisation’s project portfolio. In addition to this supervision, the PMO can also play the role of ‘guardian of the project methodology’, ensuring that best project management practices are followed consistently, and offer coaching to project managers.

Among the many challenges faced by project managers, time and budget overruns stand out as one of the most frequently encountered problems. These overruns can compromise the success of a project and have a significant impact on your organisation and its stakeholders.

How can project managers overcome these obstacles to achieve the desired end result?

Many factors can contribute to time and budget overruns in a project, but most have their origins in poor initial definition and planning, ineffective risk management or clumsy contingency management.

Definition and initial planning

I systematically observe projects that have already started but for which there is no scoping memo, or where the scoping memo is incomplete or badly drafted. In other words, the scope of the project has not been clearly defined.

I also frequently notice a lack of detailed planning, i.e. a detailed schedule and budget, or poorly conceived and imprecise plans.

Without a clearly defined framework and initial detailed plans, it becomes extremely difficult to align with the COPIL or the customer on what constitutes an overrun. This is bound to lead to chaos and frustration for all the stakeholders involved.

The obvious solution is to invest the time needed to draw up these initial documents before even committing to the project. In any case, rough initial documentation is better than no documentation at all, but it is clear that the more detailed and accurate the documentation, the easier it will be to respond to unforeseen circumstances. It is up to project managers to adapt the complexity of this documentation to the complexity of the project, and not to overwhelm stakeholders with details that are not necessary for the nature of the project.

The quality of these documents depends on their structure and content, as well as the quality of the estimates. To achieve this, it is essential to work in collaboration and to build and estimate directly with the business experts. A project manager is a facilitator, an integrator, and can never have the same depth of expertise as each individual operational stakeholder.

As far as good practice in estimating is concerned, an article has been devoted to this subject.

Risks management

Unidentified or poorly managed risks can lead, among other consequences, to problems that delay the project and increase costs.

Just as some projects are not documented in a detailed schedule or budget, I see even more frequently projects where no thought has been given to risk management.

I strongly recommend systematically carrying out a risk analysis for all projects, whatever their complexity. For an uncomplicated or low-stakes project, a high-level risk analysis, such as a SWOT analysis, may suffice.

On the other hand, complex or high-stakes projects absolutely must be the subject of a detailed risk analysis. Inevitably, some of these risks, if not managed, will lead to delays or cost overruns.

Managing the unexpected

All project managers are aware that as soon as a project’s schedule and budget are established, they quickly become obsolete. The environment in which any project evolves is dynamic and changing, requiring constant management of unplanned events.

Establishing a detailed schedule and budget does not guarantee that the project will run smoothly. However, it does allow project managers and the COPIL to be much more effective in their decision-making, as these plans enable them to quickly understand the consequences of an unforeseen event on the scope of the project.

A minor contingency, i.e. an event that does not alter the scope of the project, will be managed at operational level and will require an adjustment to the detailed plans.

On the other hand, a major unforeseen event, which calls into question the scope of the project, will have to be dealt with at strategic level. This will involve adjusting the scope note, or even abandoning the project, and this falls under the authority of the COPIL.

What does the Triangle represent?

The Project Management Triangle, sometimes called the Magic Triangle, is a universally recognised concept. There are various interpretations of it, but they all reflect the major constraints that frame a project. Here, I will use a representation of the Triangle that illustrates four constraints common to all projects: Result, Time, Cost and the Human factor.

Result. The first parameter of the Project Management Triangle concerns the constraint of the expected end result, i.e. the objectives to be achieved and the deliverables to be produced as part of the project.

Time. One side of the Triangle represents the time constraint, in other words the time allowed to deliver the expected result of the project.

Cost. The second side of the triangle represents the financial constraint, in other words the costs associated with the project.

Human. The fourth constraint, the human factor, represents the availability and performance of the people needed to make the project a success. Too rarely identified in the Magic Triangle, it is nevertheless at the heart of any project approach.

Trivial definition or useful resource?

Unfortunately, many project managers perceive the Project Management Triangle as a trivial definition, devoid of any usefulness. Too often relegated to the status of an academic concept, the Magic Triangle is seen as a cliché with no relevance to the real world of dynamic projects. It’s obvious… Everyone knows that… Project managers see it as such a ubiquitous concept that it is of no use.. And yet, this careless perception obscures the true essence of the Magic Triangle, which goes far beyond a mere academic formula.

In fact, understanding the flexibility inherent in these constraints turns out to be a strategic asset for those who manage to master it, thus transforming the Project Management Triangle into an instrument that offers the possibility of anticipating and adjusting the methods used to control the project. It is by exploring beyond the surface that we discover the richness and usefulness of this simple representation.

Reality on the ground

Project managers take on a role in which the main responsibility is to successfully navigate through the unforeseen events that constantly challenge the path initially planned. Their task is to choose a route taking advantage of limited resources, all with the aim of achieving the desired end result. However, this roadmap is constantly being challenged, as the reality on the ground brings its share of unforeseen events every day.

These unforeseen events, whether they be delays, resource problems, changes of priority or any other unforeseen obstacle, continually test the robustness of the route initially chosen. Project managers must therefore be masters of adaptability, ready to constantly reassess and adjust the trajectory in the light of changing circumstances.

Postponing the Paris Olympics?

By understanding the flexibility of a project’s major constraints from the outset, managers can anticipate the potential changes to which they will need to be able to react and thus adapt quickly to unforeseen circumstances.

An inflexible constraint is one less lever for project managers. For example, if there are unforeseen circumstances in the preparations for the 2024 Olympic Games in Paris, it will be impossible to postpone the dates. This leaves only the option of committing more resources or delivering a worse result than originally expected.

Once they have understood how to use the Magic Triangle, project managers will adapt their tools and the route chosen to achieve the result, sometimes even modifying the scope of the project so as to reintroduce flexibility with regard to one or other of the constraints. The key is to create flexibility where there is too little, or to plan alternatives in advance.

In short, mastering the flexibility of constraints at the start of a project transforms the manager into an informed navigator, better prepared to deal with the unexpected and take advantage of sudden opportunities. It’s a strategic way of choosing the ideal path to ultimate success, where agility becomes a valuable asset in the project manager’s toolbox.

The challenge of each estimate is to identify the most realistic value possible, so that at the end of the project, the difference between the estimated value and the actual value is as small as possible.

To get as close as possible to this realistic value, I use the following approach:

1. I start by noting the value that comes to me intuitively, whatever it may be.
2. I use one or more of the following estimation methods:
   • By breakdown. Breaking down the element to be estimated into sub-elements, up to a level at which it becomes possible to make an estimate.
   • Expert judgement. Consultation with people experienced in the field related to the item being valued.
   • Estimation by analogy. Reference to similar projects or project elements whose value is known through experimentation, while adapting this value to the new context.
   • Parametric estimation. Estimate based on statistical data specific to the field of the element being estimated.
   • Mean value. Calculation of an average value, based on the most optimistic value and the most pessimistic value.
   • Poker planning. Collaborative and consensual estimation method, using a pack of cards bearing different values.
3. I add to the value obtained a reserve linked to the level of uncertainty in the estimate. This reserve can range from 10% to cover a minor contingency to 300% for highly uncertain situations. For very specific projects, some people use the pi-figure method to define the reserve to be included in their estimates.
4. I compare the intuitive value with the value established using one of the above methods. If they are consistent, I have sufficient confidence in the value established. If the values are inconsistent, I redo the intuitive estimate and use other methods.

One of the keys to successful projects is controlling deadlines. This requires good planning and coordination of the work needed to deliver the final results expected at the end of the project.

Here are the 5 steps I use to keep my project deadlines under control.

1. Determining the complexity of the project. An uncomplicated project is one where the strategic stakes are relatively low, the entire project lasts from a few weeks to a few months, the team consists of a few known people, the environment is known and the budget is a few thousand francs at most. A complex project is one in which one or more of its parameters is strong or high.
2. Determine the predictability of the project. A predictable project is one where you can easily determine the course, activities, costs, stakeholders and risks before the project starts. A poorly predictable project is one in which one or more of its parameters is difficult to estimate in advance.
3. Understanding the project environment. The choice of project management method and planning tools depends on the organisation’s environment. It depends, for example, on the tools already in use, established procedures, IT security rules or licence costs. The choice also depends on the habits and skills of the team.
4. Choosing the management method. Depending on the predictability and the environment, you can determine whether the most appropriate method is an agile method (e.g. SCRUM), a predictive method (e.g. Hermes, IPMA, PMBOK) or a versatile approach such as Circular Project Management, which allows both approaches.
5. Choosing the scheduling tool. For less complex projects, I make do with a list of tasks and a summary schedule, or even a few key milestones. For projects that follow an agile approach, I use a phase plan and Kanban boards. Finally, for complex projects that follow a predictive approach, I use a specialised planning tool (e.g. Merlin Project, Microsoft Project). There are a wide variety of IT tools available for planning projects: tools offering Kanban (e.g. Trello, WeKan, OpenProject), tools specialising in Gantt charts (e.g. GanttProject, ProjectLibre, Microsoft Project) or multi-functional tools (e.g. Jira, Asana). At Prefix, I use Merlin Project, a very comprehensive tool that can be used to display work in the form of both Kanban boards and Gantt charts.

The purpose of the specifications and the product backlog is to ensure that the final deliverable meets the needs of the customer or end user as closely as possible. It is therefore used to identify customer requirements and to structure the work to be done to achieve the final deliverable.

So it’s the same thing, but it’s very different!

What differences are there?

REQUIREMENTS SPECIFICATION

• Origin. The term “specifications” originated in the Middle Ages in the field of construction and engineering. Project owners (architects, engineers) wrote down their requirements, their “specifications”, on sheets of paper and passed them on to the craftsmen. All these sheets together formed a “notebook”.
• How it is used. It serves as a reference for defining the customer’s or client’s expectations of the deliverable. It is the responsibility of an expert or the person in charge of managing the project.
• Content. The requirements specification detail the constraints and functional requirements of the deliverable, as well as the associated performance criteria.
• Evolution. The requirements specification is a formal, static document, once it has been accepted during the planning phase. Any changes are subject to a formal validation process, which is not very flexible.

PRODUCT BACKLOG

• Origin. The expression “product backlog” is an Anglicism originating from agile methodology, in particular Scrum. The word “backlog” literally means accumulation, delay and represents a list of tasks or items awaiting processing.
• How is it used. It is used to organise and prioritise the work to be carried out on the deliverable. It is constantly updated to reflect the changing needs of the product. It is the responsibility of the “product manager”.
• Content. The product backlog is made up of “customer stories”, which represent the functionality of the deliverable expected by the customer, as well as elements representing improvements or corrections to be made to the deliverable.
• Evolution. It is potentially updated during each iteration, or sprint, of the agile process, depending on customer feedback and changes in priority.

In short, the specification is a static document that specifies the requirements of a deliverable, whereas the product backlog is a dynamic, evolving list representing the tasks to be carried out as part of an agile development process. In both cases, it is the document that frames the development of the deliverable, ensuring that its final form perfectly meets the customer’s needs.