SY-EPC-LPC Generalities Concepts

CERN Map / Buildings

|

CERN Phonebook

|

| CERN | SY | SY-EPC | EDMS | PROJECTS | ODF / OOXML |

| SOFT | HOME Logo home

Introduction

Lessons Learned

Introduction

Any project is an opportunity to collect successes and failures. From them, it is recommended to draw and extract some lessons, the approach on how to collect them being described here.

Lessons Learned

ID	Description	Example
1	Pay attention to the quality of your requests, especially to other sections. Your initial request should create a positive link with people you need assistance from. Use as much as possible pre-defined and agreed forms. Write your requests in a way they can easily be understood, retrieved, well defined, even allowing the control of the task status by both sides.	Too quickly written emails, too long documents being used as a reference to avoid creating a specific request won't help, not showing sufficient respect to the people being asked for help. A high quality request, written on purpose or using agreed pre-defined form, will push people to naturally help you, creating positive environment.
2	Pay attention to put/request the right peole on the right place/tasks and take advantage from it. Discuss with them first; experienced people in charge of a task do not require highly detailed plan, but more a precise objective, and quick answer when the case. They will often accommodate on field their actions towards the optimum solution.	It is counterproductive to specify a task in too much details, especially in a domain not well known, to an experienced people. Expert knows his work and how to adapt it for the best result. It is often better to assist the expert during the task execution, answering raised questions, than trying to pilot him.
3	Always proceed with a design phase before building, sometimes simply using a basic and quick test to ensure the result can fit. When facing the situation of an unknown domain to be coped with in a already challenging planning, estimate if requesting the help of an expert is a possible optimum solution, or evaluate rough basic tests you can manage and understand.	Some domains (safety issues, thermal ...) are not in already acquired skills. Instead of simply ignoring the issue related to, specify a time window, and think about some very simple tests or actions which can ensure the direction is good. (A basic thermal test simulating losses with a basic resistor in a similar rack installing fans can be sufficient for a first approach).
4	Always consider innovative solution in the full life of the project / unit, and evaluate its real cost. If getting smart ideas is often a way to solve difficult problem, always pay attention to the implementation (design complexity, operation), and revalidate the gain obtained, judging if the overall is positive balance or not.	High level of complexity is and will stay difficult to manage, at any stage (design, operation, update etc...). Complex solution must provide a very strong positive advantage to be evaluated and debated. Always consider that getting new ideas can often help with a final upgrade of an existing & working system, instead of creating a brand new one.
5	Pay attention that designing new systems keeping old ones, or re-using part of old ones is not always saving both time and money.	Trivial statements often do not resist with deep analyse. Keeping old systems, parts (not buying new ones) will give constraints which can easily overcome the benefits.
6	Pay attention to any date used in planning, so that each task being announced at a given time is the result of a real estimation, analyse, with all relevant people being consulted when possible. Make sure any announced date was discussed and agreed with relevant actors.	Too many plans are over optimistic, simply because dates are placed in a logical way, and not as a result of a correct evaluation, taking into account the task difficulty, people working on it, and the context. This ends creating high level of stress for people for inefficient work.
7	If planning the project is done through a milestone plan method, adopt regular short briefings during the whole project, evaluating the project status and reviewing the milestones (last ones, next ones, focusing on close ones). Every actor will get a refresh of where and how he is assumed to intervene on the project, starting the actual work on milestone in time and being kept active on the project, in a positive environment.	It is unrealistic and naive to think that once a milestone plan is given and accepted, every actors will deduce the optimum starting date, pointing it in his calendar, and starting it in time. Other urgent requests will come in between and will jeopardize the important even if agreed expected actions inside the project.
8	Plan your work through identified steps or states, jumping from one to the other without inserting dead and waiting period in between them. Define and use the concept of proto-preserie-serie, identifying in which state you really are, and organising the tasks.	Any work almost completed, but waiting an undefined period to see if everything is fine is a result of a wrong planning. It will result in many un-finished states, losing dynamic progression. It will also make foggy the real situation of the project.
9	A well planned (in advance) commissioning plan, with all documents, webpage and even edms nodes already created and simply to be filled allow to treat emerging and unexpected issues, not losing efficiency nor the established planning. It is also a key point for ensuring safety.	Commissioning involves many different teams and many units, with each individual project/part being involved in the full plan sometimes only from that step. Per nature, probabibility of some unexpected issues is high; still, they should not make the whole plan to collapse.
10	Communication is a key point, which, if ignored will eventually impacts the technical work, in consequence.	A lack of reporting can lead to a misunderstanding on the project state from project supporters, impacting, finally the global plan since trying to correct and reduce their frustration.
11	Clearly define the role of EPC in the installation process, as soon as possible, defining the interfaces between EPC and EN-EL / EN-CV.	It can happen everyone is waiting for information from the others resulting in blocked situations.

Lessons learned