Culture is everything - Signing off

The most important part of EA is having fun while doing it as no one will want to be part of an EA initiative that doesn’t. In every business there are compliance requirements and mandates that require teams to do work they might rather not which is why having the right culture is so important. Is it imperative that the Chief Architect sets a tone that makes the EA process approachable because this will lead to increased participation and cooperation. If stakeholders dread your meeting then they will find every possible reason to get out of it and pretty soon they will delegate their role to a subordinate if they can. Shortly afterward one will have room full of subordinates instead a room full of decision makers and every time a decision needs to be made each subordinate will need to scurry back to their boss for feedback. Of course since the boss hasn’t been to the meeting and probably hasn’t read any of the emails guess what… Someone gets to explain to him or her second hand what’s going on. It’s like a bad game of telephone but with really important stuff. And if a single participant is causing the EA meetings to take the wrong vibe – get rid of them. I’m not saying get rid of the problem stakeholder necessarily – I’m saying call them out and then tell them if they are not on board, there a door in the room they can choose to exit from.

So think about the following each time you schedule a meeting: are all the participants really needed or are you just sticking to a list of everyone. Be a good steward of people’s time and they will be grateful for it. Next time you schedule a meeting that they really DO need to attend then they will be receptive to the request. This is especially true if the EA meetings have a good tone. It’s just EA – no one is going to die if things don’t turn out perfectly and mistakes will be made. This should be expected as EA is an iterative process through which value will be increasingly apparent as the EA initiative grows in maturity. Articulate and document the value EA brings in a way that is not debatable except for the amount of value it brings: significant or very significant. I’m not saying it  will be easy as most things in life that are valuable are not but perception is reality to most in today’s hyper-connected world. The perception that EA is not culturally aligned with an organization will kill the program as fast of not faster than if one has a poorly designed and executed program.

So make EA fun and people will spread that good word around the water cooler.

Perception = Reality.

In business the context usually looks like this: “Customer àBusiness à IT” and this can cause major problems in planning cycles. So if and how can one identify predictive statistics and employ them to reduce the lag and have IT & business together calibrate to customer needs quickest?

There’s no magic bullet but Weiss puts forth some greatly helpful suggestions in the “Introduction to Business Context” article. Since every organization is different each organization should pay attention to environmental trends first and also stay on top of emerging technology and trends also. Paying attention to these will help business and IT stay future focused. This also means staying on top of the Common Requirements Vision and updating it at least yearly. It is essential that EA teams revise the CRV frequently especially as the pace of technological improvements increases.

The one Weiss quote that sticks with me most is the following: “The business context is the step in the EA process that combines the analysis if environmental trends and the business strategy and directs the EA team effort in the creation of the future state.”

EA Measurement - How not to fail

Measurement is critical to any business initiative in today’s business climate but the mountains of data collected by various business applications can also be detrimental. Agonizing over metrics can reduce speed to market, by creating a culture that needs to “fully” analyze data before decision making. Gartner’s “Why EA Measurement Programs Fail provides a simple high level viewpoint of what to avoid when constructing measurement programs. The validity of the article became apparent when looking back at a past business interaction from several years ago.

Management wanted to institute a new time management program and track time everyone in our division was spending on various activities. Sounds all fine and good, right? WRONG. Management decided to have everyone track their time in 6 minute increments (one tenth of an hour) because that was what other companies were doing and justified it by stating it was  industry standard. It was a way to reward our productivity and gauge the IT tools provided to us. That’s not how it was perceived by the majority of the employees and this effected the results of the measurements.

One of the core tenants of the company had always been having a client focus and to the employee base this new time tracking standard was seen as micromanagement. It took away time from clients and put an undue burden on the employee to manage this active metric (most metrics gathered by the company were passive). After a few weeks of adoption and correction to standardize the compliance department who was running the time tracking measurement program touted their progress and how the program was giving them insight into how time was spent for projects vs.  support vs. administration.

However, there was an elephant in the room they could not see. There were no controls around how employees were entering their time. After being questioned on “why an entry was a certain way” and/or “what one was doing” employees began constructing their time cards in a way that corresponded with what the compliance department wanted to see. There were few controls around this active metric so compliance thought they were seeing improvement when in fact all they were doing was scolding employees into cooking their timecards. All of the employees were on salary so it had no effect on payroll dollars, but invalidated all of the measurement that was being done by compliance.

The measurement program was not well explained, aligned with the company culture so it was not trusted by the participants. Needless to say it failed after a couple of trying months. Measurement programs must be well articulated to those being measured in order to build trust in them and around them. If the participants can see the program is designed to furnish them with better tools and the right resources for success – the measurement will have value and garner support. 

Works Cited

Weiss, D. (2006). Why Enterprise Architecture Measurement Programs. Stamford: Gartner .

Governance in IT Projects

Over the course of the last several years as project manager I’ve seen an increased interest in data security and this is a wonderful thing. After several high profile leaks of personal information companies across the world are finally understanding the need for a practical and deliberate approach to governing company-wide IT systems. It’s not flashy, it’s not going to get customers to love you but it is a cost of doing business. On top of that if you don’t do it, you might not have a business to run if things go wouth. The quickest way to lose credibility is to be wreckless with something someone else values – not to mention if it’s something personal – and every person involved in the EA governance process should know that:

We are steward of the data we collect – we don’t own it.

Adoption of EA processes including an ARB and a robust governance process is integral to standardizing security controls across a company. The ARB must perform a risk analysis and vet each and every project according to its level of risk and complexity. It is imperative that EA team befriend and work closely with project teams to understand the scope of each project because EA program should not be involved in day to day project work. EA should act as gatekeepers at major milestones of the project or at the very least during the planning and closeout stages of projects. Too much EA involvement can be as bad as too little.

So keep it simple – where and whenever possible. 

Roadmaps and SaaS

Continuing from last week’s post about Old roadmaps being dangerous this week I’m going to explore some thoughts on how the increase in subscription based SaaS applications can affect EA roadmaps.

So how do Cloud based SaaS technology affect EA roadmaps?

The power of SaaS lies in the fact that the purchasing company doesn’t own a soon-to-be outdated technology. The cost of the applications is spread usually across a number of years and as the software vendor updates and upgrades the application, these features are made available to the purchaser. This means for outsourced services like purchasing or HR software the EA team needs to keep aware of the SaaS vendor’s roadmap and identify if it affects their own. Also, at the expiration of the contract the EA team should be evaluating that SaaS and making a recommendation on how it fits into the current and future company EA.

This breaks the old model of: Emerging à Production à Legacy à Exit.

A good SaaS company stays relevant through the adoption and deployment of new technology so the application never reaches the legacy stage without a major market shift. Yes there will always be new trends but companies will always need to manage the HR process and purchase items. The question is how can the SaaS enable and automate those processes so company employees can spend their time doing what the organization hired them to do. In addition, a company only needs to administer SaaS and not maintain the code freeing up IT and EA resources to focus on the company mission.

I see the new model as: Implement à Deploy à Adopt à optimize (and don’t stop)

Unless there is a strong reason to implement a new solution, companies who leverage outsources SaaS applications can stay in the optimize phase. To me, there is a strong value proposition in in the reduced costs of optimizing versus implementing a similar solution every few years. Your get new tools right away, the key is being agile enough to pick them up and use them. 

Old Roadmaps are a Dangerous Thing

Old Roadmaps are a Dangerous Thing

I think I have seen about a thousand roadmaps over the course of my career, some great, some needed to be burned. Having a time phased plan for improvements is critical to the success of any business but what is just as important is how often that roadmap is reviewed and how flexible an organization is with that plan. Roadmaps like many EA artifacts can quickly become dated so EA teams must be ready to make a new plan as market conditions and technologies change.

Once upon a time I knew a Senior VP of a company and he was incredibly inflexible even in the face of strong evidence that market conditions were shifting. He still lived in the word where technology was something that helped the business run but did not have the role of connecting the organization to the customer. He had a talented and experienced IT Corporate IT team that could have transformed the organization into an industry leader but lacked the vision. His roadmap looked like the ones that had been presented for the previous 10 years, so results suffered.

So where did he go wrong? What should he have paid attention to? Did he miss a roadsign?

1) Company and EA Leaders must be visionaries. No vision = your company is roadkill in today’s Hyperconnected economy.

2    2) One needs to be able to translate that vision into incremental activities that are appropriately stratified.

      3) Roadmaps are necessary, but like Rand McNally they have to be released a minimum of once year.

      4)  The new roads, while less traveled are the ones EA and company leaders need to be aware of. If you are that proverbial gas station on the corner or Main and Park and there’s a new interstate allowing traffic to bypass that intersection, time to rethink your roadmap.

      5)  If there’s construction (market turbulence) make sure your roadmap reflects this. Will it last for one year, or five?

      6)  If there’s no good roadway option, maybe it’s time for a new road. 

      Have a safe and happy Independence Day 

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.