The Biggest Challenge of Postmodern ERP - Cloud Integrations

Gartner originally coined the term “enterprise resource planning” (ERP) back in 1990 to describe a new breed of integrated software solutions. These solutions included modules for Material Requirements Planning (MRP), Manufacturer Resource Planning (MRP II), Financials, Human Resources (HR) and Customer Relationship Management (CRM).

During the 1990s and 2000s, these single monolithic ERP solutions became an essential part of most corporate IT strategies. But by the mid-2000s, such ERP solutions started to get a bad reputation. The very high price tag, the relative inflexibility of an integrated solution and the droves of ERP implementation failures that made headlines in both the tech and business world clearly showed the shortcomings of this strategy. It became hip to proclaim that “ERP is dead” or “the end is near”. 

Companies started implementing best-of-breed applications to replace individual modules within larger ERP solutions. For example, using Salesforce instead of the CRM module bundled with their ERP solution, or Workday to replace the HR module. Others ditched their ERP solution altogether and started using only best-of-breed applications and started connecting them with each other. 

Gartner coined the term “postmodern ERP” in 2014 to describe this new ERP strategy.

Postmodern ERP is a technology strategy that automates and links administrative and operational business capabilities (such as finance, HR, purchasing, manufacturing and distribution) with appropriate levels of integration that balance the benefits of vendor-delivered integration against business flexibility and agility. 

To put it another way, a traditional ERP solution is like the new car you buy every 10 years. A postmodern ERP solution is like owning the same car indefinitely, but with various components that can “easily” be changed out as needed.

Around the same time that postmodern ERP strategy became hip, we see the cloud strategy of both vendors and clients taking off. This means many of these best-of-breed applications are consumed in a SaaS model with all its advantages and disadvantages.

Whilst this all sounds like great ideas it gives us one very big challenge to solve; cloud integrations.

Why Cloud Integrations Are so Difficult

Cloud integration means integrating data used by disparate systems, between or within public or private clouds, or between cloud-based and on-premise systems. The goal is to create unified data stores that can be accessed efficiently and transparently by all relevant users and applications.

There are mature tools for data integration within public cloud providers or private cloud platforms, for example within AWS, Azure or an OpenStack data center. The main challenge begins when organizations need to integrate multiple public clouds, set up hybrid cloud environments, integrate legacy on-premise systems with cloud workloads, or lift and shift legacy workloads into the cloud.

You can increase flexibility and agility, or reduce complexity, but you can’t do both. Despite the rigid nature of traditional ERP solutions, they solved some key issues, including the need for consistency and integrity of data and processes. 

Let’s have a look at some aspects you have to deal with when implementing a postmodern ERP solution. 

Release Management

Each SaaS application that is part of your postmodern ERP solution will have a different maintenance and upgrade cycle. This means that you will have continuous change in parts of your end-to-end solution without you being able to stop this. This means you have to have a solid plan in place for regression testing. Does the end-to-end solution still work after each upgrade? Do your integrations still work? Are the data semantics still the same?

Environment Management

Tied to the previous point is environment management. In order to do development and testing you will need to have a development and test environment. This works a little differently for each SaaS application that is part of your postmodern ERP solution. And just as the production environment, they will all have different maintenance and update cycles, meaning it will be very difficult to have a stable environment for long.

Backup and Disaster Recovery

It is safe to assume that each SaaS application that is part of your postmodern ERP solution will have a solid backup and disaster recovery strategy in place. But they all will be different. Do you understand the impact of such an event on your integrations? On your data integrity? Did you test this?   

Firewalls

In hybrid cloud environments, when moving data between the cloud and on-premise systems, opening the firewall is a necessity that most network administrators anxiously resist. You will have to carefully evaluate the requirements for data integration flows that cross the firewall to find the solution that minimizes the exposure of enterprise systems and data.

Network Latency

Cloud environments are often preferred to on-premises because of their scalability: you can easily increase or decrease your usage of compute and storage resources in just a few minutes. But scaling your cloud environment will have limited effect if your network latency is too high, which puts a firm cap on the data integration workloads you can run.

Data Transfers

Moving data between clouds, and between cloud and on-premise systems, can be time-consuming and error-prone, or even unfeasible in some cases, depending on the data volumes and the required data transfer frequency. Cloud data integration won’t work without solid strategies to transfer data in a timely manner. There is a huge difference between 10 messages a second and a 100 -- trust me.

Data Integrity

How are you monitoring all points of integration and logging the data on the move? Depending on the method used, the process of monitoring and capturing data changes on source systems can increase the load on the source system causing slowdowns in operational systems.

Data Conversion

In traditional data integration projects, complex Extract Transform Load (ETL) workflows were set up to clean data and transform it into the precise format needed by target systems. Many SaaS applications work with unstructured data or provide a flexible data model for structured data. However, they still need data to be cleaned, treated and converted into the desired format. Integration strategies must consider how ETL can be performed without slowing down the integration or adding a lot of complexity.

Data Synchronisation

SaaS applications are often architected with scalability or performance in mind, not around data integration. For example, in a system that rapidly scales up or down, with data stored on dozens or hundreds of cloud instances, it may be challenging to synchronise with external systems.

Standardization

There is no standard approach or protocol for integrating data between SaaS applications, not to mention cloud and on-premise systems. Each cloud platform, service or resource tends to have different data schemas and formats. Data connectors or adaptors need to be constantly updated, as new cloud services are introduced or as applications are updated or modified.

Security and Compliance

Consider the security requirements and industry standards applicable to each of your datasets. Both your integration platform and all connected applications need to fulfil those requirements, both for one-time data transfers and ongoing data synchronisation.

In a nutshell: You can increase flexibility and agility, or reduce complexity, but you can’t do both. 

Read more…

Create a Lighthouse to Drive Your Transformation

I’m a firm believer in transformation through delivery. In my experience real change cannot be implemented without a vehicle that is used to drive it through the organisation and crash through existing barriers. 

Transformation is far more than just deploying new technologies for the sake of it. A genuine competitive advantage can only be gained through the combination of an organization’s culture, its strategic choices and way of operating. 

It’s about continuously enabling new and leaner operating models underpinned by flexible business processes, connected platforms, analytics and collaboration capabilities that enhance efficiency and effectiveness. 

It’s about searching, identifying and developing new technology supported business models and, above all, ensuring that customers and employees are at the center of whatever a company does.

A good way to start transformation through delivery is by defining a so-called lighthouse project early on in the process and letting your best people make it a success. A lighthouse project is a short-term, well defined, measurable project that serves as a model — or a “lighthouse” — for other similar projects within the broader transformation initiative.

This technical delivery project will show new ways of working and doing business combined with the use of technology and will help to identify organizational challenges that hinder you to do the same in the rest of your organization.

The 4 key attributes of such a lighthouse project are:

> It has high business value and visibility so it is less likely to be cancelled. A lighthouse project doesn’t need to directly benefit everyone in your organisation. But its value should be something that everyone in the organisation can appreciate and understand. It should have obvious results, such as “we have reduced the hardware purchasing budget by 70 percent” or “we have managed to increase our application uptime from 95 percent to 99.9 percent.”

> It has clear metrics. You’ll notice that the results mentioned above involve hard numbers. Collecting quantifiable data about your lighthouse project is important in order to make the demonstration of value as clear as possible.

> It touches multiple business units and silos to enable the identification of barriers and influence change.

> It has a hard deadline in the near future to focus the business and delivery team to provide pressure to break down barriers. You don’t want to wait years for your lighthouse project to be complete. Choose a project that can be implemented within a reasonable period of time—a year at most. Of course, you should be careful to balance time-to-completion with sophistication; don’t make the project too simple in order to make it faster to complete.

In a nutshell: A lighthouse project is the key to transformation because it shows everyone in your organisation what they can achieve by leveraging new ways of working, new ways of thinking, and using new technologies.

Read more…

Going Live Too Early Can Be Worse as Going Late

A significant part of my engagements involves post-mortems on large, failed technology projects. And out of professional interest, I study public project failures and write case studies about them. 

Based on my experience and studies, most of these disasters could have been prevented (or at least anticipated) based on the project’s available information.

While project teams are rarely surprised by the outcomes, sponsoring executives are often unaware of the impending tragedy until it unfolds – and sometimes at the expense of their careers.

One executive decision in particular can move your project from challenged to a full blown disaster. And that is going live too early with a business-critical system.

A well-known characteristic of large projects is that once “go-live” dates are planned and communicated it is hard to change them. There are multiple reasons for this. For example:

> Highly visible or public commitments may be difficult or embarrassing to come back from.

> Breaking contractual commitments may have significant financial consequences.

> Individual and company reputations may be damaged by not meeting a promised date.

> Significant costs may occur to continue the current solution beyond the cutover date.  These costs can include renewing expensive leases, licenses, or maintenance for equipment, software, or real estate.

> People currently working on the project may be needed elsewhere, creating a resource problem that would impact operations and other projects if the current efforts were extended.

Most of you have experienced such timeline pressures; they are real, and I do not intend to underplay them. But, as real and daunting as these pressures can be, they have to be balanced with the consequences that a premature go-live can have. 

You must consider both scenarios in your decision-making.

Estimating implementation timelines is an imprecise art, not a science. It is subject to error as well as risk and uncertainty. As your information systems become increasingly interconnected and sophisticated, coordinating changes takes time, patience, and hard work.

Systems often have substantial elements of organizational change that must be addressed before a go-live. If your new or changed system requires a meaningful change in how people do their work, significant time may be required to understand the implications of the change, modify processes, as well as user enablement through training and support. Changes in the processes may create downstream effects into other parts of your organization that must also be understood and dealt with.

Replacing all, or part of, an existing system can also be complicated by differences in how data is captured and stored between the old and new systems. The efforts and impact of stopping an existing system, converting and loading data, and restarting the new system are easy – and devastating – to underestimate.

Unfortunately, what happens often in large projects is that all these things are ignored as soon as the first milestones are missed. It suddenly is all about making the deadline, and not about doing the necessary work and mitigating these risks.

Below are a few prominent examples of what can happen if you go live too early:

> Case Study 13: Vodafone's £59 Million Customer Relationship Disaster

> Case Study 9: The Payroll System That Cost Queensland Health AU$1.25 Billion

> Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed Sap Implementation 

> Case Study 3: How a Screwed-Up SAP Implementation Almost Brought Down National Grid

> Case Study 2: The Epic Meltdown of TSB Bank

So before you find yourself pushing relentlessly for the go-live date, I encourage you to consider the following eight questions about your team’s readiness for go-live.

1) Is your system ready?

Has it been thoroughly tested? Is there an honest assessment of the quantity and priority of its known defects? Have business users weighed in with an informed opinion about the acceptability or the feasibility of workarounds for the known issues?

2) Are your upstream and downstream systems ready?

Have interfaces been tested fully? Are instruments in place to monitor traffic and identify problems? What would be the business impact to your system and your surrounding systems if there is a significant disruption of data flow or a significant error in the data? What are the consequences of data delays? Can the teams operating your upstream and downstream systems support your cutover date?

3) Are your users ready?

Have the implications of changes been thoroughly analyzed and communicated? Are users ready for the changes to their processes? Does the organization understand the secondary effects of these changes on downstream processes? Are user staff sufficiently trained on the new system? Will there be enough staff available during cutover to deal with the learning curve of the new system and processes and work through unforeseen issues?

4) Is your technology infrastructure ready?

Are you confident that there is sufficient processing, network, and storage capacity to support the new system? Are your help desk and operations people trained and ready?

5) Is there a go-live playbook or schedule?

Did you provide details of the steps required to stop the current systems, migrate data, convert interfaces, and begin processing with the new system? Are roles and responsibilities during cutover clear? Are the timings of the cutover schedule reasonable? Has there been a successful dry run?

6) How and when will you know that the cutover was successful?

Success here would mean not just all aspects of the technology, but also the impacts on the processes and the people who interact with the system. Has monitoring been established to provide early warning of problems?

7) What is the impact of a failed implementation?

Have you considered the failure modes of the new system and its impact to your business and that of your partners? Are there feasible workaround processes in place should cutover disruption be extended?

8) Is there a feasible fallback plan?

Can the cutover be aborted if significant issues are discovered? How long can the new system be in place before the cost and complexity of backing out of the system will be preventing this? What is the “point of no return” on the implementation? Is the fallback plan as detailed as the go-live plan? Has it been tested?

Before succumbing to the inertia and inevitability of a committed date, an honest assessment must determine whether the system and organization in which they operate are ready for the transition. 

So instead of focusing on the list of reasons why a system “must” go live on the selected date, have an honest conversation with executive stakeholders about the true status of the initiative and the potential consequences of a failed implementation.

In a nutshell: Going live on time should not be the default. Going live when the system and organization are demonstrably ready should be the goal.

Read more…

Another Great Leading Indicator for Future Trouble - Issue Resolution Time

I have a very simple metric for determining the health of a project or an organization: the age of issues. 

Issues are like fish; when they get old, they stink. 

A sure sign of a lack of leadership and upcoming trouble is old issues or issues that take longer than necessary to resolve. 

Issues are obstacles that get in the way of execution. It is the project manager’s role to resolve and eliminate these issues as quickly as possible regardless of the owner or the cause. 

If the project owner cannot solve it (or doesn’t try) it is up to the executive sponsor.

If an issue stands in the way of executing project objectives or makes it difficult for project managers to perform, it’s your responsibility as an executive sponsor to resolve it. 

If the project manager is the problem, it is also your responsibility to solve this.

Fix the root causes of problems and fix them early. 

What you want to avoid is a form of collective project amnesia where issues come up and never get resolved. 

Issues have a funny way of resurfacing when they don’t get resolved.

In a nutshell: Old issues and/or issues that take too long to resolve are an indicator of poor leadership and a great leading indicator for trouble in the future.

Read more…

A Great Leading Indicator for Future Trouble - Missing Milestones

I have done quite a number of inflight reviews and post-mortems of troubled and failed large system implementation projects. 

One pattern that emerges very clearly is the one of missing milestones whilst keeping the go-live date the same. 

It rarely ends well.

I see it again and again. Multiple important milestones are missed. Sometimes by months. And the ones that are marked as completed have their original scope reduced.

For example system integration tests (SIT) without all interfaces being completed and no production like data.

Or user acceptance testing (UAT) with systems that are not ready or contain so many bugs that end-to-end testing is not possible.

Astonishing is that in most cases both the project sponsor and project manager seem to be convinced all is “green” and it will work out until the project folds like a house of cards.

When you look at a typical large system implementation project it is still largely implemented like a waterfall. This includes ERP systems, CRM systems, Core Banking, etc. 

And this has not changed with the rise of software as a service (SaaS) offerings like Salesforce, SAP S/4HANA, Workday, etc.

Yes, the design and build phases are now iterative, but at a certain point your full solution needs to be tested end-to-end. This means one or more SIT phases and an UAT phase that includes all upstream and downstream systems and processes. 

You also need time to fix all the findings of your testing, and to do re-testing. If you are lucky one cycle is enough. Usually it is not.

You also need to train all your users and your support teams on the new solution and processes. Ideally on a solution that actually works. 

And when you are ready to go, you have a cutover phase from your old solution to your new solution. 

So yes, you design and build iteratively, but the rest is still shaped like a waterfall.

And this means that if you miss important milestones and you don’t change the go-live date you will steal time from the very important phases that come at the end of such a project. 

Starting these late phases without having completed the previous phase just does not make sense and will drive your test team and end users crazy.

Missing milestones does not mean your project team is doing a bad job, but they obviously underestimated the time it takes to do certain things.

Chances are this is a pattern that is repeated for the later phases of the project. 

So you will probably need more time for these phases as planned. Not less. 

In my experience there are only two probable outcomes of such projects:

1) They never go live

2) They go live too early 

The latter can be even worse as the first. 

See here and here for some prominent examples from multi-million projects that never went live, and here and here for projects that went live too early. 

You will find many more examples among my project failure case studies.

In a nutshell: missing milestones and not changing your go-live date is a great leading indicator for trouble in the future.

Read more…

Jobs to Be Done for CxOs in the Project Economy

We all have heard about the disruptions that are impacting our society and the business world: robotics, machine learning, artificial intelligence, shared economy, blockchain, big data, augmented reality, and so on. 

But, there is one disruption affecting our world that media and academia seem to have completely missed.

The Project Economy

For decades organizations have been run and structured in a very similar way: hierarchical; in which power, budgets and resources are divided over departments, the so-called “silos”. 

Management and management theory was focused on how to run and optimize the business best in an ever during quest for efficiency. Projects were an addition, but hardly ever a priority.

Today, due to the speed of change witnessed in the past decade, this model has become more and more obsolete. 

For many organizations the day-to-day running of a business will soon be carried out through automation and robots – and is already done so in many instances. Projects have become an essential part of any organization.

My prediction is that in the upcoming years, senior leaders and executives will spend much (maybe even most) of their time selecting, prioritizing and overseeing the execution of projects.

Ultimately, projects deliver value to stakeholders by solving their challenges, delivering products and aligning projects to an organization’s value streams. If done right, these initiatives also deliver financial and/or societal value.

This phenomenon is known as “The Project Economy”.

Jobs to Be Done

Taking the above into account there are a number of jobs that a CxO (like Chief Executive Officer, Chief Operations Officer, Chief Financial Officer, Chief Technology Officer, Chief Information Officer, etc.) will need to be able to do well when leading organizations in this project economy. 

Below you will find the (in my humble opinion) ten most critical jobs to be done for CxOs. 

1) Being an effective Project Sponsor.

2) Being an effective Steering Committee member.

3) Selecting the right Project / Program Manager for your initiatives.

4) Implementing change.

5) Executing a strategy with projects.

6) Selecting the right projects.

7) Prioritizing projects.

8) Killing a project.

9) Reviewing a project.

10) Recovering a project.

In a nutshell: In the upcoming years, senior leaders and executives will spend much (maybe even most) of their time selecting, prioritizing and overseeing the execution of projects.

Read more…

Can a Task Force Rescue Your Failing Project?

We’ve all witnessed projects in trouble—the ones that required a quick and firm intervention in need of help from a task force to bring it back on track.

No executive wants to be in such a difficult situation, especially not with one of his or her own projects.

But how do we, as the executive sponsor, handle saving a troubled project? Can it be as simple as mandating a task force?

Let’s start with exploring what a project task force is and when it could be useful. 

A project task force starts with a mandate given by the organization’s project sponsor or senior leadership to an experienced leader with the goal of finding the best option for resolving a particular problem in a very short amount of time.

A task force team is a small group, usually four to twelve people, that brings together a specific set of skills and experience related to the problem at hand.

A task force is a useful management mechanism that should be only used in exceptional situations. It generally requires disrupting other project activities and deploying the best people to solve the problem under possibly highly stressful and energy-depleting conditions.

So how do you handle this? 

I have been part of several task forces and have led a few as well. I have had both good and bad experiences. In order for task forces to be effective, you will need:

A Clear Mandate: It needs to be communicated to all stakeholders that the project is in task force mode, as well as who is leading the task force (see next point). You will need your stakeholder’s help in receiving quick turnaround times on information requests and decisions. You will need the best people in your organization for your task force team, so people need to understand it is urgent and important. 

An Experienced Leader: It can either be a senior project manager or a leader experienced with crises situations. Single leadership is the key to getting the job done! The last thing you would want is having two or more leaders debating how to drive the task force; one person has to call the shots.

An Expert Team: The task force leader will need to quickly assemble an expert team, formed with the best people who have the required field expertise to quickly understand and resolve the problem. The smaller the team, the easier it is for the task force leader to motivate and steer the team towards finding the right solution.

Laser Focus: The particular problem the task force is working on has to be clearly defined and known to the entire task force team. The objectives they will be working on also have to be clear to everyone involved. Several other project issues may come up along the way, thus, to be effective, the task force must remain focused on the specific problem.

Executive Support: At times, the reason a task force is needed in the first place is due to internal politics and resistance to change. One of the worst things that can happen to a task force is that they have no backing from their leadership to cut through this. 

Expectation Management: Many times, a task force can improve the status quo significantly, but you should not expect miracles. Further, you should strive to not communicate your desire for miracles upfront. Make clear to everybody that the goal of the task force is to find the best possible solution under the given circumstances.

A Short Time-Frame: Given the urgency and the high level of the task force team’s energy, they are only effective if conducted in a short time frame (a matter of days, or a few weeks). If efforts go on for longer, it is likely not a task force, as the energy and effectiveness will lower over time.

Simple Logistics: Due to the intensity and possible stressfulness of the situation, task forces require an isolated project space—or war room. This space needs whiteboards to facilitate brainstorming and for capturing the results of the task force (notes, action items, assumptions, decisions, solutions, etc.). Yes, we all learned during COVID-19 to cope with this remotely, and yes, for international teams, it is not always feasible either. But trust me, in a time of crisis, it really works better this way.

Solution Options: The task force’s outcome should include one or more options that lead to a solution to the problem, including a recommendation for the best option. This option, even if it is technically the best that the expert team can recommend, might not satisfy the risk appetite of the person or organization that has mandated the task force. Therefore, every option should also provide the related pros and cons.

Qualified Assumptions: Beware of unqualified assumptions. If the identified options are building upon assumptions that are not fully validated, highlight the risks or needs for confirmation before making a final decision.

A Clear Ending: To end the task force, its leader and the expert team will have to reduce the complexity and summarize the outcome of their work (options with pros and cons, along with assumptions and their risks or opportunities). Ultimately, the task force leader will communicate the outcome, confirm the decided solution, and conclude the mandate of the task force.

If set up and executed properly, a task force can be an effective tool to resolve crises situations in projects. 

Typically, these situations occur relatively late in the project when nothing else has worked. Interestingly, they usually work relatively well, as they are given the highest priority. 

Due to their ability to solve such issues, task force leaders are often celebrated as heroes. 

But task force teams work only at the expense of all other projects! All other projects endure even more pressure and are good candidates for further task force teams. Thus, they should be deployed wisely.

In a nutshell: A task force can be an effective tool to rescue failing projects if set up and executed properly.

Read more…