Future State: A Simplified Checkpoint

Tempus Fugit.

Double-O-7, tortured and bleeding, whispered in the ears of Dr. Madeline Swann, "Tempus Fugit."  She then threw the time bomb devised by Q, towards the sinister Blofeld, for an explosive diversion and escape.  Indeed, time flies (in spite of the run-on tendencies). And here we are, somewhere at the midpoint of the term, where we have supposedly reinforced what we know, as we continue our learning journey of Enterprise Architecture.  As you can see from the diagram below, we're also midway towards the end of the navigational roadmap. A well-known effective devise, it's good to come up for air, and check where we've been, get our bearings straight, before we continue to dive again and learn some more.

A Good Day for Drawing.

Using Gartner's Navigational guide for EA (deliverables) above, I went ahead and worked on an exploded view of the future state area. Hopefully the diagram below serves to highlight what I think are the key playing components, when we are at that particular stage, focused on communicating future state. Things became more clear to me as I was drawing, and my purpose is to share and validate this clarity with readers.  At any rate, it was a good breakfast -- a typical weekend delight from my wife, and hopefully you'll agree that it served me well.

Where's the Customer?

Please make no mistake -- this picture embodies a customer focused philosophy.   Ironically, the customer labels are missing in the diagram. But this is by design, because everything in this model segment revolves around customer focus i.e. the spirit of the customer is everywhere. Internal customers, as organizational units work to serve each other, define the efficiencies and effectiveness of the business. Obviously, the actual business customer to which the organization evolves its business, is the reason for being -- our raison d'être. The vision of this business customer is critical to keeping the business organization alive in the ecosystem, such as the marketplace, or society in general.

Revisiting Business Context

The model also comes back to why we need a solid understanding of the business context for the organization, to which we develop and serve the enterprise architecture.  The Business Context gives us a clear view of the environment to which we will implement our initiatives; i.e. the operating model that the business has chosen, the organizational culture and capabilities in place, and the trends -- technology among others, to which the business needs to react and/or adapt. Moreover, the Business Context gives us a strong foothold with which we anchor our understanding of mission, goals, and strategies;  to which, in turn,  we work our architectures in pursuit of constant alignment. Note that I have placed the gears near the alignment box to indicate where I feel the bulk of the work of EA is done - as mentioned elsewhere I feel this area triggers the messy work of change management.

Stakeholder Viewpoints. Having your Cake and eating it too.

Viewpoints represent each group of stakeholders' interest on the architectures, i.e. a particular viewpoint takes a focused slice through any or all of the 4 layers of the future state (Business, Information, Application, Technology) -- to make sure that IT initiatives are taking care of stakeholders' concerns.  As architects, we need to precisely define these viewpoints, and deeply understand the nuances, because they serve to keep our communication lines with stakeholders crystal, to ensure that we evolve our architectures responsive to the key stakeholders' concerns. Indeed, when architects create these slices with the highest skill, it is possibly one of the few occasions when we can really say that we can have as many slices of the "cake", while we keep and wonder at the beautiful EA cake we made.

An Important Equation: Requirements = Capabilities.

The sets of business capabilities is the combination of processes, information, people, technology, and other enabling assets such as facilities and funds.  Business strategies are geared towards developing these capabilities in order to achieve mission and goals. Capability components are related to each other, as well as to the Business Context where they will eventually be applied. Such relationships imply key interfaces, and ultimately require a definition of responsibilities and ownership.  Achieving a comprehensive understanding of capabilities, therefore, allows the architect to have a clear picture of the set of business requirements which, in turn, defines a key driver for the architecture.

Principles. You can run -- but you can't hide.

There are many ways to logically organize and categorize principles. The Gartner conceptual matrix,  supplied in the class toolkit, nicely shows a summary form of how principles can cut across and map with other principles, e.g. business vs. information, and business vs. technology.  

You can, as an option, devise the architectures without thinking about the principles. But you got to be ready to run when you do.  Stakeholders will be waiting for you at the corners.  The diagram could have shown a bi-direction line connecting requirements and architecture. However, note that I only kept one direction, to illustrate retention mainly for the validation relationship from architecture back to requirements. As best practice, a true architect would shape the solution by looking at the requirements from a principled view. In short, capability requirements are designed into the architecture, not auto magically, but through the application of guiding principles that the organization has bought-in and understood.

Happily, these principles, once bought-in, facilitates the justification process for our architectures i.e. makes our lives as architects easier, in line with what was pointed out in class. We should never underestimate the power of these principles, nor should we understate and neglect the promotion of such. As architects, we should repeat these principles in our head, because these sets of principles are the stuff from which we make our magic. Part of our job is to constantly evangelize on the principles at play in the architectures that we provide.  At the end of the day,  those who will call these architected solutions "home",  will be more at peace -- knowing that what they have and use on a daily basis are based on solid rationale, which promotes confidence, that keeps them operationally strong and healthy. 

Maturity Growth Towards Mission and Goals.

Notice that the architecture maturity levels grow towards mission, goals, and strategies.  As the enterprise architecture matures, I should think that the organization will see the tighter alignment of IT initiatives with business vision and strategies. A happy event for sure, in which the organization incrementally reaps the benefits of their IT investments -- hopefully creating opportunities to pursue innovation, and in the process, reinforce the competitive posture of the company.

The IT Engagement Model and the Next Steps.

Clearly this way of thinking for future state communication promotes what Ross talks about as the IT engagement model. It gives us a picture of relationships, important to understanding the required governance mechanisms, which in turn, should ensure that business and IT projects will deliver on objectives. By highlighting mission, requirements, and principles, it is clear how this segment of the IT engagement model influences decisions and prioritization of projects; and provides guidance for solutions via enterprise architecture.   For senior management, such clarity reminds of key results and benefits, facilitates measurement, and helps maintain an encouraging view of how EA creates value. 

So, given these discussions, what artifacts are key in communicating future state, and how would you present these artifacts convincingly?

Good luck to all of us on our team submissions of Case Analysis Part 2.

Cheers, and keep it light.

Complementary blogs:

Other blogs for week 7 nicely complement this blog. Hasan's Business Context issues, Veena's abstraction levels of future state models, Susan's nuances of the architectural layers; Jonathan's discussion on principles, with caveats and the reference to IBM's sample for the financial sector;  and Swathika's take of conceptual details from week 6.

https://hasan7350.wordpress.com/2016/02/27/business-context-layer/

http://veenavenkataramu.blogspot.com/2016/02/blog-entry-7.html

https://smk40.wordpress.com/2016/02/28/lesson-04-blog-7/

http://enterpriseskeptic.blogspot.com/2016/02/extreme-architecture-principles.html

http://swathikav.blogspot.com/2016/02/conceptual-level-of-future-state.html

TOGAF or NOT TOGAF

Is this really the question? Or is this even foolish to ask? [Alternatively insert your comparative frameworks of choice here]. I think to a certain point these are valid questions. However, indeed, it appears that the debate on the level of completeness for frameworks continue to reach seemingly Shakespearean heights of intrigue and borderline melodrama.

Admittedly, a framework can leave a lot up to the organization to fill in the blanks. But this should be no surprise -- a framework by definition is skeletal, and perhaps one can use the word "deliberately vague" as a remote synonym. Sampling some frameworks, I see that others are more generous with substance, but these come mostly as examples i.e. so-called Reference Models, and can still leave you with the option to explore your own specific elaboration.

If you google on "EA frameworks", discussions will be replete with comments that a framework is not a cookbook. It is not a methodology in itself. Although a framework can suggest its own methodologies for specific areas of the framework, e.g. TOGAF's ADM.

As an additional example, a framework can introduce the concept of views and viewpoints, and will perhaps illustrate the concept with the primary viewpoints, but will leave the option and flexibility for the organization to explore what other viewpoints make sense for their particular business context.  Thus, I continue to see consistent illustrations that reinforce the notion that these frameworks are meant to be explored, and allows the happy free experimentation to see how one framework can actually be combined with others.

Take a look at what Raytheon tried with TOGAF, DoDAF, and Zachman.

http://www.opengroup.org/architecture/0310wash/presents/Rolf_Siegers-REAP_Overview.pdf

Allen Brown, President and CEO at The Open Group, says this: “If people are struggling with TOGAF, either they’re not adapting it for their organization, or they’re not getting people who’ve ‘been there, done that, got the T-shirt, have the scratch marks’ to help with the initiative.” 

Vish Viswanathan, Managing Principal of an Australian EA consulting firm agrees: "TOGAF consists of best practices, processes, principles, rules, guidelines, techniques – basically, a toolkit” A toolkit by definition is a kit of tools -- tools you use to build your house - definitely not the house itself, and not even the finished modular components of the house. Apropos, Viswanathan warns us that “A fool with a tool is still a fool." i.e. we need to have a healthy expectation of what the tools are for, so we can use them properly.

See the full discussion about fools with tools here:

 http://www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/#6e21c97245f1

Being a firm believer in the power of visuals to bring out insights, I hope the following attempt helps. I know I myself will want to see these notes again, when I relapse into my own confusion.

Check out this house, and the next.

And then the next below.

If you noticed something similar, you're right - the three were all built using the same basic framework. But each one was customized to reflect the preferences for taste, function, and other purposes known only to the homeowners.  The same goes for the internals of these houses - same frameworks, but the execution of details can vary depending on many factors.

Now please take a look at the fourth house below.

Clearly the framework for this bigger house is different. The point being -- the choice of framework matters because some frameworks might be too big for the occupants, or possibly too small.

Going over to another favorite analogy, please take a look at the next two vehicle frames. 

Do you notice the differences?

Both fundamentally have the same essential elements and shape for their framework. However, the construction and composition of the two frameworks are different, because one is built for rough and tumble, the other for smooth roads and speed. The first is for the Humvee, and the second for the Corvette.

Again, the point being, purpose and application are important criteria for selecting the more appropriate framework.

Now take a look below at the advantage of a framework which is deliberately "vague" and more bare-bones to the essentials. This kind of framework gives you the openness and flexibility to express the full potential of your vision. 

Lastly, I would like to leave with the picture below of what should be the whole EA landscape. 

Again the picture above includes the essential elements of enterprise architecture, to which  I pose the question:  

Would there be an organization -- so experienced in systems development, and deep in their artifacts inventory, that they can run off with this fundamental EA schema, and devise their own framework?

What do you think?

I quite understand that active discussions can be a sign of attempts to resolve confusion. However, I would think that this should only be to a certain point, and we need to check if we just need to go back to fundamentals to get back our bearings. As I mentioned elsewhere, I can see why Allega said "framework debates are irrelevant" Hopefully the sigh was not too long.

Cheers always, and let's try to keep it light. 

Addendum:

Some good references which maintain consistent terminologies regarding frameworks.

Cameron, BH., McMillan, E. (2013). Analyzing the Current Trends in Enterprise Architecture Frameworks. Journal Paper. Journal of Enterprise Architecture.  http://ea.ist.psu.edu/documents/journal_feb2013_cameron_2.pdf

Urbaczewski, et al. (2006). A Comparison of Enterprise Architecture Frameworks. Journal Paper. Eastern Michigan University. Issues in Information Systems. Vol7,No.2.  http://ggatz.com/images/SOA_COMPARE.pdf

Open Group. (2001). Other Architectures and Architectural Frameworks. Web Article. The Open Group.  http://www.opengroup.org/public/arch/p4/others/others.htm

Walker, M. (2013 Feb 10). TOGAF Demystification Series: Comparing TOGAF To Other Frameworks. Web Article. http://www.mikethearchitect.com/2013/02/togaf-demystification-series-comparing-togaf-to-other-frameworks.html

/

ERP: A Reference for Future State vision

Alignment needs a lot of work.

Len Fehskens of The Open Group points out in one interview that "although EA is becoming popular as a tool for managing change, the real focus should be on EA's role as a tool for alignment".  No doubt this deep insight rings true. But while the EA work of painting clear pictures and models for future state alignment is quite an involved undertaking in itself, the real work lies in achieving that alignment through the widespread enterprise changes that the organization needs to make. After all, when we speak of alignment, we speak of future states to which the current states are transformed -- in order to execute strategy. Thus, alignment is essentially a collective set of abstractions, which translates into actual transformational tasks during implementation, and critically calls out for change management.

The target ERP system as the vision of Future State      

An ERP system usually comes as a software package which already embodies defined processes for various business functions. These come as modules which collectively provide future state capabilities in the primary business areas of accounting and financial control, logistics, and human resources.  For example, the logistics components of an ERP system will include Materials Management, Sales and Distribution, Production, Customer Service, Quality Management, Plant Management, and Logistics Control.   Thus, a complete ERP system solution embodies the possible future state for the organization.

A serious commitment - financial as well as organizational.

An ERP solution is a long-term fixture for the organization and will affect its people, processes, and technology use for many years. As such, ERP solutions carry a substantial cost impact.  Although the costs for ERP packages vary, they are all expensive tools relative to the financial posture of the acquiring organization.  Moreover, as it is often the case, the system implementation itself is always an even more expensive undertaking.  Thus the wrong choice of ERP software, as well as the wrong formulation of the implementation methodology, can be a critically costly disaster for the company if the selection methodology is not carefully defined and executed.

The painful lessons of ERP implementations.

In the late 1990's through 2006, I worked on perhaps one of the largest global SAP ERP projects at that time, and was done during the wave of international mergers and acquisitions spree by the holding company - reportedly one of the most aggressive M&A strategies executed in the market at that time.  One can only imagine the integration nightmares in this context. I was on the Data Architecture team, and the Enterprise Architecture (using our current definition without the labels), was coordinated with PwC consultants. We were closely watching the lessons learned from the nearby company at Hershey's, as their ERP implementation lessons were unfolding while we were doing our own project.  At its peak, particularly during the so-called blueprint phase, the ERP project flew in selected functional representatives as teams from different countries into the dedicated ERP project headquarters -- which housed 250 personnel -- easily, at any given time.  Hundreds of man hours in meetings (average per person) with the goal of checking alignment of functions to each group's business objectives, and how current processes will need to be transformed.  It was not an easy process, and there were a lot of politics and cultural clashes as well. I remember the Japanese team came on a Wednesday morning, had lunch with the German team, and on the next day stormed out of the project building to fly back home because they could not agree on which country would do the pilot for the first module.  All in all, that ERP implementation took 8 years to complete, for all planned global rollouts.

EA and the Selection Process of Future State solutions.

It has been said that the effective EA program institutes a collaborative, shared planning process. EA teams work with business and IT stakeholders to define a future-state vision in terms of requirements, principles and models. The process of enterprise software selection is critical to the overall success of the enterprise software implementation.  Done properly, the selection process ends with a best-fit solution for the organization, and enables the implementation to proceed on strong cadence.  Weakly executed, the organization ends up with a poor choice for its enterprise tool, and often falls into a nightmare -- spending a lot of organizational time and effort to force its implementation.

Given the significance, The ERP solution must therefore be correctly selected for best fit along primary notions -- not only of functionalities, but also for overall strategy alignment, organizational culture and capabilities, and emerging trends.  ERP customizations is another critical area for review, since these customizations add complexity to implementations, can make downstream upgrades more difficult and expensive, and therefore increase implementation cost, and risks - often exponentially. Moreover, a properly executed selection process includes methodical reviews which enable the organization to establish correct placements for expectations of time and budget of the implementation. This also enables assessment of compatible roll-out options for implementation such as big-bang, phased or hybrid. 

"Change Awareness" As a Critical Success Factor.

An organizational culture which has a depth of understanding and appreciation of "change" is critical to the successful implementation of an ERP system.  I think many ERP implementations fail because many of those organizations come short of understanding that they are about to overhaul the way they do things as an organization. An ERP implementation is indeed an organizational transformation. The enterprise-wide nature of an ERP implementation needs to be recognized as a project which is large and complex by definition - and the set of changes it will bring is always large and complex relative to the scale of operations.  To achieve success, the ERP implementation team and the organization at large must develop the proper attitude towards change.  The whole organization will have the commitment and the discipline required for the challenging work, only if they have a solid practical understanding of the nature of changes i.e.  The need for them, what causes them, what they cause in turn, the rewards they bring, the ownership and responsibilities, and the options available to make change-related decisions.  Thus, understanding change translates to a full appreciation of the impact of changes -- not only on costs and schedules, but on stakeholder relationships, and the continuity of operations.  Change awareness enables collective decision-making to be done from a better frame, and avoid underestimating the scope of influence for changes.

Conclusion - The Need for EA in Effective ERP implementations

Thus, if organizations look at ERP implementations from the perspective of transformation, and integration - as they should, we can really never over-sell the utility and need for EA as a contributing factor to a successful execution. And if an EA team is under-utilized in an organization, this is not completely the fault of the team, but rather the lack of definition for the role, and its potential impact to the business in general - beyond the confines of IT.

Here are some statistics to warn against the treacherous roads, when looking at ERP solutions to frame the organization's future state.

• One of the world's largest candy maker failed to deliver $100 million dollars in candy for Halloween 1999 after a troubled ERP implementation caused serious operational problems (CIO Magazine).
• 61.1% of ERP implementations take longer than expected (Panorama ERP study).
• 74.1% of ERP projects exceed budget (Panorama ERP study).
• 2013 one out of three of ERP buyers did not even demo a product before buying it! (Capterra).
• 22% of companies surveyed reported they just bought the first system they looked at (Capterra).
• 67% reported that they need a solution with more industry-specific functionality than their current ERP system gives them (Mint Jutras).
• 21% of ERP implementations fail to deliver significant business benefits (Panorama ERP study).
• 58% of manufacturers report they are doing too much non-value added work (double entry in multiple systems) which is impacting productivity. Why? Because they are not using an industry-specific ERP system (Mint Jutras).
• 40% of ERP implementations cause major operational disruptions after go-live (Panorama ERP study).
• 23% are unable to grow their business as quickly as they would like and believe this to be because they lack the tools they need in their current ERP system (Mint Jutras)
• 28% report being unable to serve their customers as well as they would like due to a lack of functionality in their ERP system (Mint Jutras)
• Only 15% of survey respondents installed "plain vanilla" software without any customizations.

References:

• Michael Krigsman. (March 1, 2011). 2011 ERP survey: New IT failure research and statistics. Web Article. ZDNet. Retrieved on Feb 10, 2016 from http://www.zdnet.com/article/2011-erp-survey-new-it-failure-research-and-statistics/

• Jeanne Lee. (Oct 31, 2014). 9 VERY Scary ERP and ERP System Implementation Statistics. Web Blog. Retrieved on Feb 10, 2016 from http://www.erpvar.com/blog/bid/108723/9-VERY-Scary-ERP-and-ERP-System-Implementation-Statistics

• Eden, C., Ackermann, F., Williams, T. (2005). The Amoebic Growth of Project Costs. Project Management Journal Vol 36.2: 15. Also retrieved from http://www.csb.uncw.edu/people/rosenl/classes/OPS100/The%20Amoebic%20Growth%20of%20Project%20Costs.pdf

• Kotter. Leading Change, Why Transformation Efforts Fail. Harvard Business Review. Retrieved on Feb 10, 2016 from http://www.srfmr.org/uploads/teaching_resource/1396040272-211c50caa4635c59b/Leading%20Change.pdf

ERP: Force Jumping to Unification Stage 3

The deeper insights from our course continue to clarify how Enterprise Architecture is the embodiment of business strategy with a technology execution. Once defined, and portfolio of initiatives sorted, EA is supposed to execute on strategy through vehicles popularly known as projects. The following is based on a true story and is a retake from another case analysis I worked on recently, and now with an EA perspective. This blog is an attempt to see the EA principles at work in this company's transformation via an ERP implementation.

Hello Growth, My Name is Change.

In early 1993, ABC was a $500 million company. ($830 million in 2015 dollars). The business wanted to grow towards the $5 billion mark, and needed a better IT system to help them achieve the goal. Similar to how most of the ABC organization was managed, IT and its systems were centralized, and used a Unix-based solution to support its core processes to service Financials, Manufacturing, and Order Entry (Sales). At that point, the system had become too customized and was in "spaghetti" state, and ABC wanted a better system which has more redundancy (fault-tolerance), is more reliable, and is easier to maintain. ABC felt that they have outgrown the capacities of their then current vendor, and rather than get an upgrade, The CIO wanted a new solution and support from a larger vendor.

Moving Out of a Conflicted Operating Model.

The CIO's management preference was to let each functional area make its own decision regarding budget and expense schedules for their own applications, as long as these are within the IT framework of standards and common architecture that he has provided for the organization. If I read the ABC context correctly, I think the CIO wants to focus decisions on technology requirements for IT's policies, standards, and architectures, but would rather push budgetary decisions on IT expenditures to the respective functional areas. A model mixed between standardization and diversification - a limbo of sorts. However, this approach was not compatible with the nature of an ERP implementation. Such implementations demand an integrated, holistic approach which requires functional areas to coordinate tightly in order to arrive at a truly integrated solution. This would also mean that such coordination required that budget and implementation decisions need to be made collectively, from a systemic enterprise-wide perspective, rather than from disjointed autonomous functional areas.

This conflicted view of the landscape produced inertia at ABC. On one hand, The CIO had an initial inclination to avoid an ERP solution, which is understandable, because of valid concerns that such solutions can become runaways and turn into costly "mega-projects". On the other hand, The CIO's management approach of a distributed autonomy, to my mind, would also raise concerns within the organization because the functional areas can easily run towards going their own ways, and build disconnected systems which fail to integrate and fail to communicate with each other. Thus, these two conflicting sentiments can become circular dilemmas which could be enough to feed the organizational inertia towards an ERP solution.

The Engagement Model. Breaking Inertia with Governance-PM Alignment.

From a reactive disposition, there's no better way to really kick start an organization from inertia than having a real palpable threat of an imminent massive system failure -- partly this was so at ABC. But general wisdom tells us that proactive measures supersede those which are reactive. To set things in motion, and achieve the required organizational velocity, ABC did  two things proactively: 1.) They assessed their Enterprise Architecture, IT Governance, and Project Management processes to develop and apply best practices in order to increase the chances for success of a true ERP implementation. 2.) They combined the best practice methods for cost and value management; with best practice methods for risk management i.e. risk identification, assessment, and response formulation. All together, building these first-order capabilities enabled the ABC organization to identify and plan for viable options. More important, these capabilities enabled the organization to make well-informed decisions for choosing and implementing the best-fitting approach, and the most effective solutions that will achieve their strategic objectives.

EA Initiatives - Preparing for Transformation. 

ABC understood from the get go, that this is not called "transformation" for nothing. This is a big deal, and they went through steps that could teach us well.

#1. ABC's decision to understand the ERP implementation's impact to overall business strategy and vision was critical in providing first-order capabilities and facilitated downstream enablers to make the organization overcome the challenges ahead. This allowed so-called "sense-making" to happen, particularly in the organization's leadership, and clarified the high priority that the implementation project deserves. It is the commitment from senior management which facilitates buy-in to happen across all levels of the organization. Thus, such depth of understanding helps the organization plan for, and manage the enterprise-wide changes that is about to unfold, and keeps all areas and levels of the organization steadfast when push comes shove, during the most trying and stressful phases of implementation. We catch an insight of this depth of understanding and strategic vision, when the CIO said "Cost avoidance [at this point] is not an appropriate way to look at the choice of a solution".

#2. ABC assembled a great implementation team for the project. For the internal project team itself, they hand-picked the best and brightest business analysts, even if this means that they will be taken away from the functional area. Clearly, ABC has achieved the project-oriented mindset. ABC chose the right vendors at the right time as part of the project team, with Oracle poised to bring its ERP solution commitment, and the expertise and advisory of KPMG for its end-to-end implementation. KPMG had the depth of understanding of ABC's needs, and were the architectural technologists who provided the integration guidance to make the solutions all work together. Moreover, ABC understood the demands of projects and installed effective IT governance mechanisms to provide oversight and control of the project. Their choice of leadership for the Executive Steering committee provided high level sponsorship, effective project visibility, and sustained motivations for the project organization. It is particularly noteworthy the way they deliberately made use of steering committee meetings mainly as an event for celebrations, rather than the typical checkpoint sessions. This again indicates the advanced mindset and level of maturity of ABC as an organization which sets them apart from others.

#3. ABC formulated an aggressive project strategy, and delivered with determined execution. The project contract strategy of "buying the capability" -- versus buying hardware and software from vendors, proved to be a lifesaver for the project when capacities where not performing to expectations prior to go-live. This was brilliant. Often, less astute organizations will contractually formulate acquisitions based on delivered software, hardware, and customizations without clearly defined and effective parameters for SLA's. Every organization should learn how to effectively embed guarantees in their contractual agreements. Moreover, there's the implicit wisdom of buying critical ERP components from one vendor - in this case Oracle. Many times project management is caught in the middle of the cross-fire between the software vendor and the database vendor pointing fingers when it comes to system performance failure. Although not exactly applied in this case, the notion of prime contractors to handle such conflicts is an important strategy to consider.

Unchartered Waters - Risky business even for a smart company.

This was one of the earliest major ERP implementations in the U.S., and many things were done which most likely increased the risks for the project, and perhaps indicates that risk management could have been done better by the organization.  On hindsight, they did two major risky moves:

#1. Going with the Big-Bang approach. Although they had an idea of the extent of change impact on various areas of the organization, I think they still underestimated the effort, perhaps influenced by their desire to pursue aggressive schedules.  It was only later, through the due-diligence phase reviews, did they began to realize that their core systems need to be changed, and an overhaul was needed to get it right. Changes were done to the extent of renumbered customers and renumbered products, and thus imply fundamental changes to master data, a large effort for conversions, and overhaul of data structures. As Ross warns us - Don't skip stages -- it can be very risky.

#2. Trying to meet aggressive schedules at the risk of quality and completeness. Indications of risky short-circuiting of process by forcing people "to nod" and say yes, even if the functional areas are not completely convinced that they are ready to say so. There were partial system tests, and water-downed due diligence, all to keep up with target deadlines, while increasing the potential risks when systems go live. ABC took the odds, and decided to go live on both the ERP system and the "bolt-on" package -- on the same day. This again was aggressive, and could have been a very messy and costly affair.

I myself have worked in quite bold project environments, with very aggressive and ambitious project targets and deadlines. Often we see these as a result of the demands of business pressure and the extreme competitive nature of the client organization. It would not be an overstatement to say that ABC embodies such a competitive posture. This is not necessarily bad, but we do need to consider caveats.

Conclusion - Organizational maturity saves the day.

ABC eventually was a successful ERP implementation, four years from concept phase. They did a lot of smart things. And although the risky things were few, they were significant enough to potentially flip the implementation into a costly disaster for the company. Thus, ABC as an organization was, and is, incredibly smart; but at the same time, was incredibly lucky to have pulled off the ERP implementation of 1995. ABC was both smart and lucky i.e. if we subscribe to the notion that luck is not 100% random.

To explain, we go back to ABC's organizational maturity, and project-readiness.  I use the term "organizational maturity" not in a loose way, but different from the maturity of architectural stages that we are studying. I actually think that ABC was not completely Stage 2 mature before they jumped to Stage 3 with the ERP implementation, and perhaps accelerated pursuit of Stage 4. Organizational maturity and project-readiness simply speaks of certain capabilities that the organization has achieved that enables the organization to address the challenges of IT initiatives such as an ERP implementation - their cultural readiness for change. There are simply projects that are "age-appropriate" if you will allow the metaphor, and an ERP implementation requires "age-appropriate" handling. I'll write about the change management and culture in my future blogs.

The key illustration that smarts and luck were at play was in the partnership of ABC and Oracle in order to accomplish the feat that they did on this project. ABC was smart in their strategies, one among which was that of procurement which we refer to as "Buying Capability" only possible because they shrewdly understood Oracle's own motivations for wanting to be part of the high-profile project - Oracle was hungry for a win for their new ERP product.

In the final assessment, we applaud ABC for all the smart moves they made, as well as for the gutsy decisions they called, in order to reinforce their competitive position in the market. However, we do need to place the strong caveat, that some of the things they did are not for all other organizations to attempt. I believe the ABC organization was able to overcome the risks because they had the sufficient maturity of capabilities, and the readiness for the challenges of an ERP implementation project, as they did. After all, this is ABC - a legendary company known for its smarts and good fortune. It is not surprising that they now enjoy a market cap of almost $112 billion, and reporting $12.6 billion in revenues in 2015.

That's it for now. Next week I'll reflect on my own experience with a large global ERP implementation.

Cheers always. Keep it light.

/