ERP Projects Management

You might be thinking to yourself that this tip is project management 101. True, but have you ever experienced how quickly it can rear its head in a software implementation?

Here’s a simple example of how something deemed out-of-scope can suddenly find its way into your ERP project plan: maybe that all accounts payable business processes are in scope for the project. A list of business processes is included in the SOW, and “settle vendor invoices” is a process that makes the cut. In the SOW, it is also noted that automated workflows are out of scope. Now imagine the team conducts an ERP requirements gathering workshop and notices that several of the requirements are related to workflow. These requirements are valid as they are required to complete their business process. The business analysts or ERP consultants on your team may go ahead and configure these requirements if the ERP software can handle the requirements.

What’s the issue here? While it is admirable of the team to configure the ERP system to meet the business requirements, what is not immediately apparent is the impact this has on the project timeline. Introducing workflow to the project scope now has added hours for testing and regression testing. This is why quelling scope creep early on is so important and can save you from being weeks behind on your project plan.

The classic project management constraint triangle of scope, time and cost is infamous for a reason. One cannot increase or decrease a factor without proportionately doing the same for the others.

Unfortunately, since time is based on predictions of the future, it is usually the factor that is frequently underestimated. That said, when creating your project timeline, it’s important to be realistic about the schedule. If your project sponsors are adamant on having all requirements gathered in Three months, but you have 16 weeks of workshops to get through, it’s time to have a reality check with your leadership to either increase the timeline or reduce the scope.

For many implementation projects, the need for more resources is common. However, adding more resources does not always solve timeline issues. In many scenarios, there are a handful of project resources (i.e., subject matter experts) that are required to attend all critical meetings. Just because there are four ERP consultants for a workstream, doesn’t mean that four workshops can be conducted simultaneously.

Creating a timeline for software requirements gathering, design and development is fairly straightforward: You can estimate the complexity of a feature in terms of design and development, and based on this complexity, you can determine approximately how many hours or days of testing is required once the feature is delivered.

However, one element almost always forgotten when building the project timeline is regression testing. Regression testing is retesting all test scripts previously passed to ensure any new development has not impacted the results. Regression testing for ERP requirements can sometimes take even longer than testing the new feature itself.

Lately, there has been a trend of automating regression testing using predefined test scripts. While this automation may save you time in executing the regression testing, it’s still important include time in the project plan to build the test scripts to program the tool.

There’s a good chance that multiple team members will be writing design and integration documents, but only a few will review and approve them.

To bring some consistency to the reviewers and approvers, we recommend sticking to a standardized template for design and integration documents.

This will allow reviewers to quickly review large documents and help them zero in on complicated sections needing extensive review. This also saves time for the authors of the documents, as they will be reminded of what elements to include, such as performance considerations, security requirements and test scripts.

A weekly, or sometimes even daily, requirement for ERP project managers is to report out the project status. Since project managers cannot possibly attend all workshops and meetings, the data for these reports are provided by other project team members.

Asking for daily or weekly updates from each member of your team is time consuming for all parties involved – the business analysts and ERP consultants have to set aside time each day to write up a report, and then you as the project manager have to combine all these individual reports.

However, if your project is leveraging a DevOps tool, you can simply extract the needed data on demand to put in a report. This eliminates the need for your project team to do double work since they will already be completing and updating their tasks in Devops .

Devops tools have become increasingly advanced when it comes to reporting. With some tools, you may not even need to extract the data as the internal reporting capabilities may suffice.

One deliverable often overlooked or rushed through during an ERP project is a cutover plan. A cutover plan is a list of activities required to prepare the production environment for end-user use. Examples of cutover tasks include loading user IDs into the system, kicking off batch jobs, connecting hardware components to the ERP solution and starting any integration services.

Cutover plans are extremely important as there are many tasks required to get an ERP system production ready, and many are dependent on one another. As an example, consider the task of starting integration services. Most ERP systems require a user ID to identify any records created or updated via an integration. However, if the user IDs haven’t been loaded yet, this task can’t be completed. Part of creating a cutover plan is to sequence all tasks in order of dependency.

Another key succes

s factor in building a cutover plan is building it while the system is designed. During a six-month (or longer) ERP project, you risk forgetting activities if you wait until the month before go-live to create your cutover plan. It’s best to seek input from all team members throughout the project.

Employee burnout is real. All work and no fun can really bring the morale of the team down, along with the health and motivation of individual team members. It might sound counterproductive to take time away from work to get out of the office and have some fun, but there is extensive research that happier employees produce better results.

In fact, team bonding activities can help break down barriers that exist in the workplace. Team members that wouldn’t normally interact can get to know each other and what their responsibilities are on the project.