The changing role of the technology team in ERP implementations (part 3)

In two previous articles, I described several areas where the role of the technology team in ERP implementations has changed in the last ten to twenty years.  Here is part 3, the final installment.

Single sign on

This capability makes life much easier for the end user. Although it is easier to implement than it used to be, it still requires set up, testing, and support by the technology team.

 

Disaster recovery

In a cloud environment, you won’t be managing databases and servers any more. The scenario where your entire data centre collapsed and you lost all your systems at once will change to multiple application-based or vendor-based scenarios. You need to re-think what disaster recovery planning and testing should cover. You also need to verify that participation in disaster recovery planning and testing exists in your contracts with cloud vendors.

IT controls

If you’ve been outsourcing some of your IT functions already, you’re familiar with this. Although your organization is responsible to ensure IT controls are operating effectively, many of those controls will now be implemented and operated by your cloud vendors. Relevant IT controls will need to be reviewed internally and with the vendors to identify if any controls need to be re-designed, and how they will be tested. Selection of your ERP system and negotiation of the contract needs to consider IT controls and associated Service Organization Control (SOC) reporting requirements.

Application support model

With ERP in the cloud, the internal support team no longer needs to be heavily weighted toward database analysis, operating system, and hardware experience. Instead, the team’s focus will be on the business process, how the application supports the business process, and reporting and data governance. This is a significant shift in mindset and skills for many IT support managers and staff.

If the existing ERP is supported by manual processes, your business users will certainly want to automate more when the new ERP is implemented. E.g. on-line workflow to replace email approvals. As a result, the number of ERP users you support is likely to be higher than it is today.

Vendor management

Given the number of areas where your IT organization now relies on vendors (ERP, integration, disaster recovery, IT controls), it is evident that a key responsibility and skill set in your operational support model is vendor management. This may be an area in which your team requires bolstering if you have not been outsourcing or using cloud very much to date.

Conclusion

Technology is so ingrained in business processes today that there’s no such thing as a fully manual business process any more.  Having the business define the new processes and handing off requirements to the technology team is not a workable process. Business analysts have to participate fully in the business process workshops, identifying requirements along the way for everything from mobile device needs to interface and data conversion requirements.

In addition, your technology team for the ERP project, whether internally available or contracted, needs to support a wide variety of requirements that didn’t often exist two decades ago: mobile technology, browsers, firewalls, single sign on. In addition, the approaches to disaster recovery, IT controls, and application support likely need to change.

As you can see from this article and the previous two, the role of the technology team in ERP implementations has changed significantly. So, if you are implementing ERP soon, and it’s been ten or twenty years since you did so, you should anticipate and plan for all or most of these differences.

The changing role of the technology team in ERP implementations (part 2)

In a previous article, I described several areas where the role of the technology team in ERP implementations has changed in the last ten to twenty years.  Here is part 2.

Importance of data

ERP and other application implementers have historically considered focus on People, Process, and Technology as the foundation for success. In the last several years, it has become apparent that Data is a fourth and equally important element.

Data, including its definition, conversion, integration, and governance have become critical to the success of the implementation and the ongoing usability of the ERP system. Although the data is owned by the business, they generally require support from the technology team in supporting data governance and enforcement of data standards.

Downstream systems

Due to changes in master data or the business meaning of data when you implement a new ERP, combined with the integrations, you may have many changes to data in applications you connect to/from.

One of the causes will be data re-numbering. For example, if you change significant master data such as customer number, vendor number, or part number, you will likely have a business requirement to update existing data in other systems besides the ERP.

In addition, when implementing ERP, the business may take the opportunity to change the meaning of the data. For example, the existing ERP may have Acme Toronto, Acme Vancouver, and Acme Calgary all set up as separate vendors. In the new ERP, the business may choose to eliminate these three vendors and instead create a vendor called Acme Canada with three sites in Toronto, Vancouver, and Calgary. You can see that this would have an impact on the way that integrations to/from other applications are designed; and the potential for changes to existing data in those systems.

Data cleansing

Data often requires cleansing in order to accommodate a new ERP. In addition to correction of issues with existing data, the business may want to develop data for the ERP that exists only in spreadsheets today. The technology team is often called upon to support data assessment and may also need to provide tools and processes to support data creation and standardization. 

Workflow

Workflow can enforce controls and retain documentation of approvals, and is built into modern ERPs. In a cloud environment, the notification emails will be crossing multiple corporate firewalls. Similarly, if you are using your ERP host or another external party to provide integrated services such as invoice scanning, there will be technology-enabled processes crossing internal and external environments. Your technology team will need to be involved in the security design and implementation.

Customizations

If your existing ERP system is customized, you know what a challenge it is to keep up with upgrades, as modifications need to be re-established with each upgrade. With cloud ERP, it is easier to push back on the business when they want to customize, as cloud lends itself to adherence to the vendor’s standard offerings. However, where there is a real business need, you may need to develop the customization outside of the ERP, leading to another system and interface to manage, and the necessity of supporting business questions on differences between the two systems.

System cutover

Along with the transition of business functions to the new application and processes, there will be a number of technical steps involved as well. Cutover tasks may include turning off/on interfaces and scheduled jobs, and providing updated charts of accounts and other master data (e.g. customer numbers) to other systems and business partners. It is also common to prevent data updates in legacy applications by modifying user roles when the new ERP goes live.

Stay tuned

There is more to cover on the changing role of the technology team in ERP implementation. Watch for part 3.

Introduction to IT Project Risk

While working on a variety of IT projects, I’ve seen several project charters and risk registers. Over time, I’ve noticed that not all project managers have a solid grasp of how to identify and mitigate project risk. So, here’s an introduction to the subject.

These aren’t project risks

Perhaps it seems an odd place to start, but the most common problem I see is that many risks identified aren’t really risks.  So, what is not a project risk?

An issue is not a project risk.  An issue is something that is already a problem for the project. E.g. a risk item that states: Vendor is late delivering components. Since the vendor is already late, or you already know the delivery is going to be late, this is an issue, not a risk. A risk is something that could happen, but hasn’t happened yet.

An outcome is not a project risk. E.g. a risk item that states: The project might not go live on time. This statement is an outcome of one or more events that could happen, for which the outcome is that there could be an impact on the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.

Also, a vaguely-defined concern isn’t a risk. Risks aren’t really properly identified if they are not specific. E.g. a risk item that states: Testing is a risk. This statement is too vague, as it doesn’t say what specifically about testing is a risk and why it is being identified.

These aren’t mitigation plans

In addition to incorrectly identified risks, I often see vague mitigation plans. E.g. Manage dependencies and milestones. E.g. Leverage vendor’s experience. These mitigation plans are too vague to be actionable.

What are we worried about? What will we do about it?

Every book on project management has a risk definition along the lines of “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a definition of risk mitigation, such as: “Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.” (PMBOK, Fifth Edition)

Although accurate, these definitions can be simplified to aid understanding. The easiest way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?

Then, once the worry and rationale are very clearly defined, the mitigation plan is based on:  What very specific actions are we going to take regarding that worry?

An example

Do you have reason to believe the vendor might deliver late – before it happens? For example, maybe the vendor has recently made a lot more sales than usual and you’ve had late deliveries when you’ve bought from other fast-growing vendors. If so, you can record the risk very clearly: Vendor has gained significant market share in the last three months. Based on our experience with other vendors, this market gain can have an impact on manufacturing capacity, which may result in late delivery.

If you want to avoid this event, think about what options you have to avoid your project being derailed by late delivery. For example, if the contract isn’t signed yet, can you build in a penalty clause, or pay a premium for on-time? Can you spend extra effort on vetting your requirements to ensure your own project doesn’t cause any impact on the vendor? Do you have access to other equipment you could use temporarily if the delivery is late? Does that strategy lead you define an additional risk and mitigation plan? Ask others for ideas on how they’ve managed this kind of risk before and how successful the strategy was for them. Be specific in your mitigation plan: go beyond platitudes such as good project management.

Do you have other worries?

Anything that causes you a specific concern is a candidate to be included as a risk.  Risks are as varied as the projects on which they arise. Here are a few examples I’ve seen: (1) Servers are being moved from a company-run to an external data centre during the same time period that our project needs to test connectivity for several interfaces. Testing connections to the old data centre will need to be repeated for the new data centre, with potential for delay to our project’s timeline. (2) Although the on-site project manager assigned by a major vendor has great leadership skills, he’s not particularly rigorous about scheduling and tracking against the schedule. Since he is managing a large team and a tight delivery timeline, we are concerned that we won’t have adequate visibility to progress or lack thereof. (3) Previous upgrades to this application have failed due to lack of understanding of the integration points.

Notice that all of these risks are very specific, and they provide a rationale for why the risk has been identified.

Schedule and follow up

Assign a responsible person and due date for every mitigation action item. If you aren’t able to assign a person and due date, the mitigation step probably isn’t defined clearly enough. Track these mitigation steps to make sure that they actually get accomplished.

Conclusion

Understanding of IT project risks and mitigation plans can be improved by simplifying the definitions to: (a) What you are worried about exactly and why; and (b) what you will do about it.

It is important to be very specific and provide the rationale for the risks. The mitigation plan needs to be detailed enough that each task in it can be assigned to a person and on a specific date. 

Project risk: Vendor management case study

Working with vendors is a fact of life on technology projects. It makes sense to engage vendors to work on your projects. They have product experience with many clients and can bring best practices in addition to technical expertise.

However, vendors are not your employees and it is wise to remember that their goals and your company’s goals are not always completely aligned. As a result, in addition to the benefits, there are risks in bringing on vendors to deliver your projects.

Case study

Here’s an example of a project gone off the rails due to issues with selecting and managing the vendor.

The client had issued a Request for Proposal (RFP) and selected a vendor to implement a new application and its supporting technology platform.

The vendor started missing deadlines early in the project. The client’s requirements for performance were not met. To resolve the performance issues, the vendor proposed hardware changes. The resulting procurement and installation time caused more delay.

Unfortunately, installation of the new hardware did not resolve the performance problems, so the vendor embarked on a series of changes to try and improve performance.  Time after time, the vendor said the performance changes would be done by the following week, but every time they were unable to deliver the improvements.  It was clear that the vendor’s team was working hard, including evenings and weekends, but still the system could not operate within the necessary timeframe.

After months of promises followed by non-delivery, the vendor asked for a three-month period to achieve the necessary performance. The client agreed to the three-month timeline, but once again, the performance metrics were not achieved.

At this point, the vendor asked if the client would make changes to other applications in the same business process. As long as all of the applications fit into the overnight process, the vendor’s own application performance would be of less concern. The client agreed to modify other applications, which caused further delays while requirements, development, and testing took place.

Unfortunately, the changes to the other applications were not sufficient. When done, it was clear that the vendor would still have to significantly improve the performance of its own product.  

The vendor continued to work at application changes and database tuning to try and correct the performance issues. When that failed to achieve the desired results, the client agreed to examine the business process to see if they could change it to accommodate the product’s performance issues. The process re-design did not create enough efficiency to solve the problem.

If you’ve ever been in this position, either as vendor or client, you know it’s a very unpleasant situation. The client and vendor blame each other for the problems. Millions of dollars are spent. The business does not have their new application. The vendor is losing money on the project. Discussions about legal action take place.

Causes

There were several problems with this situation.

In the RFP, the client did not specify performance requirements. This lack of guidance allowed the vendor to avoid considering performance when creating the proposal.

The vendor was a solid, well-established company, with an excellent reputation for delivery and support. However, the product was new, with no installations in the client’s industry or any other industry. When evaluating the vendor proposals, the client did not recognize the importance of the fact that the references provided by the vendor (for other products) were irrelevant to the project they were proposing.

The vendor’s size, stability, and reputation were a good thing, of course, in that the vendor was motivated to deliver to the client’s satisfaction, and had the financial resources to invest in efforts to correct the problems.  A smaller, less reputable vendor may have simply walked away early on.

As delays continued over many months and millions were spent, the client never had any discussion regarding whether the project should be cancelled and alternative products evaluated.  This inability to face the failure of a product and project is common. Many clients, once they’ve invested a lot of money, time, and resources, do not admit defeat and start over.

Conclusion

The interests of the client and vendor were never aligned right from the start. The client was looking for a product to install and add value to their business process right away.

The vendor was looking for a successful installation of its new product, so they could use it as a reference when selling to other clients.

If the client had realized up front the differences in their goals, they may have been able to negotiate an approach that worked for both. Instead, both the client and vendor have failed to achieve their objectives.

Planning an IT project

Successful IT projects don’t happen by accident. Good project management is one of the keys to ensuring that the project is completed according to expectations.

In this article, let’s start with the assumption that the project is approved, and it is time to start building the project plan. This article outlines some items to consider when planning an IT project.

Define Objective and Results

First of all, it’s important to define the purpose of doing the project. Outline the business need the company is trying to fulfill, and how this project fits with long-term goals.

Describe the end results of the project including which software modules will be developed or implemented, which end users will be trained, which manuals will be completed.

Project Scope

Outline what exactly is within and outside the scope of this project. Remember to include items such as hardware set up, testing, documentation, and end user training.

In setting expectations for the project team and the end users, defining out-of-scope items is just as important as defining in-scope items.

Project Work Schedule

Figure out an overall plan for the project. For example, define which modules will be developed or implemented in what order. Decide whether training and implementation will be done by module, by region, or all at once for the whole company.

Break down the overall plan into smaller parts to create a work schedule. Outline which activities will be done at what time during the project. Determine which parts of the project depend on others being completed first and which can be done at the same time.

Set the Budget

Determine the budget for internal and external resources, software, hardware, travel, and accommodation costs. Include costs for publishing documentation and equipment needed for training of end users.

Based on the work schedule, determine how much money will be spent in each time period.

Resources

Identify what types of resources are needed to work on the project. Decide how many people who already work for the company can fill these project positions.

When using staff from inside the company, determine how their regular duties will get done while they are involved in the development or implementation project.  Be specific, and don’t accept assurances that the staff will be able to cope with their regular duties as well as their project responsibilities. Loss of internal resources who get pulled back to their regular jobs can be a serious problem in achieving the project objectives.

For project roles that cannot be filled by internal staff, determine where they will be found. They may be loaned from another division, hired as consultants, etc.

Determine the Completion Dates

Be realistic in setting the intermediate and final completion dates for the project. Find out when vacations are, so there are no surprises later and the plan can be laid out with the vacations built in. The project team members will be attending progress meetings and maintaining their part of status reports, so allow enough time for these elements of their work.

Add extra learning time to the schedule if team members are relatively inexperienced or if a new technology is being used.

Keeping the completion dates reasonable may be one of the most difficult parts of planning the project. There is frequently pressure from others (for example, upper management) who don’t know what is really involved in accomplishing the various milestones but want to set them anyway. Explain how the dates were derived and resist the demands for unreasonable dates.

Unmovable Deadlines

Sometimes there really are unmovable deadlines (for example, implementation of new tax policies). In these types of circumstances, do a draft of the schedule to determine what the project completion dates would be based on work to be done and resources. Then, if the completion date calculated is too late, determine what changes can be made to the plan in order to meet the deadline. “We’ll work harder” is not a reasonable solution. To correct a deadline problem, either add extra resources, or reduce scope. If you need to cut scope to meet the deadline, you can create a second phase of the project to complete the remaining work.

Assess the Risks

Identify potential sources of risk to the project. For example, if a new technology or new software product is being used, assess the impact on the project if the product doesn’t work as well as expected. Or, determine the risk and implication of losing a key member of the project team.

If any of these risks have a high likelihood and/or have a serious impact on ability to complete the project, find a way to reduce the risk if possible. For example, additional product testing early in the project could be scheduled. Cross training of key members of the project team may reduce the impact of losing one key person.

Contingency planning can also be used to mitigate risk. For example, if a vendor missing a delivery date would be a serious problem, find out if it would be possible to buy from another vendor or if the equipment can be rented temporarily.

Standards

Establish standards to be followed by team members during the project. For example, in a development project, it is important that programmers and testers know the programming, testing and documentation standards to be followed.

In addition, set the standards to be followed for creating end user documentation, tracking issues, and maintaining multiple versions of project documents. For example, is there a specific form or database to be used for logging issues?

Status and Coordination

Determine how the status of the project will be reported to the stakeholders. Some options include meetings, newsletters, and reports. Decide how the project steering committee will be kept informed of progress, how frequently the committee meetings will be held and who will attend.

Find out if there are other projects going on in the company at the same time or external projects (e.g. customer or supplier) that have to interact with the new software. Decide how the new project will be coordinated with the other projects. Options include wikis or other knowledge-sharing software, coordination meetings, and conference calls.

Change Control

Outline the procedure for making changes to the project while it is underway. Decide who will be responsible for gathering cost and benefit information, and who will be authorized to approve the change to the project.

Revise the Plan

Completion of the project plan is an iterative process. At any of the steps outlined, it may be necessary to re-work one or more previous steps. For example, perhaps staff will not be available internally and the deadline cannot be achieved. In that case, it will be necessary to reduce the scope of the project, adjust the deadlines or add external staff. Then, if external staff are being added, the budget will also have to be changed.

Approval of the Plan

Review the project plan with the steering committee. Obtain written approval from the steering committee for all aspects of the project plan.

Execution and Completion

The first step in good project management is a good project plan. Now that you know what to include in your plan for the project, I’ll cover the execution of the plan and completion of the project in the next article.

Copyright 2015 Debbie Gallagher