Vision in Project Management: Bridging the Gap Between EA and Project

There are so many details in IT Application implementations that many EA Teams do not have the time to be involved with. This is a critique, not a criticism. Many decisions are made “on the fly” by the functional lead along with consensus by the rest of the group but this can be problematic. Quickly made decisions lead to quick action but that does not mean the time has been taken to evaluate the appropriate viewpoints. To truly address this, a cadence needs to be established that bridges the various constituencies, with a “just enough, just in time” approach. Phasing meetings throughout iterations of a project consistency in the exchange and evaluation of ideas from multiple levels of an organization. This includes regularly scheduled feedback loops through which EA team members can act as gatekeepers for the local project level decisions.

Additionally, the stratification of each meeting should scale across meetings so that non-pertinant stakeholders are not involved in discussions that don’t require their input. Being respectful of each and every parties time, large and small, will win a project manager’s favor. The establishment of that trust can be a foundation that the EA team builds with a vendor concurrent with the implementation. A project manager is a relationship builder and E A teams should take the time to integrate EA tasks into their actives.

EA teams should use Vendor Best Practices to Shake the Tree

A Best Practice Configuration is something that many Software as a Service companies bring to implementations but in my experience getting clients to adopt them is difficult. Personally I believe this is a byproduct of the paradigm shifts between old school On Premise products and the new school Cloud Based solutions. In order to service the greatest number of customers and implement in the least amount of time some level of standardization must be achieved and leveraged. This also leads to client pain points when their internal processes don’t align with vendor best practice, or their EA program is not well developed.

Having EA guidance when choosing a vendor is a practice most organizations follow but their continued support through the implementation is where additional value can be found. EA teams should provide guidance and governance on project teams, not just take a supplementary role. Waiting for project team members to ask for EA assistance ignores a common problem: without EA being fully involved in project activities project team members unintentionally miss opportunities for EA involvement. Application implementation often involves several functional teams such as H.R., Accounting, Compliance and IT and understanding those interactions are critical to the process improvement that lead to improved Solution Architectures and new iterations of the Future State Architecture. In my experience functional departments are the slowest adopters of change and often hold on to a way of doing things because they are comfortable with them not because they are actually optimally configured.

EA teams should use implementations to further realize EA value and adopt vendor best practices when possible. By actively participating they will make functional departments accurately articulate their needs rather than accepting the status quo. By challenging them, and then listening, EA teams will gain a greater understanding of not just what these departments say they need, but what they actually do.

The Shift from On Premise to a Cloud Model and EA

Getting involved in the strategic planning of an organization is essential for all EA teams but in order to make the greatest impact. EA teams needs to consider how the strategic shift to cloud based applications affect their planning and implementation cycles. Over the last several years software giants have slowly began to embrace and implement cloud based solutions even for core IT systems such as ERP, CRM and HR. Cloud based applications are sold on a subscription model which allows EA team to set terms of those contracts and also more effectively plan for when procurement cycles need to occur for various enterprise applications. Furthermore, with more frequent product releases and approaches such as agile scrum organizations need to be increasingly ready to incorporate new product features into business models if they are to keep up with the increasingly changing marketplace.

 In the past, an ERP system might be used for 10-15 years with few changes in capabilities. EA teams built documents and aligned strategy around what the ERP could do and this worked. In the next 10 years as most companies shift to cloud based applications for the majority of their core systems it becomes incumbent on EA teams to modify their approach with more frequent updates to the “Future State” model to reflect these changes.

Heller does a great job of reflecting on this in an Oracle centric way in Public Cloud: The Next Frontier of Enterprise Architecture ( http://www.oracle.com/technetwork/articles/entarch/oeea-public-cloud-next-frontier-2400599.html ). He points out that data integration, business process understanding, security and finally business intelligence are four dynamic challenges that must be managed if organizations are going to succeed in building a competitive advantage. The standardization of these many applications in a Cloud Suite can be a powerful tool for many of their clients, however there is a bit of nativity related to organizations purchasing their IT products from one vendor in a Stack as suggested. No one company is best-in class in every aspect as there are many vendors who unlike Oracle focus on verticals or micro-segments of the overall software market. In the future to avoid the problem of middleware ERP teams should consider and purchase products that offer connectivity outside of a product stack of one of the software behemoths. Every organization should be able to purchase and connect the products that are the best for the business needs of their organization without constriction. Software companies who support this flexibility will lead their individual markets as I believe the software stack will wane in strength within the marketplace.

EA teams can’t wait for this to happen to change their thinking and should always seek the best solution for their business.

Works Cited

Heller. (2015, January). Public Cloud: The Next Frontier in Enterprise Architecture. Retrieved June 2016, from Oracle : http://www.oracle.com/technetwork/articles/entarch/oeea-public-cloud-next-frontier-2400599.html

Operating Model Changes Must Align with the Company Culture or Choose to Intentionally Break it

A several years ago I was part of a company servicing the Higher Education Industry that changed its operating model and I can say it was a less than fun experience. The company moved from a diversification model to a replication model in order to address what was a changing industry. Deregulation has removed barriers to entry and new competition was driving down both sales and margins. Additionally, the workforce was aging and as employees retired their institution knowledge and connections were lost.

In the past, team members would spend 30 years working for this company because each location was given significant freedom to cater to their unique market and the bonus structure was configured to significantly reward that knowledge and hard work. Inventories and purchasing were managed locally as each market was unique and the people who were in that market knew it best. Only HR and payroll were housed at the corporate office in the Midwest and most other IT decisions were made by the local management.

When the industry was deregulated, these colleges and universities had to publish what had previously not fallen under the Freedom of Information Act. The moved the power from the seller to the buyer and increased competition. In efforts to keep pace with the changed landscape the President of the division I worked for began the shift to a replication model. Purchasing, Marketing, inventory management and other core aspects of the business were one moved to corporate control out of company headquarters. In theory this was a solid business move as it would allow for standardization and replication across the several hundred locations. However, what occurred was a dilution of the culture and uniqueness of each location.  Every college and university has a different look and feel and that was translated by the local staff into sales. Those at the HQ office had no idea what each location was like nor had they ever visited most of the schools. Local managers could make suggestions but actually getting something approved took so long the business opportunity was often gone by that time. Additionally local vendors who had been doing business locations for decades were shut out because central purchasing was not willing to purchase for just one location and these local products were what sold well. Central purchasing ordered standard items from national vendors and the local stores lost their identity.

After a couple of years sales continued to decline and management placed the blame at the local level. They stated we were not executing the plan and we stated the products they provided were trash. It wrecked the existing company culture, caused many experienced team members to move on, and it took a couple of years for the new operating model to establish itself. That said, this shift in operating model did allow the company to sell off this business unit several years later even though the industry was in continued upheaval. It could be described as successful depending on the viewpoint one takes.

So as one thinks about changing an operating model consider this:

How will you mitigate the short term turbulence so you can best get to the long term gain an operating model shift can provide?

Don’t throw the baby out with the bathwater.