Human Factors Engineering (HFE) at the early phoases of a project
•Transferir como PPTX, PDF•
1 gostou•379 visualizações
Presented at the EHF conference 2017. Encouraging the inclusion and consideration of human factors engineering as early as possible in a project
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Human Factors Engineering (HFE) at the early phoases of a project
Semelhante a Human Factors Engineering (HFE) at the early phoases of a project (20)
Mais de Andy Brazier
Mais de Andy Brazier (6)
Último
Último (20)
Human Factors Engineering (HFE) at the early phoases of a project
- 1. Tel: (+44) 01492 879813 Mob: (+44) 07984 284642 andy@abrisk.co.uk www.abrisk.co.uk 1 Human Factors Engineering (HFE) at the early phases of a project Andy Brazier
- 2. 2 Disclaimer The views and opinions expressed in this presentation are mine and do not necessarily reflect those of my employer.
- 3. Not a literature review Kletz explained the importance – 1980’s This has been accepted by industry We keep saying why, but not how. 3
- 4. My experience Process industry (oil and gas) design phase 15~ UK projects 20+ Middle East Projects Africa and Australia projects Range from relatively small modifications to full refinery/platform design Assisted clients developing in-house standards/procedures for HFE Many operate phase studies. 4
- 5. All stages of projects Very earliest (Concept/Select) Very late in a project HFE design reviews of plant already built Usually during detailed design Often mine is the first HFE study for the project Most ‘inherited’ early HFE studies have been poor. 5
- 6. Late stage design review 6
- 7. Some HFE is being done early Screening Often simply says HFE is important for most (or all) of the project Strategy Often adds little more than saying HFE needs to be addressed at later stages of the project Fail to answer the ‘so what?’. 7
- 8. 8 Using HFE to influence key decisions Start of project and throughout Project office
- 9. We need to work with engineers Very clever Highly educated Inquiring minds Professional Good looking Good sense of humour Busy. 9
- 10. Once invited, we need to: Understand the project Be clear about human factors requirements and opportunities Provide solutions. 10
- 11. Demonstrate we can make a difference Setting project philosophies for HFE Automation Human machine interfaces Staffing Etc. Options selection Objective HFE criteria ALARP demonstration Task analysis Transition to operate phase. 11
- 12. We need to be experts Don’t get sucked into the mundane HFE activities Ticks the box Uses the budget Doesn’t add (enough) value. 12
- 13. Don’t waste our time in 3D model reviews 13
- 14. Valve analysis is not our job 14
- 15. Standard physical ergonomics - not enough 15
- 16. Avoid psychobabble Engineers may be interested in theoretical concepts but will not apply them System 1 and 2 behaviour Normalisation of deviance High reliability organisation Our job is to: Understand how these concepts are applicable to the project Help the project to develop the best deign solution. 16
- 17. If you are invited to develop in-house HFE standards/procedures Don’t assume that those used by multi-national mega companies are appropriate to your client Or that those standard/procedures actually work in the company that developed them! Be prescriptive about what needs to be done early in the project Don’t allow it to be viewed as an option Require detail Consider developing template plans Whatever is easy for the project team. 17
- 18. Conclusions HFE is seen as important But… It is quickly put on the ‘back burner’ if it starts to get difficult Even if the regulator requires it Project engineers have a lot to do They need a tick in the HFE box They will respond positively if approached correctly A lot of projects happen without any formal HFE. 18
- 19. 19 Ref: Martin Robb via LinkedIn – used with his permission
- 20. Recent experience Two clients have ‘seen the light’ Procedures in place for HFE in projects Require HFE studies at very early phase Still reliant on an individual to prompt and organise If that person doesn’t do it - it doesn’t happen Multiple issues being highlighted Some potential show stoppers Updating project specifications as a result. 20
- 21. 21
Notas do Editor
- My aim with this presentation is to make the case for doing more human factors earlier in projects. It is focused on the oil, gas and other process industries as that is where my experience is. I don’t know, but I suspect similar issues apply to other industries.
- I thought I would follow the corporate style of starting with a disclaimer. This presentation is only my opinion. But as I am self-employed I don’t really need to worry about what my employer thinks.
- Really what I am trying to say is that I have based this presentation on my experience. I purposely did not carry out a thorough literature review, although I was prompted to look at a few books by the people who reviewed my original paper. The reason I didn’t feel compelled to do a literature review is that the importance of considering human factors in the process industry has been accepted for a long time. Professor Trevor Kletz made the case in the 1980s, and as far as I am concerned this has been accepted by industry. The problem, in my opinion, is that we keep repeating the same message of why human factors is important but we are not clear about how to do it. To put this another way. I have seen the same problems repeated on numerous projects over recent years. There has been plenty of literature available on the subject in this time, but the problems continue to occur. I see this as evidence that the current messages communicated in literature has not and is not working. Hence we need to change the message.
- If I am going to ask you to listen to my opinions based on my experience I had better justify myself. I have worked in human factors for over 20 years, and over the last 8 or 9 years I have begun to get involved in numerous capital projects – I think this is now what we call human factors engineering or HFE. This has included about 15 UK based projects and over 20 in the Middle East. Also, one in Africa and another in Australia. I have provided human factors support on a range of projects. Some have been relatively small modifications. But I have also worked on some very large projects. As well as particular projects, I have helped a couple of clients to generate their in-house standards or procedures for integrating HFE into their projects. I am aware that these are actively being used and my message of thinking about HFE as early as possible has been accepted well. I would also point out that I still do a lot of consultancy work at operational sites. There are a lot more of these than there are capital projects, so this is essential for my income.
- Across the approx 40 projects I have worked on I have been engaged at wildly different stages. A few were have been in their very early stages, which we would call concept or select. A couple of times I have been asked to carry out design reviews of plant that was already built. Most of the time I have been engaged during the detailed design or execute phase. Often this is the first HFE study for the project. On projects where HFE studies have been carried out before I have been involved, they have invariable been poor, with very little detail and nothing useful to the project engineers.
- I was somewhat surprised when I was engaged to do a design review and found this sat in the yard nearly ready to ship.
- It is not fair to say there is no HFE being done early in any projects. The problem, in my opinion is that the work that is done is of very limited value. For example, HFE screening has been accepted as a standard requirement. On the face of it this makes sense as it should allow us to focus effort where it can have the greatest effect. But what generally happens is that screening is done and simply says HFE is important to most (or all) aspects of the project. Also, strategies do get developed but they are often do similar. They say HFE is needed and allow for it to be done during later stages of the project. But these strategies are not clear on what needs to be done or why it is OK to do it later. The failure in my opinion is that HFE work is done but it does not add value. You read the report and come away thinking ‘so what.’ I appreciate that there is a view that you cannot do a lot of HFE early on because the detail is not available. And, if you do a lot it may have to change as the design evolves over time. I don’t really agree with either of these views.
- One of the problems is that we can’t just do HFE on projects. We have to be invited. If the client doesn’t invite us until late in the project there is nothing we can do about it. We need to understand why we are not being invited and work harder at explaining why this needs to change.
- This means we need to make the case to project engineers as these are the people who are going to invite us. If they don’t see the need to do HFE early it just isn’t going to happen. Now engineers are very talented bunch. They are clever and well educated. They have inquiring minds and take an interest in lots of different things. They are professionals, and expect everyone else to be. All engineers are very good looking and have a good sense of humour – you may guess I am an engineer? But a major problem for us is that they are very busy. Projects can move very quickly and there is a lot of detailed work to be done. If something new like HFE comes along it has to be clear to the engineers what it is going to involve and why it is important, otherwise they won’t pay it any attention. My experience is that as soon as it appears to be difficult, all aspects of human factors is put on the back burner. This is even the case when a regulator is demanding that it be addressed.
- If we do get invited to a project we need to respond quickly and decisively. In a way that engineers understand easily. This requires us to quickly understand the project, why it is important and how HFE can assist. We need to be very clear about requirements and opportunities. Any vagueness makes it sound like an optional extra. Most importantly, in my opinion, we need to provide solutions. If we tell an engineer that there is a problem with their design they may be interested, initially, but will quickly lose interest. Given the pace that projects move this will mean that the opportunity to make a difference will be missed. Our job cannot be only to highlight the problem.
- The areas where I think we can make a difference include setting philosophies. For example, if we can explain why the use of automation needs to include a consideration of human capabilities and limitations we can demonstrate that better solutions can be developed. If we are able to get engineers to understand that there is a big difference between a good HMI and a bad one we can help them avoid rework during the design phase and problems during commissioning and operations. If we can get the project to talk about staffing arrangements early on we can help them to understand that their design may have to change depending on how many people will be engaged to operate and maintain the system, their skills and competence and how they are organised. A key element of this is getting human factors considered when design decisions are being made. If we can explain why one solution is better than another we are more likely to get into the position we want to be, which is to make a difference. But we need to be objective and make the case in a way that engineers understand. And we need to be realistic. Our preferred solution may not be selected, but by being part of the process we will be better able to support the ultimate requirement, which is to demonstrate that the overall risk of the design achieves risks that are As Low As Reasonably Practicable. One thing that I am very clear on is that task analysis is very useful and highly regarded by everyone. But there is a tendency to leave it until later in the project. The problem here is that our findings often come too late to make a difference. But I know we can start our analyses very early in a project and although details may change the general findings remain applicable and useful. Ultimately I think our role in a project is to keep the project focussed on how their plant is going to be used when it is complete. Unfortunately design engineers are not always so interested in this aspect because they will not be there when the problems occur. But there is an increasing awareness of problems that occur when a project is being commissioned and through to early operation. One thing that is becoming apparent is that a lot of issues highlighted during pre start-up audits are related to poor consideration of human factors in the design. And these problems can result in delays in projects being signed off as complete and ultimately delay the designers getting paid
- However, we need to be careful in how we get used. We have to remember that HFE is a box that needs to be ticked, but because the discipline is not very well understood it is easy for that box to be ticked just because something gets done rather than because the right things gets done. I have observed that it is easy for the HFE expert to get sucked into doing mundane activities. The project engineer is happy because their box has been ticked and the budget has been used. But we have not added any value. This is a missed opportunity for the immediate project and does little to further the case for doing HFE better.
- For example, 3D model reviews are now a standard activity in most projects. They do, quite rightly, have some relevance to HFE. But that does not mean that a HFE expert needs to attend them all. They take a long time and a lot of issues are discussed. You can quickly spend the total HFE budget and not have time to do the more useful and interesting things. My approach is to ask for a high level overview of the 3D model and then to take it away and do my own review. I can then pick out items that don’t look right and ask for an explanation. Not everything I find is a problem, but I invariably find some issues. As a minimum, this acts as a HFE audit of the model. You quickly get an idea of how well HFE has been considered in its development and how well human factors were considered in the project’s reviews.
- Valve analysis is another standard activity for many projects. Again, it is relevant to HFE but does not require a high level of expertise. My approach is to work with the piping engineers to develop the rules to be applied. I will then review their analysis. Again, this is an effective audit.
- And if asked to review a control room design we really should not be spending any time on the standard stuff. If they have bought chairs, desk etc. from a suitable vendor they will satisfy ergonomic requirements. We need to be taking an understanding of the process and organisation to determine if the right equipment it being supplied, if the layout is going to support communication and teamwork and encouraging better design of HMI.
- One thing that concerns me is the tendency for the profession to waffle and use psychobabble. Engineers are people who are interested in things. They may take some time to try and understand theories and concepts but they will not apply them. If you find yourself using this psychobabble you have lost the plot. It’s OK to throw it out there during coffee break or over a pint in the evening, but not in a design meeting. Our job has to be to understand these theories and concepts and to identify how they can be applied in a project. We can use them to explain why our chosen design solution is preferred, but the important thing to communicate is the solution.
- If you are invited by a client to help them develop their in-house standards or procedures you have a great opportunity to make a difference. But make sure what you come up with something that works for the client and the way they manage their projects. Don’t assume that the approach taken by mega companies is going to work for your client. In fact, don’t assume that the systems being used by those corporations actually work for them. Large companies seem to be good at creating bureaucracy that does not always add much value. Be very clear on what is required. Almost blunt. Emphasise the need to start HFE early and to include detail. Don’t leave the door open for HFE to be seen as optional or something that can be deferred. Consider generating a template or proforma HFE plan. If this makes it easier to use it is far more likely to be used in practice.
- To wrap up. Human factors and HFE are seen as important in the process industry. They have been for 20 or more years. Where we have failed is making it clear about what this means and how it can be done. We have not communicated to engineers in a way they understand. This means it seems to be difficult and HFE is quickly put on the back burner, even if the regulator is demanding it. We need to remember that project engineers have a lot to do and HFE is something often seen as an extra. No matter how interested they are, it can easily be seen as a box to tick rather than a critical part of the project. But in my experience, when given the opportunity they will respond very positively once the cost vs benefit is demonstrated in practice. Ultimately we have to reflect that a lot of projects are being done without any formal HFE. This is a big failure for our profession.
- I would like to finish with this conceptual illustration develop by Martin Robb based on a paper from NASA. It clearly shows the benefits of addressing HFE earlier rather than later.
- I am sure some people will be wondering whether my views can work in practice. Is it really possible to do meaningful HFE at a very early stage in a project? In the last two years I have worked with two clients to develop in-house procedures for dealing with HFE in projects. In both cases I have been successful in making the case for studies to be conducted at a very early phase. Making this a requirement in the procedures has been accepted. However, it does appear that getting this done currently relies on a specific individual making sure it happens. If that person was not involved, I am not yet convinced that the project team as a whole would necessarily do it. I have now been involved with a couple of projects at both clients. What has been very interesting to me is the number and nature of issues that have been highlighted, with clear actions to be carried out. Some of them could have been significant show stoppers if they hadn’t been picked up. The output from the studies has resulted in updates to project specification, which I take as an indication that we have made a significant difference. Of course, I don’t know if these issues would have been identified via other project studies, but it seems pretty clear that they would have emerged at a later stage with potentially costly implications.