Decisions – Not Documents – Move ERP Implementations Forward

Information Alone Does Not Generate Value 

I grew up in a time when information was hard to obtain.  Generating information was seen as a valuable exercise because information was a scarce resource.  The first software development life cycle (SDLC) I learned was Waterfall.  One of the key focus areas for the Waterfall SDLC was documentation (i.e. information).  However, there is a limit regarding what value information can provide.  In our enthusiasm to create information we sometimes go to an extreme and generate so much information that it becomes a roadblock.  What we often forget is that the key purpose of gathering information is to make decisions!

There is a direct relationship between the speed of customer decisions and the speed of ERP implementations.   The faster a customer can make a decision results in a faster implementation cycle.  Naturally, customers want to make right decisions therefore the project team must gather the right information.  To gather the right information we first need to understand the key decisions that must be made as part of the ERP implementation.

Decision-Oriented Information Gathering

Before the project team begins gathering information they first should consider what key decisions the project must make.  The ERP implementation scope will determine both the information gathering scope and key decisions to be made.  Consider the following illustration:

Gathering information to support decisions

Decision-Oriented Information Gathering

Simply stated, the scope for an ERP implementation consists of the software features that will be deployed (product scope) and the project activities and audience for the deployment (project scope).  Once the implementation scope has been defined, the project team can better identify the information requirements.   Gathering the required information and presenting that information in the appropriate context will enable the customer to make both software configuration and fit/gap decisions.  

Utilize Best Practices to Drive Decisions

A best practice is a process, method, or approach that is considered the most effective at delivering a desired outcome.   A best practice is repeatable and has proven itself over a period of time.   For ERP implementations there are two areas of best practices that should be considered:

  1. Industry best practices
  2. Configuration best practices

Once the implementation scope has been clearly defined, the project team should leverage industry best practices to assist the customer in making decisions.  Providing these best practices up-front to the customer will streamline the information gathering process.  As the project team moves from gathering information to driving decisions on ERP configurations and Fit/Gap, configuration and gap decision best practices can be referenced to provide proven knowledge to key decision makers.   Having the right Implementation Partner can have a significant impact on effective information gathering and decision support.  An Implementation Partner may not know every single decision that the customer must make as part of their ERP implementation but they should be able to identify up-front the key decisions required based upon the scope. 

Consequences of Not Driving to Decisions

The ability to make informed decisions is fundamental to ERP implementation success.  I would like to encourage the two key players that impact the decision-making process for ERP projects:

Customers

We live in a society where we like to keep our options open.  Many say that keeping your options open will make one flexible to future opportunities.  Many customers have applied this concept to technology and business systems.  I have seen this philosophy trickle down into a customer’s decision-making approach for ERP implementations.  Customers desire to have a business solution that is both adaptable and flexible.  It is an understandable and legitimate requirement.  However, customers need to keep two things in mind:

  • Keeping your options open (i.e. not making decisions) will slow down the implementation project and increase your risk for failure.   
  • People, not technology, is the most flexible and adaptable component of a business solution.
Strengths of Business Solution

Business Solution Strengths

Implementation Partners

Implementation Partners should be able to provide industry and ERP configuration best practices to their customers.  These best practices should be formally documented and provided early in the implementation where they have the greatest benefit.  These documents will provide evidence that the Implementation Partner can provide a repeatable and reliable service.

Summary

As a project manager, I’ve observed where project team members focused more on producing information and focused less on producing decisions.     Producing information (i.e. documents) is far easier than driving decision(s).    There is a false perception that generating more information will result in more knowledge and enable customers to make better decisions.  Nothing is further from the truth.  Only when the right information is communicated in the right context then knowledge is created for making informed decisions.

IT to Business Alignment for ERP implementations

You’ve decided on the ERP software you need, the Business side has bought into it, and you’ve even picked your Implementation Partner. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure Business, IT and the Implementation Partner are all speaking the same language.

Increasing knowledge transfer and collaboration between business and IT

Driving IT to Business Alignment

First, we need to understand that Business, IT, and the Implementation Partner are coming from different perspectives.   Every party has a knowledge gap to address.  Business best understands their existing business model and the underlying success drivers.  The Implementation Partner understands the ERP software and has multiple years of implementation experience.  IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies.  Alignment is generated only when a common understand of the business model, ERP software, and technology capabilities are shared by all three parties.  When this alignment occurs there is effective communications and faster decision-making.  Decisions move implementations forward. 

Following is a recommended set of steps to develop a common understanding for effective collaboration:

  • Document existing business processes

It is an area that I see many ERP implementations lack.  The typical challenge I hear is “Why document my existing business processes if I know they are changing?”  Here are my reasons:

  1. Business users usually do not have a consistent understanding of their business model.   Going through the exercise of documenting business process will highlight these differences and drive deeper understanding.
  2. Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur.  How can you manage organizational change when you do not have a clear understanding of what’s changing?
  3. Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.

 

  • Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model.  The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level.   Following is a suggested approach for conducting this training:

Level Description Suggested Duration
Business Solution Provide an executive overview of the existing business processes, systems, and organizations that make up the existing business solution. 4 hours
Business Process Provide a work flow of business activities that result from a business event.  Key variations and exceptions should be noted. 2 hours for each business process
Business Activities grouped by Role Provide a “day in the life” experience for key roles that support the business solution. 1 hour for each role

 

  • Complete ERP software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your language it is important that Business and IT have an understanding of the ERP software and its language.  Effective communication is a two party effort.  Taking the required ERP training before the arrival of your Implementation Partner will enable you to more effectively work together.

  • Have the Implementation Partner conduct supplemental ERP software training

Education is an iterative process – you will never learn everything you need to know for supporting ERP  in one training class.  ERP vendors only provide foundational training.  I always say that the Implementation Partner completes ERP training for the customer.  Implementation Partners have hands-on experience with configuration and maintenance of ERP solutions. 

  • Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer.  Too often we create project documentation that focuses more on technology than business reasoning and justification.  There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without understanding why does it need to be done.  At the end of the day we build software to drive business results.

 Summary

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust.  Implementing ERP software is an opportunity to generate greater alignment by developing a common language for effective collaboration.  When alignment is achieved then decision-making is effective resulting in a greater opportunity for success.

From the book “Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations” by Brett Beaubouef.

When ERP methodologies go wrong

Webster defines a methodology as a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures.  Methodologies add tremendous value to the implementation team by providing a process to guide the team through the implementation.  Methodologies have inherent assumptions, risks, and constraints.  For an ERP implementation multiple methodologies are involved.

Methods, Disciplines required for ERP implementations

Disciplines for ERP projects

Now I believe that methodologies are not the issue; it’s how they are applied that is the issue.  Following are typical problems I’ve observed with applying a methodology to an ERP implementation:

  1. Try to use one methodology for all disciplines.
  2. Execute methodologies in silos.
  3. No taking into consideration the inherent advantages and challenges associated with a methodology.

With several methodologies for each discipline to choose from the question becomes “Which one should I choose?”  Following is a list of the key factors you should consider as part of your methodology selection.

 Factor: Size of the implementation

What is the size of the ERP implementation?  When considering size we need to look not only at the financial perspective (cost) but also from an organizational perspective (users impacted).

Factor: Personnel Capabilities

A methodology is only as good as the people using the methodology.  It is very important that the people on the project team (Business, internal IT, Implementation Partner) have the necessary abilities and training to successfully apply a selected methodology to an ERP implementation. 

Factor: Risk

What are the risk(s) associated with the ERP implementation?   How risk-tolerant is the customer?  Does the customer have experience with ERP implementations?  If there is a high level of risk associated with the ERP implementation then you may want to select a methodology that is more risk-adverse (ex.  iterative).

Factor: Business IT Relationship and Culture

The customer should perform a realistic assessment of the relationship between the business and the internal IT organization.  If the relationship does not foster effective collaboration or there is a known alignment challenge then an iterative approach should be considered.

Iterations provide a dramatic increase in feedback over sequential software development, thus providing much broader communication between customers/users, and developers.

Factor: Business Model Dynamic

The more dynamic a business model is the greater opportunity for evolving requirements.  A dynamic business model requires a method that is rapid and flexible.  Traditional approaches that focus on a reasonable stable set of requirements may not be the best choice for this environment.

Factor: Assumptions for a Methodology

As stated earlier every methodology is based upon an “environment”.  It is very important that you understand the basis for the methodology as well as determine the assumptions made.  Making an objective evaluation of the methodology will determine its advantages, challenges, and assumptions made. 

Summary

The first step of effectively using the required methodologies for an ERP implementation is first understanding the methodology integrations.

Methodology integrations for ERP projects

ERP Methods

 The second step is to consider the key environmental needs that the methodologies must support.  Implementation size, personnel capabilities, risks, and relationships are factors that will have a material impact on how successful a methodology can be applied to an ERP project.  In addition, Implementation Partners should be able to support multiple methodologies in order to provide the best approach for the customer‘s unique implementation.

Five key areas to consider when selecting ERP software

There are five key areas to consider when selecting ERP software:

(1) Functional Fit

How well does the ERP software fit with (a) current business requirements and (b) future business requirements?  Too often I see vendor responses and demonstrations spend too much time on “core” functionality and not enough time on the unique and strategic requirements of customers.  These are the requirements that generate a competitive advantage to customers.

(2) Technical Fit

Two key activities need to be performed: (1) internal technical assessment and (2) external technical assessment with each vendor.  The internal technical assessment consists of identifying the current state of the customer’s IT environment: in terms of hardware, software, FTEs, and skills.  The external technical assessment consists of identifying the technology requirements of the vendor’s ERP software in terms of hardware, software, FTEs, and skills.  You then perform a comparison (fit/gap) to identify the technical requirements for the customers to move to the vendor’s ERP solution.   Quantifying the technical gap is very important in calculating the financial fit.

(3) Organizational Fit

This area is typically overlooked and underestimated.  It is important to understand how the customer’s organization must change to effective support the new ERP solution.  Many customers know that they must change, however few understand how and the amount of change that is required. 

(4) Implementation Partner

This is by far the area that will have the greatest impact on your success with any ERP software.  You can select the ERP software with the best fit but if you cannot implement the ERP software then what is the point!  This area is so important you should have a separate selection process for the implementation partner (separate RFIs, RFP, Evaluation).   Following are the key questions you should address with potential implementation partners:

  • Strengths
  • Weaknesses
  • Revenue, # of consultants dedicated to ERP software vendor
  • Locations
  • Industry Focus
  • Target Customer Focus (Up-market, SMB)
  • Software Product Knowledge
  • Certifications (Software, Industry)
  • Type of Consulting Services (implementation, upgrade, training, process improvement, installation, technical services) – how well can they support the entire ERP lifecycle
  • Implementation References similar to you
  • Recent News
  • Thought Leadership (publications, presentations)
  • Partnership status with Vendor (# of years, level)
  • Vendor recommendation

  (5) Financial Fit

 What is the total cost of ownership across the expected lifecycle of the ERP solution – including installation, training, implementation, maintenance, upgrades, hardware, ERP software, 3rd part software, process improvements?  It’s important to set the expectation that the proposed gains will not be realized in the initial implementation but over the expected life of the ERP solution.   The end result of the financial fit is the business case.  As with any business case there will be assumptions, constraints, and estimation accuracy (ex. Order of Magnitude) so please ensure that you clearly specify this information along with the value proposition. 

ERP software selection is an important step in your goal of implementation a new business solution.  I hope that the information will assist you in being successful.

Key Project Management Strategies for ERP implementations

I had a colleague ask me what are the key project management strategies for successful ERP/COTS implementations. I laughed and told my friend that I’m still learning! My friend is an experienced, certified project manager (PMP) so I spared him the foundational best practices (approved project charter, executive support, risk management, communications, etc). These core best practices are well known and documented. I wanted to go to extra mile and provide advice that may not be well known or understood. Following are the key strategies that drive my project management approach for ERP/COTS implementations:

(1) FOCUS

Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who is doing what. Just as important to scope definition is to define constraints and assumptions. Example: for packaged software implementations (like ERP) I create scope statements with the following sections:

i. Packaged software features in scope (product scope)

ii. Packaged software features out of scope (product scope)

iii. Implementation activities and party responsible (project scope)

iv. Assumptions

v. Constraints

A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.

(2) KNOW THE BUSINESS

How can you lead a project to generate value for a business if you do not understand the business? You may be able to perform project control/admin but you will not be able to lead a project team in their efforts. Analyzing whether your project is generating business value is difficult if you do not understand what results drive real value.

(3) ENABLEMENT OVER CONTROL

Would you rather have one person (PM) focused on project scope or the entire project team (including your customer) guarding project scope? It’s been my experience that undetected scope creep starts outside of project meetings – ex. water cooler discussions, off topic discussions. Addressing project scope changes in a change control process is reactive – you already wasted time/effort writing up the potential change. I educate the entire project team on the project management basics of scope, schedule, and resources. I also make the scope easy to understand so that every individual on the project team understands scope boundaries. Individual team members are your first line of defense – the project manager cannot be everywhere at once.

Governance by itself does guarantee business value – a project manager has to do more than just control.

(4) BE RESULTS-ORIENTED

Focus on the right results: On-time, On-Budget are good project metrics but it does not guarantee that business value is generated. Decisions drive projects forward – not action items. As your project evolves your meetings should start generating more decisions and less action items. Running software is a good beginning but is not the end of generating business value.

(5) CREATE AND PROMOTE TRUST

Like the old adage says “Trust but verify!” The only thing I would add to this is to build in an iterative approach so that verification is frequent versus a one-time event. Waiting to develop trust during the Testing phase (i.e. validation) is not a smart risk to take.

(6) BE ADAPTABLE

Do not confuse a plan with execution. A project plan is a simplified model of reality based upon many factors whose definition will further elaborate during the project. Change will occur – be flexible and adaptable to reach the desired goals. A process (methodology) supports achieving the desired results but the methodology is not more important than achieving the desired business results.

Effective project management must be more than coordination and control – it must include enablement and leadership. Always keep the end goal in sight and on the minds of your project team.

Follow

Get every new post delivered to your Inbox.

Join 4,138 other followers

%d bloggers like this: