How to adopt and implement software in the EHS department? – Part 2

implement ehs software - team building

In the first part of this series, we looked at ways to navigate past the potential bottlenecks for successful implementation of software. We emphasized the importance of making a list. We also distinguished between the functional and non-functional requirements. Finally, we looked at the various ROIs through time spent by stakeholders and the potential costs involved.

In this part, we attempt to explain the various teams and individuals that are potentially needed to make implementation successful and sustainable.

Once your objectives are in place, one needs to build a suitable team that would actively invest dedicated time and effort to ensure productive implementation. This is a crucial and highly important step in the overall planning.

Building a team

Once your vendor partner has been finalized, it is time, as an organization, to build your team for undertaking the various activities required for the implementation of EHS management software. With clear objectives, you need to coordinate with your vendor for determining the various tasks and activities that you might have to undertake in the entire process.

Three key things to remember are;

  • Identifying appropriate persons from your internal departmental teams for forming your project team including;
    1. Functional person(s): Few actual users from your EHS team
    2. Non-functional person(s): Ideally, person(s) from the IT team
  • Defining roles and responsibilities of each of your team members

Collaborating with your vendor partner to determine each of their roles & responsibilities

Client’s Project Team

The first step for the client is to identify the key participants who would make the team for driving the project. The team shall consist of members from different departments who would be playing an active role in the project. Here are the roles they might assume in the overall process;

  • Project Manager:

The project manager is mandated to set the objectives of the requirement. His primary roles and responsibilities could be summarized as under;

  • To identify and freeze budget for the project
  • To identify and finalize the scope of the project
  • To outline the schedule and timeline of the project
  • To underline the expected outcomes
  • Assist in defining the implementation strategies that is applicable to their business unit / plant / corporate HO level

He prepares his team to set the expectations from each one of them so as to participate productively in the project. He is required to keep them aligned towards the objective of the project and not sway away from the original goal. He plays a major role in giving approvals and managing the various aspects of the project, from the client’s side.

For example, he ensures that an accurate understanding of the objective is expressed through the BRD (Business Requirement Document), which is prepared by his team.

He acts as able support and coordinates with his team to ensure all actions, schedules and tasks are done in a timely manner.

  • Functional team:

The functional team defines the functional requirements in the BRD based on the overall objectives. They are responsible for documenting various needs of the users and overall automation desired through the application.

Most users would have diverse understandings regarding software applications. Hence, it is important that they understand their participatory role in the whole project. Each user may be required to define his scope, work flows and role. He is then required to provide inputs regarding the desired automation needed.

A short summary of the role of the functional team;

  • Participate in meetings with the vendor partner for defining requirement.
  • Participate in the interim demonstrations of the application to gain knowledge and share their expectations.
  • Verify and validate by comparing the manual and digital process on a regular basis
  • Once the application or tool is delivered (final cut), they do the User Acceptance Testing (UAT)
  • Get trained and train subordinates (Train the trainer approach).

After using software for a relative period of time, they need to ensure whether there are any change requests. They need to ascertain the overall impact that such a change request can have on the overall application.

  • IT Team (Technical assistance):

The IT team is primarily required to identify and define the non-functional requirements in the BRD (Multi device compatibility, user interface, alerts & notification, security, backup and disaster recovery, GDPR compliance, audit trail, configuration, performance testing, SSO among others).

This team assists in setting aside the infrastructure requirements for the application. They are required to align all stakeholders to the budget and data security policy. They may be required to determine (in collaboration with the functional team and the vendor partner) on the hosting requirements (Cloud or Hybrid or On-premise), end user device requirements, pre-requisite software and hardware requirements and licenses.

The team is a key participant in determining all required integrations of business applications within their organization. They shall provide clear communication for executing the required integrations between different agencies involved.

Vendor Partner

As an organization looking to deploy EHS Management Software, it is also important that you understand the roles and responsibilities of the vendor partner team. As much as the internal project team building is important, it is equally important to determine the vendor team and their roles & responsibilities as well. Communication channels and its protocols must be established so that organizations can keep a watchful eye on the status and progress of the project.

In an ideal environment, these are the individual roles that vendor team members can assume;

  • Project Manager:

The project manager must assume all authorizations to ensure that there are no roadblocks in the development process. S/he must majorly focus on TCS;

  • Time
  • Cost
  • Scope

The project manager acts as the go-to person for all stakeholders and is always in control of the project. He is involved in the risk assessment and mitigation, and act as the single point of communication for Vendor partner. He makes sure that timely sharing of status happens across all stakeholder(s).

He defines the schedule as well as the communication protocols (like daily / weekly meetings). He is also party to setting of milestones and whether they are achieved within the expected timelines.

  • Project Team Leader:

The project team leader is usually a technically proficient person who acts as the architect of the application. It is under his able guidance that the application is developed and delivered. He is responsible for making sure that the software development, testing and other technical teams are aligned to the overall scope of the software. He assists his team wherever possible, in technical and other matters.

He also acts as a second-in-command to the Project Manager. He may not directly interact with clients, but is always updated on the status of the project. He participates in meetings where the client’s IT team is involved for discussing matters related to hardware, software, infrastructure and licenses discussions. He usually will interact with the client’s IT team for setting up the non-functional requirements of the project.

  • Business Analyst / System Analyst:

The Business Analyst or System Analyst is responsible for understanding the needs of the application, that adhere to the requirements mentioned in the BRD. He does the requirement workshops with the client’s functional team. Once requirements gathering is completed, he needs to document it clearly with accurate process maps, approval work flows, wireframes, business rules, and even design prototypes if and when required.

Based on the gathered information, he then prepares the System Requirement Specifications (SRS) document. The SRS contains important information (those mentioned previously) that allows his team to understand the requirements accurately in their development process. S/he directly interacts with the development and testing team for ensuring that they follow the requirements based on the overall objectives of the project.

The SRS acts as a reference document for preparing test cases, UAT scenarios which will be verified by the functional team when the UAT happens. S/he also prepares the UAT scenarios and test cases along with the team.

  • Training Team:

An important aspect of the overall implementation process is Training which is imparted by key people who are involved in the project. Primarily these trainings are imparted to key members of the client’s functional team using a “Train the Trainer” approach.

  • Support Team:

The support team comes into the picture post “Go LIVE”. They are primed for resolving any issues or challenges that users face at the time of actual use of the application. For example, any member of the functional team might be unable to understand some of the terminologies or how to use the various features of software.

There are other teams at vendor partner side who support the entire project implementation process as well – like the software development team, testing team, UI/UX designers etc. They contribute equally to the overall development of the application as well.

Building teams and setting expectations with them is an essential and truly important aspect of any successful project. Is there anything that we may have missed out in this piece? Or do you think there could be some more additions to this? Let us know your views / thoughts in the comments section.

1 thought on “How to adopt and implement software in the EHS department? – Part 2”

  1. thank you so much for sharing. this is so important to me and a great help for others.

Leave a Reply

Your email address will not be published. Required fields are marked *