2015 ESOS Guidelines Chapter 6 – Role of Lead Assessor

The primary role of the lead assessor is to make sure the enterprise?s assessment meets ESOS requirements. Their contribution is mandatory, with the only exception being where 100% of energy consumption received attention in an ISO 50001 that forms the basis of the ESOS report.

How to Find a Lead Assessor

An enterprise subject to ESOS must negotiate with a lead assessor with the necessary specialisms from one of the panels approved by the UK government. This can be a person within the organisation or an third party. If independent, then only one director of the enterprise need countersign the assessment report. If an employee, then two signatures are necessary. Before reaching a decision, consider

  • Whether the person has auditing experience in the sector
  • Whether they are familiar with the technology and the processes
  • Whether they have experience of auditing against a standard

The choice rests on the enterprise itself. The lead assessor performs the appointed role.

The Lead Assessor?s Role

The Lead Assessor?s main job is reviewing an ESOS assessment prepared by others against the standard, and deciding whether it meets the requirements. They may also contribute towards it. Typically their role includes:

  • Checking the calculation for total energy consumption across the entire enterprise
  • Reviewing the process whereby the 90% areas of significant consumption were identified
  • Confirming that certifications are in place for all alternate routes to compliance chosen
  • Checking that the audit reports meet the minimum criteria laid down by the ESOS system

Note: A lead assessor may partly prepare the assessment themselves, or simply verify that others did it correctly.

In the former instance a lead assessor might

  • Determine energy use profiles
  • Identify savings opportunities
  • Calculate savings measures
  • Present audit findings
  • Determine future methodology
  • Define sampling methods
  • Develop audit timetables
  • Establish site visit programs
  • Assemble ESOS information pack

Core Enterprise Responsibilities

The enterprise cannot absolve itself from responsibility for good governance. Accordingly, it remains liable for

  • Ensuring compliance with ESOS requirements
  • Selecting and appointing the lead assessor
  • Drawing attention to previous audit work
  • Agreeing with what the lead assessor does
  • Requesting directors to sign the assessment

The Environment Agency does not provide assessment templates as it believes this reduces the administrative burden on the enterprises it serves.

Check our similar posts

Why DevOps Matters: Things You Need to Know

DevOps creates an agile relationship between system development and operating departments, so the two collaborate in providing results that are technically effective, and work well for customers and users. This is an improvement over the traditional model where development delivers a complete design ? and then spends weeks and even months afterwards, fixing client side problems that should never have occurred.
Writing for Tech Radar Nigel Wilson explains why it is important to roll out innovation quickly to leverage advantage. This implies the need for a flexible organisation capable of thinking on its feet and forming matrix-based project teams to ensure that development is reliable and cost effective.
Skirmishes in Boardrooms
This cooperative approach runs counter to traditional silo thinking, where Operations does not understand Development, while Development treats the former as problem children. This is a natural outcome of team-centred psychology. It is also the reason why different functions pull up drawbridges at the entrance to their silos. This situation needs managing before it corrodes organization effectiveness. DevOps aims to cut through this spider web of conflict and produce faster results.

The Seeds of Collaboration

Social and personal relationships work best when the strengths of each party compensate the deficiencies of the other. In the case of development and operations, development lacks full understanding of the daily practicalities operating staff face. Conversely, operations lacks ? and should lack knowledge of the nuances of digital automation, for the very reason it is not their business.
DevOps straddles the gap between these silos by building bridges towards a co-operative way of thinking, in which matrix-teams work together to define a problem, translate it into needs and spec the system to resolve these. It is more a culture than a method. Behavioural change naturally leads to contiguous delivery and ongoing deployment. Needless to say only the very best need apply for the roles of client representative, functional tester and developer lead.

Is DevOps Worth the Pain of Change?

Breaking down silos encroaches on individual managers? turf. We should only automate to improve quality and save money. These savings often distil into organisational change. The matrix team may find itself in the middle of a catfight. Despite the pain associated with change resistance, DevOps more than pays its way in terms of benefits gained. We close by considering what these advantages are.

An Agile Matrix Structure ? Technical innovation is happening at a blistering rate. The IT industry can no longer afford to churn out inferior designs that take longer to fix than to create. We cannot afford to allow office politics to stand in the way of progress. Silos and team builds are custodians of routine and that does not sit well with development.

An Integrated Organization ? DevOps not only delivers operational systems faster through contiguous testing. It also creates an environment whereby cross-border teams work together towards achieving a shared objective. When development understands the challenges that operations faces ? and operations understands the technical limiters – a new perspective emerges of ?we are in this together?.

The Final Word ? With understanding of human dynamics pocketed, a DevOps project may be easier to commission than you first think. The traditional way of doing development – and the waterfall delivery at the end is akin to a two-phase production line, in which liaison is the weakest link and loss of quality inevitable.

DevOps avoids this risk by having parties work side-by-side. We need them both to produce the desired results. This is least until robotics takes over and there is no longer a human element in play.

Virtualisation

Using an IT solution that can provide the fastest (but still reliable) disaster recovery process is essential for the success of any business continuity plan. Although virtualisation is still considered leading edge technology by many business continuity specialists, it definitely brings a promise that, once fulfilled, can result in the cheapest, fastest, and most comprehensive solution for business continuity.

One great advantage of virtualisation over traditional BC (Business Continuity) methods is the relatively cheaper cost needed to achieve a certain level of business continuity assurance. Thus, more companies will find it easier to reach their required minimum for BC assurance. By contrast, some BCPs (Business Continuity Plan) based on a physical environment require companies to invest more than what they are willing to in order to reach the same minimum level of assurance.

Virtual machines, which can already encapsulate your operating systems and their corresponding applications, can be transported as a file from one machine running a compatible hypervisor to another. This makes the business continuity tasks of backup, replication, and restoration simpler and faster.

As of 2008, about 54% of IT professionals in Europe were willing to implement virtualisation within a maximum of two years. Furthermore, the expected compound annual growth rate of installed virtualised servers from 2008 to 2012 is already pegged at 33%.

If you want your organisation to take advantage of the benefits of this revolutionary technology, we’d be more than willing to help you discover what it can do for you. Then once you decide to make that transition to virtualisation, we can guide you every step of the way.

  • As not all applications are suited for virtualisation (e.g. some are too demanding on I/O and memory access), we’ll start by reviewing your entire IT system to see which portions can be implemented on a virtualized environment.
  • Using virtualisation and replication, we can conduct disaster recovery tests using up-to-date data without interrupting operations in your main IT site. Running these tests will increase your team’s preparedness and will allow you to discover possible weak points.
  • Provide a simple but comprehensive protection and backup system that encapsulates not only data, but also system configurations and application installations. This kind of setup allows for faster and easier disaster recovery operations. Because of these same characteristics, you can enjoy zero downtime while performing scheduled maintenance operations.
  • Since virtual machines are hardware-independent and transparent to operating systems, we can help you run a mix of legacy and new systems as well as open source and proprietary systems, allowing for more flexibility in your BCP budgeting.

We can also assist you with the following:

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
Can you do away with the Project Initiation Meeting?

Project initiation meetings are often skipped to fast-track projects. Once a sponsor is found, organisations go straight to project planning and execution. But based on our own experience, holding a project initiation meeting can actually eliminate many issues that may crop up in the future and hence may speed things up instead in the long run.

It is in the project initiation meeting where your project objectives and scope are clarified and all stakeholders are brought to the same page. Project sponsors and stakeholders will have to know in a nutshell what is needed from them, what the possible risks are, what different resources are required, and so on. So that, when it’s time to proceed to the next phase, everyone is already in-sync.

So what are taken up in such a meeting? Perhaps an actual example can help. Sometime in the past, we set out to work on an eCommerce website project. After conducting the project initiation meeting, these were some of the things we were able to accomplish:

  • Identified deliverables e.g. site design, interface to payment system, etc.
  • Come up with the project phases
  • Agreed what should be in and out of scope
  • Defined the acceptance test criteria
  • Identified possible risks
  • Identified the possible training and documentation work needed
  • Established whether any analysis was required, e.g. as with regards to payment interfaces
  • Formulated disaster recovery plans
  • Defined roles and responsibilities
  • Drafted timelines and due dates

Aren’t these covered in project planning? If the project is a big one, the answer is no. In a large project, project planning is a much more exhaustive activity. In a project initiation meeting, only the basic framework is defined.

Some questions may still remain unanswered after a project initiation meeting, but at least you already know what answers you need to look for. In the example we gave earlier, we left the meeting knowing that we needed:

  • a list of all necessary hardware to estimate the costs
  • to identify possible dependencies we might have with third parties
  • to identify what software had to be bought and what skills we needed to hire

When it was time to proceed to project planning, everyone involved already knew what direction we were taking. In effect, by not skipping the project initiation meeting, we were able to avoid many potential obstacles.

Ready to work with Denizon?

Contact Us Today