Imagine an ERP solution that drastically reduces manual entry by 90%! The remaining exception transactions can be created via Natural Language Processing (NLP) or user confirmation of AI/Machine Language (AI/ML) recommendations. All supplier invoices are electronic. Moreover, bank reconciliations are performed near real-time via blockchain. Supply chains have the ability and capacity to process an order request, gather the commodity from the location, and deliver the unit to the desired delivery point without human intervention1. Further, sub-ledger reconciliations are eliminated because there is no more need for sub-ledgers. Reports become an obsolete way to communicate information. ERP Cloud updates, testing and feature deployments occur without heavy reliance on third-party consultants. If interested, please allow me to share my vision of autonomous ERP.
What is Autonomous ERP?
While there is no agreed-upon standard definition, following is my characterization of autonomous ERP is based on research and my ERP delivery experience.
Reducing and/or eliminating data entry is strategic for autonomous ERP. Robotic process automation (RPA) is a short-term fix to automate data entry, but the goal is to eliminate the need for data entry altogether! IoTs must expand and interconnect, facilitating machine-to-machine communications. Sensors become self-sustaining 2.
It is a reality that ERP Cloud is the delivery model of the future, since its economic and technology-scalable advantages surpass those of any other ERP delivery models. However, if you do not trust your ERP Cloud service, you will not be able to evolve with it. The trustworthiness of ERP Cloud services is only proven through repeatability, reliability, and capability in achieving desired business results. Merely having “leading” features and technologies does not an autonomous ERP solution make.
Just as OLAP and HTAP/In-Memory DBMSs are a necessity for EPM performance today, these are in fact not a requirement in a solution whose performance is exponential compared to today’s standards.
Many existing constructs and ERP designs are still based on the current limitations of manual effort and technology. As Brian Sommer stated:
“Businesses have to be ready to move away from monthly, aggregated data to more precise data, costs and insights.”7
Trust and the ability to rollback AI/ML-initiated transactions will be the key drivers in ERP autonomy adoption.
Five Levels of ERP Autonomy
Since there is no standard definition for ERP autonomy, there is no clear definition for its different maturity levels either. I submit the following model for your consideration:
This model is based upon the Department of Transportation (DoT) definition model for autonomous driving.
Level 1 represents siloed feature ML capabilities that represent a “proof of concept” approach from ERP Cloud vendors.
Quick adoption is possible only with a rollback feature. This capability will enhance user adoption and reliance. At this point, over 80% of transactions are digital (invoices, payments, customer interaction) (Level 3)
As the ERP solution learns (digital experience) and business users trust the ERP AI/ML recommendations and results, customers will have their organizations focus less on transaction processing and more on decision-making activities on a trial basis. (Level 4)
At level 5, Business users “think outside the box” to ensure customer value and the ERP Cloud service performs the necessary tasks. The human brain, with its superior neural network, is fully leveraged.
Why do we need Autonomous ERP?
Given Moore’s law on technology innovation, I anticipate that autonomous ERP will happen within my lifetime. Autonomous ERP frees the human mind from the tedious and mundane. As millennials and Gen Z-ers expand their numbers and influence in the global workforce, there will be a greater demand for human creativity within every job role. Today, human creativity is limited by technology performance barriers which require humans to support business transaction processing. However, small strides are being made. Consider the following advancements:
Although separate data models (e.g., OLAP) are a requirement for EPM performance, they are not a requirement in a solution whose performance is exponential according to today’s standards. Making ERP data and analytic structures “in memory” is a step in the right direction. However, the effort required for autonomous ERP will require more than shrinking the von Neumann model.
Just as compiled code was a necessity for application performance, so is the sub-ledger to the accounting model. The sub-ledger is a necessary construct based upon established constraints and limitations.
From my perspective, I see technology as finally catching up with business and not technology changing business. Technology greatly enables the human brain to think and express thoughts outside physical boundaries whereas AI/ML and Deep Learning are limited by the data captured. In fact, human thought is not bound by such a constraint and is, in my humble opinion, the most under-utilized resource with the greatest potential for creating business value. Consider the following illustration below regarding a specific use case for autonomous ERP.
Let’s look at the example of a day in the autonomous ERP world. Jill is the controller for a mid-sized company. As Jill prepares for work, she gets the “morning report” with the following:
Tasks to perform that day as well as tasks that are past due.
Overall performance of her organization versus the plan.
Business exceptions that must be addressed manually.
Recommendations to address current business activities and exceptions.
The “morning report” is available via all interaction channels (UI, Voice, UI plus Voice, etc.)
Subsequently, Jill provides verbal commands based upon the morning report. The autonomous ERP Cloud service executes transactions based upon Jill’s decisions. Next, Jill focuses on the continuous accounting business process to review scheduled activities and provide guidance as needed. The third step of Jill’s day is to review recommendations and approve the exceptions to the standard business process. Now with the basics addressed, Jill can focus on improving the existing business process and prepare for emerging demands. Scenario analysis with business impact scoring and Jill’s input (most important) enables autonomous ERP to make better decisions. Finally, the autonomous ERP solution increases Jill’s productivity by implementing “quick win” capabilities and guides Jill and her team through the deployment.
Autonomous ERP, Intelligence ERP or “plug-in-your-name-here” ERP sounds tempting. However, there are four areas that you should investigate and evaluate for an ERP vendor’s strategy regarding autonomous ERP.
Technologies, like business functional activities, can be siloed and experience the same limitations without having deep integrations between technologies.
Without global standardization for blockchains, IoT, and business process models, the most practical approach would be a single vendor solution.
Constantly worrying, watching, or fixing basic business transactions within your ERP cloud service will have a negative impact on the future adoption of higher-level ERP functionality.
Now, allow me to switch gears to discuss deployment considerations for autonomous ERP.
In addition to the above considerations, a strategic step to prepare for autonomous ERP is to promote and, dare I say, even demand automation across your value network (customers, suppliers, and employees). The best way to ensure that all business transactions are electronic is to do it at the source! Optical Character Recognition (OCR), like RPA, is a gap technology used to bridge the manual and electronic worlds. Additionally, this automation can reduce operational costs. However, scanning still requires manual effort on your part, is slower, and more error-prone than having a fully automated flow. Any manual efforts supporting business transactions are not flexible and are typically costly to adapt and scale. Further, removing manual steps will improve data quality, which is a core requirement for any dependable AI/ML capabilities.
A misconception within the ERP industry concerns the role that AI/ML plays in generating revenue. AI/ML identifies possible opportunities, but it will be your people who execute to realize the wins. After all, technology is simply an enabler! Admittedly, people have the greater capacity for creative thinking and generating additional revenue, but you need to give your people the time and information for creative expression by delegating the basic business tasks to autonomous ERP.
Dream with me a little. ERP user access is natural and consistent across all channels. There is no longer a need for sub-ledger reconciliations since journal entries are calculated and booked in real time. Accounting closure is done at the transaction level, supporting instantaneous pro forma financial reporting. Employees manage their own career paths and job scenarios. In addition, customers see your company as a trusted advisor and not a vendor. Business users spend most of their efforts on processing exceptions, making decisions based on recommendations and performing what-if scenarios with an impact analysis on shareholder value, customer experience, and regulatory compliance. Is it possible? Yes. Will it require discipline across multiple domains? Yes. Will we have to think outside of our current work experiences? Yes. Is it easy? No. Consider the following:
Until there is global standardization regarding emerging technologies (e.g., Blockchain) and business process models, your best bet is to find a single vendor that can fulfill as much autonomous ERP vision as possible, and provides repeatable, reliable cloud services to support an enterprise solution.
In short, compared with AI/ML, the human brain is still superior and cost-effective when it comes to creative thinking. Today, your company’s “brainpower” is limited to organizational silos and dedicated jobs. Autonomous ERP has the potential of harnessing this vast, untapped resource across all business processes via trusted, automated tactical business decisions.
There are not many methods on how to maximize ERP utilization. There are approaches that do a commendable effort in identifying some of the factors that influence ERP utilization. What is lacking are predictability, repeatability and harmony across the key components of a business solution. In my 25 years of ERP consulting experience, I have never encountered a single customer that utilized over 60% of the ERP software. Given the lack of utilization and the money needed for cloud ERP implementations, I am convinced this is a problem that finally must be solved! We are in the second generation of ERP software and the only advancement that we in the ERP implementation arena have made is to retract our initial recommendation of customizing ERP for greater customer value.
The purpose of this article is to provide an overview of my theory on predicting ERP utilization. The scope of this article will focus on the cloud ERP deployment model. I have yet to complete the rigors of the scientific method to verify my theory. However, I would like to share my concepts with you and partner with you in growing the collective knowledge.
ERP Utilization requires all components of a business solution
First we need to revisit the concept of a business solution, the key components, their relationship, and influence on ERP utilization.
Just as technology has a part to play in ERP implementation success, business process maturity and the organization’s ability to change have a greater impact on ERP utilization. To elaborate on this thesis I will make use of two models:
I find that Organizational Change Management (OCM) is more of a project-based effort to enable an organization to meet a specific event. This approach works very well with an on-premise ERP solution where upgrades are measured in years. However, in the more dynamic Cloud ERP solution model, change is more rapid. ERP cloud updates and upgrades happen in months, not years. What I really like about OCC is the greater focus of providing the organization with the skills and flexibility to handle known and unknown changes.
OCC is an emerging model, thus there is limited content regarding how to assess and measure OCC for an organization. There for 4 key attributes for defining OCC levels (Saylor Academy, 2012):
It refers to how much front-line workers trust middle managers and senior executives to watch out for their interests.
Focuses on getting things done across organizational units and functional areas of expertise. Fisher and Sharp (2004).
Systemic knowledge is the degree to which members of an organization understand and are focused on the overall organizational system.
Change-capable organizations balance accountability with innovation. If the organization overemphasizes accountability, innovation suffers. And if innovation is the sole focus, accountability is ignored.
Given the above definitions, I have created a level definition to support my ERP utilization prediction model.
ERP Utilization Model
With all that said, consider the following conceptual model:
I propose a multivariate linear regression relationship between business process maturity, organizational capacity model for change with potential ERP utilization. This simplified model is based on the following assumptions:
A set of ERP features require a certain level of organizational and business process maturity for a successful experience. For additional information, see my article on Business Leads and Technology Supports.
Based upon the CMMI level and OCC for the customer, we can infer the ERP features required for maximum ERP effectiveness.
OCC has a direct influence on effective ERP utilization.
Software changes will happen more rapidly in an ERP Cloud delivery model versus a tradition ERP On-Premise model. Therefore, OCC must become an ongoing competency (versus a one-time effort) for long-term ERP success.
“It is generally not fruitful to impose a very sophisticated process on an organization whose maturity is low. The maturity of an organization not only depends on the skill sets of the individuals, but also on the chemistry of the team.” (Alexia Leon, 2012)
Based on the above model, I conclude that customer enablement must be an ongoing exercise that runs in parallel or even precedes ERP automation.
Model versus Reality
I consider myself more of a pragmatist than a theorist. Models are great to elaborate upon concept(s) for discussion and argument. However, conceptual models are limited in the value they provide to customers if there is no method to align reality (i.e., “as is”) with the optimal path. Consider the following illustration:
Key Points and Observations:
In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.
In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).
To minimize ERP Total Cost of Ownership (TCO) and eliminate cost constraints, ERP Cloud vendors should provide customers with the ability to increase ERP utilization without heavily relying on consulting services.
As we continue with the model elaboration, we find that there are regions that are not practical for a given CMMI and OCC values. Consider the following:
Key Points and Observations:
Circles represent a subset of possible values given that the scenario occurrence is highly improbable. For example, an organization with a CMMI level 1 maturity cannot expect to utilize 100% of the features available for a Cloud ERP service.
The permutations of CMMI and OCC levels indicate a linear relationship for targeted ERP utilization.
What Role can Machine Learning Play?
If we can define a logical model with reliable predictive results, then we can begin the journey of providing free consultative guidance to ERP customers and prospects. Let’s start simple with a prediction formula and a structured learning test set.
Following are the assumptions that I used for building the formula and training set:
Business process maturity (CMMI) and organizational maturity (OCC) have a linear relationship with potential ERP utilization.
Certain permutations of CMMI and OCC does not reflect reality (ex. Business process cannot be at a high level of maturity and a low level of organizational maturity).
The minimal boundary of ERP utilization is 20% and the maximum boundary is 80%.
Next, I performed individual regression analysis for each variable separate and together in order to determine if the predicting equation should use one or both variables.
Based upon the above analysis, it appears that the prediction formula utilizing both business process maturity and organizational maturity best aligns with the training set. Next step is to calculate the coefficients for both variables.
In an act of transparancy, I am sharing my data model. Feel free to review and provide feedback/correction.
So what is the application or value add this model can provide?
Even with a cloud delivery model, the implementation costs associated with ERP have not dramatically decreased. The ratio of ERP software cost to ERP implementation cost has increased from 3:1 to 6:1. It is only a matter of time before the ERP market forces ERP vendors to drastically reduce implementation costs while maintaining a sufficient level of customer enablement. Given the rise and general adoption for cloud ERP services, ERP utilization is becoming more strategic competitive advantage for cloud ERP vendors. What I see as an emerging demand from the ERP market is a reliable, repeatable method for maximizing ERP utilization. I hope that my efforts move the discussion forward.
Join the community! 10k followers across 100 countries!
Not sure if I’m wiser but as part of my knowledge sharing efforts, I would like to share 200+ quotes from over 50 books/resources that have influenced/guided my ERP journey. Nothing beats “hands-on” experience but trust you may find some value. These quotes are grouped into the following areas:
Join the community! 10k followers across 100 countries!
“For any organization there are just a few key processes that handle the core business. All the other processes support the key processes on a certain aspect.” ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.
“To maximize a revenue-supporting process is illogical as it will take effort away from revenue-generating business processes.” Bill Curtis.
“Not all process-integration problems are technical and not all about IT. Integrating computer systems is not the same as integrating the business.” Business Process Management – the Third wave, Howard Smith and Peter Fingar.
“Adaptive approaches are good when your requirements are uncertain or volatile.” Agile Project Management, Agile Software Development.
“A common mistake is to design and configure the system for only the first site and worry about the others later.” Control Your ERP Destiny, Steven Scott Phillips.
“The cost of complexity isn’t offset by what you can charge. Complexity creates opportunities for you to fail your customer.” Gerand Arpey – President of American Airlines.
“Customers tend to interpret requirements broadly, and developers tend to interpret them narrowly.”, Rapid Development, Steve McConnell.
“The ability to trace requirements flow from their source (originator), through the various project phases (design, prototyping, customizations, testing, piloting, and delivery) is a requirements generation best practice.” Directing the ERP Implementation, Michael Pelphrey.
“When managers of a company select an ERP package to implement, they are “buying into” the ERP vendor’s view of a certain industry’s best practices and relying on the system to support their efforts to embrace these practices.” Modern ERP. Marianne Bradford.
“Paralysis through analysis” is a futile attempt to develop the perfect solution. Control Your ERP Destiny. Steven Scott Phillips.
“Iterations systematically reduce the trade space, grow the knowledge of the solution, and increase stakeholder buy-in. At the same time, each iteration, or spiral, is planned to mitigate specific risks in the project.” Evolutionary Process for Integrating COTS-Based Systems (EPIC), Carnegie Mellon – Software Engineering Institute.
“Requirements creep must first be differentiated from requirements evolution (elaboration).” Agile Project Management. Jim Highsmith.
“If you’re using a waterfall model, forgetting something can be a costly mistake. You don’t find out until you get down to a system testing that one of the requirements was missing or wrong.” Rapid Development, Steve McConnell.
“The advantage of the incremental approach is that the company can get feedback on the implementation and how it is received and possibly fin tune the implementation strategy.” ERP Demystified, Alexis Leon.
“There is no direct relationship between a company size and the complexity of its (ERP) software requirements.”, Control Your ERP Destiny. Steven Scott Phillips.
“From a financial perspective, for every $1 not spent on requirements analysis: $10 is spent on extra implementation cost and delayed ROI, $100 is spent in business disruption costs on going live, $1k is spent in hidden costs of not meeting expectations over the life of the software.”, Rethinking Enterprise Software Selections, Chris Doig.
“Often the problem lies not with the ERP concept. But in the demand for quick fixes and rapid cures to underlying structural problems.” e-Business Roadmap for Success, Dr. Ravi Kalakota & Marcia Robinson.
“A company may employ the most sophisticated software in the world, but unless information is managed, timely, accurate, and complete, the system serves little purpose.” ERP Lessons Learned – Structured Process, Wayne L. Staley.
“One guiding tenet is every present: any change we administer should add more value, cost less, or deliver services more rapidly.” Transitioning the Enterprise to the Cloud, Ed Mahon, CIO at Kent State University.
“You give me good people and a great process, and we’ll beat any organization with the best technology but a poor process and under motivated people.” Information Week – Focus on the Process. Doug Patterson, VP and CIO.
“Experience shows that the greater employee involvement in the change, the greater the positive response in understanding the compelling need for the change and the sharing of the vision.”Managing the Change Process, David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management
“People are one of the hidden costs of ERP implementation. Without proper training, about 30 to 40 % of front-line workers will not be able to handle the demands of the new system.” Consider, Select & Implement an ERP system, O’Sullivan, Rico, Goldensohn.
“The users of the ERP will be confronted with a huge amount of data; most of the data will have no relevancy to any decision that needs to be considered.”ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.
“Operation and maintenance phase begins with a period of initial struggle until people become comfortable in their roles and tasks. The duration of this stage depends on how effective the training was.” Enterprise Resource Planning, Alexis Leon.
“People can’t be controlled like machines: Service processes are far more dependent on the interaction of people (both internal handoffs and working with customers) than are manufacturing processes.” Lean Six Sigma for Service, Michael L. George.
“There are limits to how much change an organization and its end users can stomach at once.” Why New Systems Fail. Phil Simon.
“In an organization undergoing change, building a resilient work force by widely disseminating the change vision and strategy and by minimizing disruption is essential.” Managing the Change Process, David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management.
“If you think education is expensive, try ignorance.” Derek Bok.
“Although consultants may participate in testing to some extent, employees should drive the majority of testing. Doing so maximizes knowledge transfer and readies them for real life under the new system.” Why New Systems Fail. Phil Simon.
“Gartner Research recommends allocating 17 percent of the project’s budget for training. Those companies spending less than 13 percent on training are three times more likely to have problems.”, Concepts In Enterprise Resource Planning, Ellen Monk and Bret Wagner.
“A big mistake made with (ERP) software purchases is leaving user buy-in until the implementation phase. When this happens, users feel the sofware is being foisted on them without their input.”, Chris Doig, Rethinking Enterprise Software Selections.
“In order to do rapid implementations, trade-offs must be made.” E-Business and ERP, Murrell G. Shields.
“Rapid Implementations: The data cleanup must start early in the project for the organization to be prepared for the data conversion.” E-Business and ERP, Murrell G. Shields.
“Rapid implementation cannot be done with a massive project team.” E-Business and ERP, Murrell G. Shields.
“Deliver sooner rather than later. It is rare to get 100% support for any project; “fence sitters” will wait to see how things turn out before giving their support.” Modern ERP, Marianne Bradford.
“The training in a rapid implementation should be hands-on.” E-Business and ERP, Murrell G. Shields.
“Good people can make a bad system work; bad people can’t make a good system work”. The Reengineering Handbook. Raymond L. Manganelli, Mark M. Klein.
“The “Train the Trainer” Pitfall: It is not realistic to assume someone can be trained several weeks before the go-live and expect him/her to deliver quality training.” Control Your ERP Destiny. Steven Scott Phillips.
“The data migration phase of a project can consume up to 30% of the total project resources. The most common flaw in data migration planning is that too few resources are invested in it.” Top 10 Reasons Why Systems Projects Fail. Dr. Paul Dorsey.
“Extracting and cleansing the data from the existing system can be the single largest task in the project.” ERP Demystified. Alexis Leon.
“Bait and switch. This is the practice of displaying certain consultants, during the sales process, to show the sales company understands business and the ERP implementation process to ensure a successful outcome.” Enterprise Resource Planning (ERP) The Great Gamble, Ray Atkinson.
“Have successful project managers who are capable of anticipating what can go wrong.” ERP Demystified, Alexis Leon.
“Overspend on consultancy is often compensated for by a cut-back in training. This is not helped by the fact that training costs tend to be under-estimated in the first place.” ERP – The Implementation Cycle, Stephen Harwood.
“(ERP) Service organizations are essentially big “people machines”, where having a high level of turnover is just as deadly as if a manufacturer was constantly asked to change machine parts.” Lean Six Sigma for Service. Michael L. George.
“Implementation audits are necessary to keep the project on track. Audits should be conducted to compare project results, business objectives, systems objectives, and project objectives.” Directing the ERP Implementation. Michael Pelphrey.
“Claims of ‘proven paths’, ‘best practices’, and simplistic implementations methodologies, that fail litter the ERP landscape as each software company seeks to gain some form of advantage over its rivals. “Enterprise Resource Planning (ERP) the Great Gamble. Ray Atkinson.
“What businesses need is not a one-time fix for individual processes but an environment that combines business and technical systems to produce processes that flex and recombine as required by changes in the market.” Business Process Management – the third wave, Howard Smith and Peter Fingar.
“As Tom DeMarco and Tim Lister (2003) so pithily state, “If a project has no risks, don’t do it.” Risk is an essential characteristic of innovation”.”, Agile Project Management, Jim Highsmith.
“Cost overruns are manageable if the project will achieve worthwhile benefits; however, failing to satisfy business goals is always unacceptable.” Principles of the Business Rule Approach, Ronald Ross.
“Customers like rapid delivery. Rapid delivery means companies can deliver faster than customers can change their minds.” Lean Software Development, Mary Poppendieck & Tom Poppendieck.
“One of the biggest mistakes during ERP projects is not taking the time to build a common understanding of how business is conducted today and potential improvement opportunities.” Control Your ERP Destiny, Steven Scott Phillips.
“If the project becomes all things to all people, it will fail to meet anyone’s expectations.” Control Your ERP Destiny, Steven Scott Phillips.
“A consultant with software knowledge is one thing, but if the consultant is a poor communicator, it undermines the transfer of knowledge.” Control Your ERP Destiny, Steven Scott Phillips.
“Job 1 is to run the business. Very close to that in importance should be implementing ERP.” ERP: Making It Happen, Thomas Wallace & Michael Kremzar.
“A methodology will help ward off risk, but a contingency plan is still absolutely necessary.” ERP Demystified, Alexis Leon.
“There are literally thousands of decisions that must be made on these projects. The project team must be empowered to make most of them. That is one reason organizations must put their best people on these teams.” E-Business and ERP ,Murrell G. Shields.
“The rumor mill and grapevine are active in most companies, and it is in the project team’s best interests to preempt them by providing clear, consistent, targeted, and ongoing communications.” Successful Packaged Software Implementation, Christine B. Tayntor.
“But technology is not reengineering. Reengineering changes the business processes – the way the work is done.” The Reengineering Handbook, Raymond L. Manganelli, Mark M. Klein.
“Projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place.” (Fagan 1976; Boehm and Papaccio 1988). Rapid Development, Steve McConnell.
“The success or failure of a new system hinges directly on the acceptance of that system by the organization’s end users.” Why New Systems Fail, Phil Simon.
“The goal of an integrated enterprise is to reduce information float, that is, the time between when data is captured in one place in the system and when it becomes available and usable. e-Business Roadmap for Success. Dr. Ravi Kalakota & Marcia Robinson.
Chris Koch of CIO.com writes, “Blank sheet reengineering can lead to unrealistic business process designs that can’t be implemented through enterprise software.”.
“A major cause of this difficulty (failures) is that organizations building these systems tend either to assume that components can be simply thrown together or they fall back on the traditional engineering skills and processes with which they are familiar-skills and processes that have been shown not to work in the building of COTS- based (ERP) system.” Evolutionary Process for Integrating COTS-Based Systems (EPIC) Carnegie Mellon – Software Engineering Institute.
“Agile methods universally need close relationships with the customer and users of the systems under development.” Balancing Agility and Discipline. Barry Boehm, Richard Turner.
“The truth is, no organization plans to fail – rather, they fail to plan…” Control Your ERP Destiny, Steven Scott Phillips.
“Two overriding criteria that mast be present if the implementation of a COTS solution are to be successful: realistic expectations and organizational flexibility.” Successful Packaged Software Implementation. Christine B. Tayntor.
“The longer a team, large or small, goes without delivering an integrated product to a review process, the greater the potential for failure.” Agile Project Management. Jim Highsmith.
“Inclusion of end users promotes acceptance of the solution and helps break down “us versus them” barriers. Working together, the two groups will provide a balanced evaluation.” Successful Packaged Software Implementation, Christine B. Tayntor.
“For an ERP implementation to go smoothly and provide value, it is critical that a company understand both its current processes and the state of the process after implementation.” Concepts in Enterprise Resource Planning, by Ellen Monk, Bret Wagner.
“Making partners of customers means they become more likely to understand technical constraints. You start to get rid of the “I need it all now” phenomenon, and customers begin cooperating to find realistic, mutually satisfying technical solutions.” Rapid Development, Steve McConnell.
“Don’t try to fool yourself that you will be able to catch up (project schedule) just by trying harder. It won’t happen.” Making ERP Work, Sam Graham.
“ERP systems will not exhibit their full potential unless they are properly integrated with other enterprise software applications.” ERP Demystified. Alexis Leon.
“ERP is a philosophy for operating a business model. If your company does not want to adapt to this philosophy, save yourself the headache and don’t pursue ERP.” Directing the ERP Implementation. Michael Pelphrey
“Implementing the ERP system and realizing the promised benefits are two different ball games. Implementation can be a success, but if the operational phase is not planned and organized properly with the support of all the people involved, then the promised benefits will not materialize.” ERP Demystified. Alexis Leon.
Given that we are well in the third decade of ERP implementations, I still observe ERP implementations following outdated/misguided concepts that do not utilize limited resources to the fullest. One of these misapplied concepts is Just-In-Time (JIT) training. End user enablement continues to be an implementation challenge primarily due to the limited investment made for the most important component of an ERP business solution. This limitation must be addressed in order to realize the value of ERP in the Cloud.
Evolving Traditional ERP Testing for Cloud ERP
Consider the following illustration that highlights the tradition user involvement model:
Traditional User Involvement
Traditional ERP implementation approaches view end users as an audience versus an active participant to leverage during the entire implementation. End users by far make up the largest stakeholder group in an ERP implementation however; they have the least amount of involvement and responsibility. Let’s further contrast and identify opportunities where end-user involvement can have a positive influence on ERP implementations.
The majority of testing and hands-on experience occurs with a limited group of users leaving a small window for direct users to gain confidence and experience with the ERP system.
The limitation with direct user involvement is based on the premise that a working system is not available until the end of the implementation. This is not the case with a Cloud ERP system that can be provisioned early during the implementation life cycle.
JIT End User training is a big bang approach – one time shot to get end-user training right. It also gives end users limited time to internalize the change. This approach naturally requires additional support and creates a greater potential for user errors.
Waterfall is based upon software being developed from scratch – i.e. you could not actively involved end users until the software existed. When ERP came to the market many approach/processes designed for software development were incorrectly applied to ERP implementations. The next section we will discuss how to involve the target audience sooner during a Cloud ERP implementation.
Increasing End User Involvement
There are two key value propositions for increasing end-user involvement:
Additional validation of the solution via testing.
Greater user adoption and enablement.
For robust testing business users should first be trained on the ERP Cloud service. Remember that testing can be “hands-on” learning for business users. Consider the following illustration:
Incremental User Involvement with ERP Implementations
Let’s expand on some key themes. First, education/learning is an iterative process where new information needs to be assimilated by users before knowledge is created. Second, an educated user is a better contributor to the project. Third, it is easier to manage and support educated end users. A forward-thinking end-user enablement process drives greater participation and ownership.
Consequences of Not Evolving your User Enablement Approach
As ERP Cloud adoption continues we will see an increase in the following implementation drivers:
Market Drivers for ERP Cloud Implementations
Consider that traditional ERP implementation approaches do not effectively leverage the largest resource pool available. I can appreciate that with additional resources comes greater coordination and communication channels (N * (N-1) / 2) yet I have witnessed that the business value outweighs the associated project risk. With the above said I do not recommend we start involving end users without some level of enablement and guidance. Just as an individual user learns a new system over time the end-user training approach should incrementally prepare the user for greater involvement during the ERP Cloud implementation.
Following are key consequences if we continue with a JIT user involvement strategy:
Potential issues/risks from take a JIT user enablement approach
The JIT approach is being used to squeeze pennies out of an ERP Cloud implementation when the potential risk that results is far greater and eventually must be solved through additional dollars or lost opportunities.
Challenge to Cloud ERP Service Providers and Implementation Partners
Cloud ERP Service Providers and Implementation Partners should take the lead in promoting and supporting end-user involvement earlier during the implementation. Unfortunately, Cloud ERP Service Providers are not providing a robust set of tools and services for incremental user enablement. Test cases should be business process focused and not just business function oriented.
Implementation Partners must also adapt to this new paradigm. It is unfortunate that many implementation partners choose to address ERP Cloud Implementation drivers (mostly cost) by reducing project leadership and transferring user enablement to the customer – regardless if the customer have the required tools/competencies for incremental user involvement. This short-sighted approach ultimately leads to an unfavorable customer experience with Cloud ERP.
Just in Time (JIT) is an operations management approach for improving ROI by minimizing inventory and related carrying cost for a production process. JIT is a viable strategy given that the process is production quality and all input variables are within controlled tolerances. Implementing a Cloud ERP solution is not a production quality process nor are all input variables can be controlled. This concept has been applied to ERP end-user training with the intent of maximizing training investment. JIT training reduces the need for refresher training due to ERP knowledge loss experienced if training precedes the go-live event over a long period of time. JIT training may be a valid approach for end users after the ERP Cloud service is in Production but it is a limited strategy to employ during an ERP implementation. Make the end-user an active partner not a passive customer.
Join the community! 10k followers across 100 countries!
I think we can all agree that organizational fit is a key consideration for successful ERP selections and implementations. However, mention the phase “fit/gap” or “gap analysis” and most people will fixate on the ERP software. There are several examples of functional/software fit-gap templates/activities but very few organizational fit-gap templates/guides. The goal of this blog is to shed some light on this very important activity.
What is an Organizational Fit/Gap?
An organizational fit/gap analysis is a comparison of the customer’s existing organizational model that supports the business to the defined organizational model supported (or assumed) by the ERP system. Consider the following illustration:
Organizational Fit Gap Analysis
If you do not know what is changing in the organization then how can you manage organizational change? Too often I see ERP projects only focus on the “To Be” model and expect business users to figure out how to transition. I have also observed that customers see organizational change activities as an opportunity to reduce implementation costs by performing the activity themselves – regardless of their capabilities.
In order to effectively conduct an organizational fit/gap analysis there are two key sources of information that are required:
Customer’s Organizational Structure and Business Processes
A majority of peers and customers believe that this exercise is a non-value-add activity given the imminent organizational change that will occur as part of the ERP implementation.
ERP Business Process Maps
Consider ERP business process maps as a demonstration by the ERP vendor to show how their ERP software supports business processes.
Just as you perform a formal Fit/Gap analysis on ERP functionality you should also consider performing a formal organization Fit/Gap analysis as illustrated below:
Template to identify possible organizational changes based upon predefined ERP roles/responsibilities
An organizational fit/gap analysis should be performed during the ERP selection stage and refined during the early design stages of the ERP implementation. Do not limit yourself to performing this exercise only once. The analysis performed during an organizational Fit/Gap will drive future decisions and implementation activities.
What Activities should an Organizational Fit/Gap Influence?
The organization fit/gap analysis will have a direct impact on your organization change management plan and communication plan. In addition, this analysis will provide insight into user security requirements. Utilizing this approach will highlight how well the predefined ERP user security profile(s) align to the organization’s existing users. As a general rule, the majority of predefined ERP workflows are based upon predefined user security roles; therefore keep in mind that ERP user security profile changes may require additional testing for related ERP workflows.
Predefined ERP implementation tools, templates, roles can provide limited value to an implementation. Too often the ERP market wrongly perceives that these predefined components result in faster implementations. This misconception is most pronounced in the ERP SaaS/Cloud arena. At the end of the day, an ERP implementation should only move as fast as the customer can handle the change. Conducting a formal organizational fit/gap can enable the customer to adapt faster by focusing on the specific changes required for success.
Join the community! 10k followers across 100 countries!
During my career in ERP consulting I had several opportunities to be involved in deployment of emerging ERP products and services. As with any innovation rollout there are challenges to overcome and I had to learn how to quickly triage ERP projects for success. Troubleshooting an ERP project is more than just performing an assessment – it’s implementing a realistic action plan and making it work for all stakeholders involved. Following is a tested and proven approach to jumpstart stalled ERP projects.
Similar to a Forest Fire Hotshot I typically got dropped into a “hot” ERP project that had stalled or had serious show stoppers. Time is always against you. However, you must first put in the effort to objectively understand the situation and establish your credibility:
Troubleshooting ERP Projects
Too often I see project managers jump into the details (WBS, Risks, Issues, CPI, SPI, Cost) without first understanding the context. You cannot be perceived as a busy body looking for who dropped the ball. Vendors, Customers, and System Implementers are made up of people. People make mistakes – especially me. People don’t care what you know until they know you care. It will be people – not technology – that will play the biggest role in getting the ERP project back on track.
Before hitting the ground running you first need to do your homework. As part of an ERP assessment it is important to review the key project artifacts generated and updated throughout the project.
Key Project Documents
This is the easy part and it is usually a simple process to review and evaluate. If a project scope statement does not exist or is not well-defined then chances are this absence is contributing to the problem. Creating or refining the project scope statement is a very small part of the action plan you need to execute. Now, let’s turn our attention to the implicit artifacts and information that are harder to identify and resolve.
Understand the Underlying Drivers
ERP vendors, System Implementers (SIs), and Customers want their ERP implementation to be successful. Yet there are fundamental drivers for each stakeholder that appears to be in contradiction. Consider the following illustration:
ERP Stakeholder Implicit Drivers
Understanding the fundamental drivers of your stakeholders enable you to relate, empathize and align the efforts of all project stakeholders. It is important to note that you need the efforts from ALL stakeholders for success – regardless of who is at fault. I humbly submit that it is extremely rare when a single stakeholder is responsible or is at fault. On the flip side it is even more extreme to have a single stakeholder solely responsible for saving the day.
Strategy & Execution
It is a straight-forward exercise to develop a plan for troubleshooting an ERP project but providing a plan by itself does not add business value. How you execute and implement the plan is more important than the plan itself. Many of my project management colleagues may not agree with my assessment but I am convinced that this is true. Following are my guiding principles for ERP troubleshoot efforts:
Create quick wins. Triage is required to stop the bleeding. You need to quickly seize the initiative and create positive events.
Attack problems from multiple angles. If you have one approach get stonewalled you still have other ongoing activities to continue the march forward. This means that you have contingency plans in flight. Be aggressive.
Triage is not the time for lessons learned. There will be opportunity for reflection after the immediate problem(s) have been addressed.
Problem solving is not about assigning blame. You need every individual to have laser focus on resolving the problem and not on how to protect them own interests.
All stakeholders must be willing to stretch outside their comfort zone. Customer and vendors limit their response based upon contractual arrangements. Partners think outside the box for mutual success.
The answer lies within the team. Many times the greatest impact you can have is to enable the key players to recognize the solution. Communication skills will be vital to your success:
Survival Skill – Communications
There is a fair amount of information available in books, articles, and blogs related to avoiding ERP problems and I agree that you should take reasonable steps to minimize known ERP problems. However, I believe that it is prudent to be prepared for the “unknown unknowns” that always occur with any ERP project. Troubleshooting ERP projects require process knowledge of project management fundamentals, problem solving techniques, and most importantly – perseverance. Just like the rudder steers the ship, finding small success(es) can get your ERP project back on the path for success.
Join the community! 10k followers across 100 countries!
I had a customer ask me about the relationship between BPM and ERP. Does ERP implement BPM or do you need to have BPM before ERP? Is an ERP implementation a BPR project? Who’s on first? As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience. In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.
BPR, BPM, and ERP Revisited
Allow me to establish some basic definitions for our discussion:
Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise. ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.
There are a couple of key concepts we should review to compare/contrast BPR and BPM.
Compare & Contrast BPM & BPR
BPM focuses on the business process model to monitor, identify, and implement incremental improvements. These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model. However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required. A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity. Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):
BPR, BPM within CMMI
Allow me to provide an example. Company A performed a CMMI assessment of their purchasing process. Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect). Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managedlevel. Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations.
Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain. Two fundamental mindsets have to change:
Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.
Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities. As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level.
ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
ERP provides the opportunity for visibility across business functions to support business process management. That said, there are several factors that determine the level of visibility.
Factors Impacting ERP Business Process Visibility
A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box. As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked. A business solution is only as good as its weakest integration. Process consistency will enable a relevant comparison of results and management of business processes.
A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.
Common ERP Misconception and Mistakes Related to BPR & BPM
Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.
BPR is part of the ERP implementation.
While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.
Implementing ERP will give us BPM.
The direct answer is no. ERP does provide an information foundation that can support BPM. BPM is more about a discipline for managing processes and less about software.
Do I need ERP to mature my business processes?
Technically speaking, ERP is not a hard requirement for BPM. However, manual routine tasks and limited visibility hinder strategic activities. ERP can play a key support role in automating business tasks and provide visibility through integration.
Should I implement ERP features that support business activities at different maturity levels?
Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels. The problem lies in two areas:
Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities. Example: A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity. This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.
Understanding how BPR, BPM, and ERP should relate to one another can be a challenge. Some believe that it is an “either or” proposition. I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy. Knowing and appreciating these interdependencies will put you in a better position for ERP success.
Join the community! 10k followers across 100 countries!
Business to IT alignment is an objective that most technology and business leaders would agree as essential for agility. However, ask for a definition of Business to IT alignment or how to implement an alignment strategy and the likely results are conflicting information and vague guidance. In the following blog I will try to add clarity to this topic as well as provide practical guidance.
Let’s start with a basic definition of Business to IT alignment by addressing some common misconceptions. Business to IT alignment is far more than just Project Portfolio Management (PPM). Business to IT alignment consists of several domains:
Business – IT Alignment Domains
Several Tier I & Tier II ERP software vendors provide software solutions to address certain Business to IT Alignment requirements, including PPM and Communications (social collaboration). However, it is important to remember that technology alone is not the answer. Collaboration tools can be used to generate more noise than effective communication. Also consider that having strategic initiatives stored in a common platform (ex. PPM) does not mean the all stakeholders share a common interpretation.
Just as Business – IT alignment is more than just PPM, enterprise governance is much more than just IT governance. In simple terms, enterprise governance is a process that ensures that enterprise capacity (Business, Operations, IT) are working on the right things at the right time to enable business goals. It’s a set of guidelines that focuses on organizational success while managing associated risks. Alignment is hard to achieve when governance is not consistent across the enterprise. Knowledge transfer is the most underestimated and misunderstood area. Effective knowledge transfer is more about education and trust than software and templates. Before one can be successful with Business – IT alignment it is important to fully appreciate the scope and breadth of effective alignment. A viable alignment strategy must address the key challenges listed in the next section.
The Challenges of Business to IT Alignment
Consider the following alignment model. This is a very simple model that I would like to use for discussion purposes.
Business – IT Alignment Governance Model
Allow me to highlight some key challenges associated with the traditional alignment model provided. First is the notion that Business and IT operate separate silos. Notice in the example above that there are separate Business and IT goals. Thus, there must be an exercise to reconcile Business goals and IT goals to identify commonalities and gaps. Practically speaking, given the level of effort required to align these separate strategies, a reasonable conclusion is that alignments occur periodically based upon corporate milestones. This is where the model breaks down because effective alignment must be a daily activity. Every business request from strategic initiatives to daily support tickets is an opportunity to reinforce alignment. Another possible concern implied in this model is that the majority of alignment effort happens at the enterprise level. Sustainable alignment must happen at every level within the organization.
A results-oriented alignment strategy must address the inhibitors of alignment. Consider the following relationship between alignment and communication:
Alignment and Communication Inhibitors
Success alignment requires successful communication. Successful communication requires the effective use of all the key communication skills
Key Communication Skills
Process is important but the soft skills like communications, emotional intelligence (empathy), and knowledge transfer will have the greatest import on long-term alignment success.
Once you have identified your current maturity level then you can devise realistic, increment steps to move forward to the next maturity level. It is also important to periodically assess your organization’s alignment. What gets measured gets done!
Why is Business to IT Alignment so hard? Consider the following statements to highlight the key challenge with alignment.
Business vs IT Value Drivers
Is Business to IT alignment an impossible goal? No, as long as a practical, measured approach is taken to achieve tangible results. 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. When alignment is achieved communication is effective resulting in valued partnership.
Join the community! 10k followers across 100 countries!
Knowledge transfer is only the beginning to enablement.
Many implementation partners (including myself) have handled enablement as an event or milestone that occured as part of the cut-over to production. We as implementation partners too often assume that the traditional, informal “do what I do” approach between consultants and customer was sufficient for customer enablement. If the traditional approach was sufficient for customer enablement then one can argue that there should be no need of post production support.
When ERP software is implemented in a production environment it is usually the first opportunity for the customer to lead in the support of a new business solution. For the majority of customers that do not have hands-on experience with supporting external packaged software this can be a difficult challenge. Customers typically ask their implementation partners to provide post-production support until the customer has confidence in their business solution support (technical, business) capabilities.
There is a better way. An approach that will more effectively provide the knowledge, experience, and capabilities the customer requires to be self-sufficient. This enablement must be completed and validated during the implementation. There will be less need for post production support to address the enablement gap for customers. Let’s elaborate on one of the key processes that will prepare the customer to lead during the implementation.
Progressive Leadership Style
A key competency for any implementation partner is their ability to enable the customer to support and manage the new ERP software. This will require the implementation partner to employ different leadership styles during the implementation. There should be a logical progression in leadership styles that naturally transfers ownership from the implementation partner to the customer. We will use the following illustration for our discussion.
Let’s discuss each leadership trait in more detail in the context of an ERP implementation life-cycle.
In the early strategy and planning stages of an implementation the implementation partner should use a directive leadership style to lead the customer. The implementation partner leads in setting the direction and the pace of the implementation.
As the customer is educated on the packaged software and implementation approach the implementation partner moves towards a coaching leadership style to enable to customer to take a more active leadership role in the packaged business software implementation.
With the facilitating leadership style, the implementation partner has moved from an active leadership role to a passive leadership role. The customer is leading and managing the implementation project.
The supporting leadership style is the final stage where the implementation partner provides what I’ll call ad-hoc/as needed support & guidance.
The first day of any implementation is the first day of transition from the implementation partner to the customer. Many treat transition as a last step in a go-live event. This approach results in customers not being ready or confident in supporting their business solution. A customer should never feel that way! Allowing the customer the lead will naturally drive the implementation partner to be more focused on knowledge transfer to the customer and results in better success rate for customer preparation.
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:
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)
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.
Join the community! 10k followers across 100 countries!