Enterprise Initiatives

There isn't a day that goes by were I don't encounter an EA blogger who states his dislike for process. Earlier in my career I was very anti-process. I was working on small teams and sometimes I was simply the only one on the team. There was no established architecture and no standards. Since this was the norm and nobody cared, why bother me with tons of documentation. As I moved through my career I worked on larger projects that spanned multiple user groups and application silos. Suddenly, the lack of process became a recipe for failure. Now I am working on enterprise BPM and SOA initiatives that touch the entire company and practically every application under the sun. Process and Governance are now critical success factors.

For those who don't like process, I can meet you half way. I believe in a lightweight process that supports agile development but not process that creates bureaucracy and results in 12-18 month projects that are doomed for failure. My current project requires more process then any project I have ever worked on before. In the past I would typically scoff at project charters, team structure documents, accountability matrices, and all of the non technical type of artifacts. But this project consists of a consulting partner, that is half on-site and half remote, multiple internal application teams working on integrating various legacy systems to the new business workflows, an offshore support organization who will take responsibility for the code once it is approved through UAT (user acceptance testing), and business representatives from multiple departments. In addition we are working towards 12 week deliverables where we work on multiple workflows concurrently that need to plug in together at the end. Try that without process. Are you kidding me? There are over 50 business and IT people involved, there has to be some order to the chaos.

The trick is to not create so much process that you stifle creativity and make technical decisions based on process instead of business need. At the same time we are new to SOA and must closely govern the architecture so we don't create a long term mess and not realize the benefits of EA and SOA. So does this make me a process weenie? I don't think so. I do know that our first attempt at this I blew off the charter, the structure, and the accountability matrix and that led to confusion towards the end of the project. Next time around we will invest a few days nailing those steps down to prevent chaos down the road. From that point on this stuff will be boiler plate material that will just need minor tweaks as we move from release to release.

I know James McGovern is going to beat me up on this for both the process stuff and the outsourcing. Outsourcing is a decision our company has made so my job is to make it work regardless of what I think about outsourcing. I can complain about it and allow us to fail or I can make it work. The more external people you have working on the project (especially remotely) and the more areas of the business your requirements span, the more process you need. I never thought I would be pro-process but when you are responsible for large initiatives with large budgets associated with it, you better deliver on time and on budget or you will be introduced to the exit interview process!

James always promotes people over process and I totally agree with him. However, the people must have the tools they need to do the job. One of the most important tools is clear direction and good communication. When you have 50 or so people on a project you need some process to supply these tools. I agree with James that CMM is overkill (unless you are sending a space shuttle to the moon), but there needs to be a compromise. So I'll lob this one back to my EA peers out there. I am sure some heated debate will follow. Your thoughts?

There are many critical success factors for implementing SOA. They range from strong executive sponsorship and business alignment to acquiring the proper talent and implementing the right amount of governance. But even if you have all of those ducks in a row, it all comes down to the basics of project management and leadership. The biggest challenges that I see implementing SOA are the same challenges that I have seen throughout my career implementing any other large initiative. This article called Avoiding Project Failure: It's not Rocket Science, gives an overview of the things that typically go wrong:

Typical problems here are scope creep, poor work-plan, lack of change control, poor communication and poor management of risks and issues.

The article goes on to state a few more killers:

There are many occasions during the lifecycle of a project for issues that may lead to failure. Examples of these include:

• Failure to define the requirements clearly, resulting in expectations not being met
• Cutting edge or new technology that causes unforeseen problems
• A poor technical design preventing the solution from being changed or scaled in the future
• Poor change control allowing change requests to cause the project to drift
• Changing priorities diverting attention away from core work

Since implementing SOA can be a culture changing event, the basic change management principles must be applied to prevent derailing the entire initiative. Here is a summary of the high points of this article:

1. Address the human-side systematically
   
2. Top level support
3. Involve every layer
4. Clearly communicate the business case
5. Create ownership, install change agents
6. Clearly and continually communicate the message
7. Assess the cultural impacts
8. Address cultural issues
9. Prepare for the unexpected
10. Define WIIFM (What's in it for me?) for each individual

I know that early in my SOA initiative, I spent most of my time digging into the technology. Once we defined what our target architecture was going to be, my role changed dramatically. I turned most of my architecture duties over to my enterprise architects and started focusing my energy on the project deliverables and the change management. I can tell you from personal experience that figuring out the target architecture was a cakewalk compared to what I am dealing with now.

So while many people lose sleep over the technical challenges of SOA, I stay awake at night worrying about scope creep, top level support, cultural issues, risk lists, and action items. If I put enough smart people in a "war room" I know we can tackle any technology problem, but coordinating the work of all these people is where the challenge is. The big challenge in my eyes is that SOA forces many different departments (inside and outside of IT) to work together as one cohesive team. This is not a technology issue, it is a people issue. So for those of you early on in your quest for SOA, don't under estimate the importance of project management and change management.

I posted this article called "Offshore blunders. Who is to Blame?" on CIO.com the other day. The story discusses a few case studies that I have personally witnessed over the years.

There are many reasons why offshore development fails:
* Resistance to Change
* Unrealistic Expectations
* Lack of repeatable processes
* Poor vendor management
* Poor vendor performance

Usually when there is a report of an offshore development project failing, the critics immediately jump on the anti-offshore bandwagon and declare that offshore development can't work. When you look at the reasons these projects fail (listed above) how many of these are the vendor's fault?

Resistance to change - This is the number one reason for failed offshore projects. Companies tend to ignore the basics of change management. The staff sees offshore as a threat to their jobs and becomes unwilling to cooperate and allow the vendor to be successful.

Unrealistic expectations - Some companies struggle to deliver so they think throwing projects across the ocean will solve their problems. If you can't manage projects onshore, how the heck do you think you can manage them offshore?

Lack of repeatable processes - Regardless of whether your vendor is CMM level 5 or ISO certified, your home based staff needs to have some form of process in place or your project will most likely end in a disaster. You still need to deliver the appropriate specifications to the vendor, have valid change control procedures, perform code and design reviews, and perform project management best practices to keep the project on schedule.

Poor vendor management - Shipping projects offshore may reduce the amount of development that you need to take on, but it increases the level of oversight that you must provide. Keep in mind that the vendor does not have the business knowledge that your staff has. If you let them make all of the decisions you are doomed for failure. Let them make recommendations, but approve all decisions.

Poor vendor performance - Ah, finally something I can blame on the vendor, right? Wrong! Who is responsible for selecting the offshore development team? That is the person who is accountable. This is no different if you performed a vendor assessment for a CRM package and you picked a package that did not meet the business needs. Is it the software companies fault? Will the CEO blame the vendor or will he hunt down the CIO?

Let me add that as a taxpaying American citizen, I don't like the fact that our beloved IT jobs are moving offshore. I can moan and groan about it all day long or I can figure out how to make it successful so I can satisfy my users' needs. As a leader in IT and a shareholder of my company, I understand the economics of offshore development.

IT is not the only industry that has been losing jobs overseas. Manufacturing and engineering jobs have been leaving the country for years. It just took a while longer for the IT industry to follow suit. Until our government gives companies incentives to keep jobs at home (don't cross your fingers on seeing this any time soon), jobs will continue to move offshore.

The next time you see an offshore development project fail, before you post your next "I told you outsourcing doesn't work" article, research the reasons why it failed. The odds are that they failed for one or more of the reasons I highlighted above. If that is the case, then who is really to blame?

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 2 I will focus on Lack of Resources.

What are some of the most common phrases you hear when attempting to promote change within your organization? The top one I hear is "I don't have time", followed by "I don't have money", followed by "I need more resources". These are the biggest cop outs in the world. The reason why nobody has time, money, or resources is because they don't put any initiatives in place that allow them to do anything other then put fires out.

At some point you should reach a threshold of pain and realize that there must be a better way. Everybody is working 50-60 hours, all the projects are late, production support continues to increase, and the users are screaming. Everybody is working hard, but nobody is working smart.

If this sounds like your shop, you might want to take a step back and put a plan together to stop the madness. If you owned your own trucking business and you spent most of your time repairing your fleet of trucks you would probably be out of business. So why do so many IT shops spend countless hours every day in repair mode? It's time to make time, time to spend your shareholders' dollars effectively, and time to maximize your precious resources.

Let's start with time. Where are you spending your time? Do you have any metrics that allows you to proactively manage and control your projects or your production support? In many shops, the main cause of all these issues is lack of a sound project prioritization process coupled with a lack of a resource allocation model. If projects get accepted at will, priorities change like the seasons, and you have no data to show that your resources are over allocated, you will become a reactive culture. If you are not practicing Portfolio Management, you should make that a priority (view this article I wrote on Portfolio Management). If you have no visibility into how much time you are spending in production support, what categories of issues you are encountering, and how long it takes to fix issues then you should make change management a priority. If you are meeting with the business to discuss the next wave of new projects and do not have a clear picture of your resource capacity, you need to start practicing human resource planning.

Next is money. Obviously, if you are spending too much time keeping the lights on then you are wasting money. But are you wasting money on infrastructure? Are you still pouring millions of dollars into big name vendors like Microsoft, IBM, Oracle, and HP? Are you paying huge amounts of money for "Gold Support"? You need to start evaluating Open Source alternatives. If you believe in the myths of Open Source, it's time you start doing your homework and read about these 50 Open Source success stories. Oh, and that Gold Support you are paying for each and every product...there are many Open Source Support Providers who can support a variety of open source products at a fraction of the cost. What is better is that these folks earn their stripes supporting customers and are actually extremely interested in helping you resolve your issues. This is their core competency. I wonder how much effort Big Blue would put forth to help a small $100M company resolve its problems. The days of saying, "Nobody every lost their job buying Microsoft and IBM" are long gone. If that is all you are buying you are definitely not seeing the big picture and your CEO might start giving you that look.

Are you still buying rack after rack of servers to support your test, development, staging, and production environments? Have you embraced Virtualization Software like VMWare yet?

And what about human capital? We already talked about spending too much time keeping the lights on and spending too much time maintaining rack after rack of servers. But what about development and testing? Do you have an architecture that allows rapid deployment and reusability? Have you separated your business rules from your applications? If your business rules are embedded in your applications then you are creating additional work to maintain and test your applications thus increasing your chances of creating defects.

Let's say you are a retailer with 1000 stores and you have a business rule for defining what a high volume store is. You have several different systems that use this business rule (billing, inventory, eCommerce site, financials, etc.). Now you want to change the definition of a high volume store. You now have to make that change in each of these systems and implement all of the systems at the same time. This simple change has turned into a project. Wouldn't it be better to go to one place, make the change, test it in one place, and roll? You don't need to practice agile methodologies to be agile. You just need to be smart! My recommendation is invest in your architecture. Create a business rule layer that sits between your applications and your presentation layer. I would go one step further and create a service layer to orchestrate your business rules and allow other applications and/or customers to access your business rules.

Well, I have rambled a lot longer then I usually do so I will pause until part 3 which focuses on Lack of Tools. I will add a conclusion after part 5 that tells you how to prioritize these initiatives and how to get started.

A good buddy of mine forwarded me this article from eWeek by Deborah Perelman. The following quote from the article summarizes the content: “In the simplest terms: too many IT workplaces have become Dilbert-ized—micromanaged, bureaucratic and stifled creatively. It's become an environment where busy work is praised and morale is low.” The article talks about IT as a commodity with trends in outsourcing. Flextronics CEO, Michael Marks, goes one step further in this Businessweek Online article Design is a Commodity. He recommends outsourcing the engineering process for electronics.

How did we get here? In my opinion, IT has done this to itself through the years due to the following reasons:

1) Not working closely with the business

2) Inability to successfully manage projects

Let’s talk about the first point. In the 60’s and 70’s, the business was dependent on IT for information. There were no high powered PCs and the Internet was not for commercial use. Most of what IT worked on in the public sector was business enabling applications. During the 80’s and 90’s, huge advancements in processor speed, memory, and disk technology enabled personal computers to do the work of the massive mainframes from the previous decades. Then the internet came of age which changed the way people and businesses interact with one another. These two important technology advancements changed business for the better but not without consequences. The days of IT being in control with centralized and reliable systems gave way to the complex, distributed, and multi platform environments that we live in today. This in turn, directed a lot of IT’s attention towards infrastructure projects. In today’s world, a large portion of IT budgets go into projects and services that keep the lights on for the company (email, voice & telecommunications, security, compliance, etc.) and do not contribute to additional revenue. In addition, software vendors started delivering shrink wrapped solutions (ERP, CRM, Financial applications, etc.) that was not feasible for companies to build internally. I believe these factors have all contributed to the fact that many IT shops have become disconnected and/or out of touch or alignment with the business. IT has become perceived more as a cost center then an enabler. Employees have become known as what Catbert calls “Headcount”.

Point #2. The PMI Institute states that 72% of IT projects they studied were late, over budget, lacking functionality, or never delivered. Of the 28% “successful” projects, 45% were over budget and 68% took longer then planned. These numbers are frightening! Lack of project management best practices have caused many companies to lose faith in IT. Many business units have started buying their own software packages or paying outside vendors to solve their business problems. This is another reason why IT and the business have become unaligned.

When a company views IT as an expense and not as an enabler, the IT shop becomes a poster child for Dilbert cartoons. Companies tend to look for ways to reduce or eliminate expenses. Once you view your employees as “headcount”, the creativity, passion, and drive gets drained right out of you.

So is IT doomed? Many experts believe that in order for companies to stay competitive and survive in the upcoming years, IT needs to focus on business processes. In the article, The How, Why, and Where of Future I.T., Mark Gibb’s states that, “I.T. has to be able to show that it delivers a real return on investment.” To accomplish that, I believe that IT should start embracing:

1) Project management – to improve delivery and communication

2) Portfolio management – to maximize IT investments, align priorities w/business, and control workloads

3) Business process management – to optimize and automate business processes

4) Enterprise architecture – to align technology with corporate goals and strategies

5) Change management - to manage change and impacts on people and processes

6) Agile development – to deliver value early and often

What are your thoughts?

How many times have we seen high profile people do things that contradict the messages that they send to us? We have seen a homeland security official stalking teenagers on MySpace, we have seen athletes deny taking performance enhancing drugs only to be proved guilty, and we have seen laws like the Patriot Act, which was supposed to protect us, actually violate our civil liberties. What does this have to do with technology you might ask? Well the lesson learned here is if you say one thing but do the other, the people who follow you lose faith and your initiatives fail.

The same holds true in corporate America. When a visionary leader attempts to implement a culture changing initiative like business process management, agile development, or a new project management methodology, they must practice what they preach. I have seen several attempts to implement standard software methodologies, like CMM, fail. Why do they fail? Because the visionary leader didn't practice what he preached. In this example, the visionary preached that by adopting CMM, IT would be more successful in delivering projects. Unfortunately, implementing CMM was not carried out like a project. No scope was defined, no communication plan was developed, no stakeholders or executive sponsor was named. Instead , a boat load of documents were thrust on the IT staff. Of course, there was mass resistance and the initiative failed. Had the visionary practiced what he preached and used CMM to implement CMM his chances for success would have greatly increased.

Practice what you preach applies to those trying to implement SOA for the first time. You probably sold management that some of the advantages of SOA are speed to market and agility. The CEO was so excited by your presentation that he freed up a boat load of funds to launch your SOA initiative. Guess what? It's now time to get agile. Practice what you preach. Throw away your old waterfall approach. Gone are the days of 6-8 month deliverables. Start delivering early and often. If you don't change your ways, the CEO will quickly lose faith in this initiative quicker the you can say WMD.

Many companies in the early phases of the project management maturity model rely totally on ROI (or sometimes gut feelings) to prioritize their projects. But does ROI tell the entire story? The ROI is just one piece of the business case that should be presented before a project gets approved as part of a company's portfolio. There are at least four categories of business drivers that should be considered:

1) Financial Analysis
2) Strategic Alignment
3) Tactical Importance
4) Risk Mitigation

When looking at the financial aspect of a project, key metrics like Net Present Value (NPV), ROI, Payback Period, Cost Avoidance, Cost Reduction, and Opportunity Costs should be considered. Things to consider in the Strategic Alignment category are business fit, customer retention or growth, revenue growth, new markets, customer satisfaction, or other important business drivers that come straight from the company's goals & objectives. Then there are the tactical drivers like improved performance or quality, longevity, competency enhancing, competitive impacts, improving time to market, or first to market to name a few. The fourth category is for business drivers that mitigate risks for business issues. Regulatory compliance (SOX, HIPAA, etc.), business continuity, disaster recovery, security, and patent protection are a few that come to mind.

Each company should have specific business drivers that fall into these four categories. All of these drivers should be evaluated in the business case that gets presented to the business owners of the portfolio. The business should tailor the specific drivers within each category to meet the overall company goals and objectives. Then weights should be assigned to each business driver.

Here is an example: Let's say that Strategic fit is a driver you wish to measure. You can apply a weight of 1 for low, 2 for medium, and 3 for high. For ROI or NPV, set some thresholds for low, medium, and high (low < $1M, Med < $10MM, High >=$10MM for a small company). After entering in all the weighted business drivers, sum up the total for each project and you get the Net Weighted Portfolio Value (NWPV).

If your company does not own robust portfolio tools, you can simply use Excel. To test this out, take what you think are the top 10 projects in your company and enter all of this data in the spreadsheet. Then sort by the NWPV and see how this compares to the original top 10. You might be surprised.

Keep in mind that the NWPV is for guidance purposes only. The CFO's pet project may still be #1 but at least you gave him visibility into the value of all of the projects in your portfolio. The intent is to put all projects on a level playing field so you can use more then the standard ROI or gut feel to prioritize your IT investments.

References
Kaplan, J. (2005). Strategic IT portfolio management: Governing enterprise transformation. PRTM,Inc.

Handler, R., & Maizlish, B (2005). IT portfolio management: Unlocking the business value of technology. John Wiley & Sons.