As the preparation phase of an ERP (Enterprise Resource Planning) project progresses towards the final stages of solution and vendor selection, there is often a desire to kick-start the project as quickly as possible. However, selecting the solution and the vendor alone is not enough to start the project. In addition to these important decisions, we must ensure the project readiness in the organization.
Project readiness means that the foundation and framework required to start the project are in place. One of the most important elements of project readiness is the resources, people, required for the project.
In the project proposal, the vendor lists quite straightforward, which project tasks are their responsibility and which ones must the customer take care of. Does the proposal then indicate what kind of team and what roles, how many resources are required on the customer’s side? Not directly, because what the vendor sees as the customer’s responsibility is not the full scope of what the customer needs to do when targeting to succeed in the business transformation project.
Why is this? The vendor’s focus is on implementing the technical solution (after all, that is what the customer is buying from them), and the customer’s workload estimate in the proposal shows what is required on the customer’s part in order to implement the technical solution. However, from the customer’s point of view, it is always a question of broader change, not about implementing a technical solution alone. Therefore, the customer must also reserve resources for tasks other than those that are necessary purely for implementing the technical solution.
From the vendor’s perspective, many tasks that are the customer’s responsibility may often also appear of a smaller workload than what they really are. The customer does not have the same experience, knowledge, and skills as the vendor. In many cases, the majority of the customer’s personnel has not been involved in ERP or other change projects of a similar size before. In most situations, an ERP project is something new and at least in some scale unfamiliar for the entire organization, from line operations to senior management.
Regardless of its scope, the implementation of an ERP project consists more or less of standard areas of responsibilities, from which the roles are derived. The roles are then formed into positions in the project organization, and in the final phase these positions are resourced with people, actual names. The number of positions needed in project organization depends on the scale of the project. How many people are required to cover each role and task? And how many roles and tasks can each person handle? What roles and duties can we expect the vendor to take responsibility for, and what is left for the customer to take care of? Which roles should primarily involve internal resources that are familiar with the customer’s own operations, and in what areas should external project experience be introduced?
These are based on identifying and understanding what the targeted change is, and what activities and stages are needed to make that happen.
Project management (PM) and project management office (PMO). Every project must have someone to lead it - a project manager. According to the project methodology, the title may be something else, but the responsibility and tasks themselves do not change regardless of the project manager’s actual title. The scope of the project and the targeted change, as well as the size of the company, give indication of the size of the project management office (PMO). In smaller projects, the project manager is responsible for all matters related to project management and communication and might be assisted by one project assistant or coordinator only. In large-scale corporate projects, on the contrary, project management employs several people, as coordination, monitoring and reporting responsibilities are divided into more specific roles for different people. In such cases, the project management really is an office of its own, not just a few persons team.
Communication and change management. Communication is one of the important areas in managing the project and the change. The wider the scope and scale of the project are, the more focus is needed on communication and change management. The more demanding and critical the change project is, the more likely it is that the project management office and change management experience required – and simply the number of people needed - cannot be found in the customer’s own organization. In this case, it makes sense to seek the necessary resources from outside.In large-scale projects, the project manager is called director, and is often not part of the project management office. The PMO has its own leader, the same way as the change management team, and both report to the project director.
IT project management (IT PM). In every ERP project, technology and IT form a significant part of the project, even though an ERP project is not primarily launched to benefit IT. An ERP project should always have clear business benefits and targets, which are enabled by technology and IT. Due to this, in addition to the project manager or director, the ERP project requires an IT project manager as well. The vendor brings in their own project manager who is responsible for coordinating resources, activities and progress on the vendor’s side. Even though the vendor’s team has very strong technical expertise and responsibility on the ERP solution being implemented, there are lots of other technical work on the customer’s side as well, areas and tasks that the vendor is not going to handle. The customer’s IT landscape with other systems and service providers is always somehow affected when a new ERP is being introduced. Managing all this involves infrastructure, various devices, third-party applications to integrate with, communication with third parties, security, access management, and more. The technical project manager puts together the technical team, a network consisting of the necessary technical experts both from customer’s own organisation and third parties, to manage the technical track of the project.
Functional and process teams. In an ERP project, the primary focus is on business and its processes. These are supported by the implementation of the new technical solution. Therefore, the main business processes and how they are organized, often form a natural framework for the structure and quantity of functional or process teams. Each team must have a team lead. In an ideal situation, the leads of these teams come from the customer’s organization, and are people who know the business, its processes and operational activities on a practical level. They must have sufficient capabilities to coordinate things and be willing to learn and develop both their own capabilities and those of the rest of the organization. If the team leads are appointed as project managers, there should be a clear and common understanding about the team’s role – is it an independent sub-project or a fully integrated part of the project? An independent sub-project, with its own project manager, can be separated from the scope and schedule of the main project, if necessary. In that case we have a program director sitting on top of a program consisting of individual sub-projects, which are aligned more on an administrative and financial level than project execution level. When the functional teams form an integral part of the project rather than independent sub-projects, it is clearer to use the title team lead and avoid confusion and distortions in terms of responsibility and authority at the team level. In a typical ERP project, business-driven teams are typically based either on functional business areas or business processes crossing the functional areas. Functional teams are typically sales, supply chain planning, procurement, logistics, production, finance, and HR management. Depending on the industry and the scope and complexity of the business operations, service management and plant maintenance, product development, project business and e-commerce can also be separated into their own teams. Based on the nature of the industry, product management and customer account management may form such large and critical entities that it is advisable to separate them into their own teams. Process approach on the other hand usually defines teams based on end-to-end processes like order-to-cash, procure-to-pay, forecast-to-deploy, record-to-report and so on, which then have different functional business components under them. Different functional or process teams may vary widely in terms of the number of resources they need. The workload of each team and their resource needs are primarily affected by the scope and complexity of that team’s responsibilities. For example, the more sub-processes or business components there is in a team, the more systems are to be integrated with the new ERP, the larger the group of end-users there is, the more members the team will also need. Team members grow into super user and key user roles during the project, so they will also be in a key role in the further development of the system after it is implemented into use.
Cross-functional teams. For functional or process teams, tasks are largely assigned through cross-functional teams. These teams are mainly organized by project phases and main activities, and each team must have a person in charge. Again, the size and scope of the project determines how many members each team has. At smallest, a team lead is sufficient, whereas in large-scale projects these teams form their own offices, just like PMO. Below are the main areas that coordinate the project areas and phases across with functional teams.
Architecture. ERP architecture work connects to many layers, from the company’s overall architecture to process architecture and all the way to detailed integration and data architecture. The solution architect of the new ERP is part of the vendor’s team, playing an important role in ensuring appropriate solution functionalities and quality. Adapting a new ERP system to the existing landscape of the company requires an architectural insight on the customer’s side as well. If there is no suitable person for this role within the company, an external architect resource should be considered.
Data and data migration. Since an ERP is an information technology solution, huge amounts of information, also called data, are processed in an ERP project. There can easily be several hundreds of data objects, each of which contains a huge number of records and accompanying data fields. Data is collected, compiled and cleaned. It is mapped, converted, transferred from one place to another and validated. All this will be done several times during the project. Data migration is one of the critical entities for which the vendor manages only part, not the whole. The data migration lead is one of the roles for which an external resource must be considered at an early stage if it is not possible to find a suitable person inside the organization.
Testing. Like migration, testing is also a critical area where the vendor takes charge only of its own clearly defined part. Before actual testing, the testing strategy and objectives, practices, tools and schedules must be planned, not to mention the content of the test itself – that is, the test cases. This whole area must also have a responsible person, a test manager who coordinates the testing from strategy all the way through to approval. The testing is carried out by the functional teams, and successful testing is the test manager’s most important priority.
Training. Training coordination is similar to testing coordination but less demanding, involving a lot of practical arrangements for organising training sessions and events. The training coordinator may as well come from within or outside the organization, but vendors are typically not known to take this role as their responsibility.
Cutting over and going live. The actual cutover from the old system to the new ERP takes place in a relatively short time, at best even overnight, and often within a period of a few days. After this, the new ERP goes live and its business use starts. Although the execution of the cutover lasts a relatively short time within the whole project, it must be carefully planned, and planning started at an early stage. In addition to the technical activities in cutover, the overall cutover planning also includes a lot of business preparation to ensure that the technical activities run as smoothly as possible. Typically, a sufficiently experienced and competent cutover manager is not found in the customer’s own organisation. When external expertise on this area is required, it is a good idea to start the search well in advance at the beginning of the project.
And where are all the coders, developers and other IT experts? They are part of the vendor’s team, consultants, and other ERP development professionals. The development and build phase and related implementation tasks are the part of the ERP project for which the vendor or vendors are primarily responsible for the ERP go-live as a whole.
Once the structure, tasks and positions within the organization are defined, it is recommended to document these as clear role descriptions. What is the purpose, responsibility and tasks of each role? What is expected of the person in the role in terms of skills, experience, use of time at different stages of the project, as well as language skills, willingness to travel, amongst other considerations? When there is a clear role description for each position, confusion and disappointments at a later stage can be avoided. One of the cornerstones of smoothly running project work is that each person involved in the project understands his or her own role, responsibilities and tasks, and how that role is linked to the project as a whole.
Once the project organization, positions, and roles are determined, you can start nominating people to these roles. In project appointments, it is essential to identify the necessary skills, experience and ability required for each role. The primary goal is to resource the project with sufficient, competent and suitable persons. There are positions and roles where content expertise is absolutely essential. For those roles, we need to find experts with a suitable attitude for project work. On the other hand, both in projects and line organizations we always have roles where experience, capabilities and attitude play a more significant role, and the content can be learned relatively fast. At the end, when you have the project organization chart, it is good to cross-check that there is a person assigned to each role, and that everyone assigned to the project also have a role.
The project organization is finally set! The role descriptions are in place. People have been assigned to the roles. Before diving into the project, however, it is advisable to first have some more patience to ensure that the new team is properly introduced to the project and ready to start working as a team. A project team is always a unique ensemble – it is most likely that the established team as such has not worked together before. Especially for people moving from their own line organization to a project, there will be a lot of new things during the project, and expertise will be gained along the way.
Before starting the project work, it is important to ensure that project governance and decision-making models, as well as common practices and tools are clear and understood by all. On top of everything, we have the project spirit, culture and way of working together, which also have a decisive role in the success of the project. It is essential that everyone has the knowledge and the courage to point out any issues or questions that arise during the project, and that there is an appropriate forum for doing this. Team introduction can easily be overlooked when a project is starting. However, it is worth putting some extra effort to this area, as, ultimately, everything that is being done or left undone in the project depends to a large extent on this particular project team.
Be prepared for surprises. Some area of work or specific tasks may turn out to be more demanding or laborious than was understood at the beginning of the project, or vice versa. A person might leave the project for one reason or another. The governance model for managing changes needs to be clear also when it comes to resource changes during the project. Decisions and actions need be made quickly and in an agile manner. The knowledge transfer from people leaving the project becomes easier when the project has clear and common practices and tools. It is important to take some time to introduce and familiarise newcomers with the whole project, even within a tight schedule, rather than to throw them in at the deep end.
Keep the role of the line organization in mind. In addition to the people in the project organization, the project will inevitably also require the line organization’s time and effort. In addition to each person’s own tasks, other tasks are bound to arise as the project progresses. Participation in definition workshops and decision-making, cleaning and validating necessary data, as well as participation in trainings, and partly also testing, must be considered. As part of the resourcing the ERP project and publication of ERP project organization, it is good to remind the line organization that there will be some work for them as well. An ERP project typically leaves nobody out in the company, everyone gets their share in making the targeted change happen.
Organisational change management frameworks, like Prosci and ADKAR, have their merits but also limitations. I acknowledge these methodologies' popularity and ...
Read moreThe year 2023 had lower-than-normal M&A activity. This was mainly due to the high interest rates yet still high company ...
Read more
One of the strategic objectives of Kontiotuote Oy (later Kontio) for the strategy period is "exploiting the potential of digitalisation". ...
Read more
