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.

Can you tell us a bit about yourself and your career so far?

After graduating in microtechnology engineering from the Ecole Polytechnique Fédérale de Lausanne, I gained a number of professional experiences as a research engineer and product engineer in Switzerland and Australia. On my return from Australia, I moved into consulting, which gave me the opportunity to take part in the Solar Impulse project, sponsored by my employer. I started out as project manager, and was then put in charge of the logistics of the flight missions. On the strength of all this experience, I founded the Prefix company in 2014.

What is your role at Prefix?

I’m the director of Prefix, where I also play a dual role as senior consultant and FSEA-certified trainer. My areas of expertise cover project management and governance, with a particular affinity for collaborative methods.

What skills and experience do you bring to Prefix customers?

I have accumulated a wealth of experience in coordination and management roles, often on secondment to clients. This experience spans a wide range of sectors, including industry, academia, administration and the voluntary sector. Not forgetting my involvement in the Solar Impulse adventure. Since setting up Prefix, I’ve also broadened my skills in governance and agile methods. Finally, I’m fluent in French, English and Swiss German.

What are your emotional intelligence assets, which are crucial to being an effective consultant or coach?

I’m at ease with communication and human interaction, and have an instinct for spotting inconsistencies in systems, particularly within organisations and methods. What’s more, I’m able to adapt quickly to different personalities and situations.

Can you give an example of a project or achievement of which you are particularly proud?

I’m particularly proud of the fact that I’ve been able to find a solution for marrying the initial approaches to project management, known as predictive or waterfall, with the more recent methods known as agile. This marriage gave birth to the method I have named Circular Project Management, which is now at the heart of Prefix.

What other question would you like to answer?

How do you see the future of Prefix?

I see the future of Prefix with a varied and complementary team of consultants, who are involved as co-owners and co-managers. Together, we form an international organisation, focused on collaboration and exchange, always one step ahead of an ever-changing world.