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?

We are in the process of defining and implementing our SOA governance processes. We are a medium size company so having armies of process cops is not an option, not to mention totally undesirable. At the same time, we need some level of process to ensure that we architect business services in a consistent manner and that we design for the enterprise as opposed to the old application silo approach. To make governance even more challenging, we want to deploy in cycles of 12 weeks or less. So how can we be agile and enforce SOA governance at the same time?

One way is to shift from text heavy documentation to visual documentation. In other words, stop generating hundred page Word documents and start creating UML models, business process models using BPMN, use case diagrams, and architecture diagrams. These artifacts are like blue prints for a building architect. If you were building your dream house would you type up the specs for your house in a Word document and hand it to your builder or would you give him blue prints?

Another way to stay agile and still enforce governance is to tightly control scope and requirements. Users are used to asking for the sun and the moon because they typically have to wait several months to get the next release. It is similar to the way politicians load up a bill with pet projects because they know it might be their only chance to get their stuff done. We must train the user community that in an agile approach, we will deploy more frequently and in shorter time spans. This means that you don't need to get every last requirement jammed into the project because another release is coming on the heals of the current release.

But the most critical way to stay agile while having a solid governance model in place is to use processes where it makes sense. Focus on artifacts that mean something to those who have to develop software. Don't focus on documents that are never used once they get signed off. One of my favorites is the team structure document. I have seen teams waste days creating a document that nobody other then the PM uses that describes all the roles, who the team members are, what their contact info is, how meetings will be held, when they will be held, and so on. Who cares? The PM needs to know this but why waste the rest of the teams time with reviewing this stuff. I can look up people's information on the portal faster then I can even find this document. Over the years I have seen teams create documents for the sake of satisfying a check list. This is a total waste of time. SOA Governance is all about managing services and the service life cycle. SOA governance can plug into your existing methodology (if you so desire). Focus on the processes that add value and discard everything else.

For small and medium sized businesses, we must be careful not to get bogged down in process. Unlike large enterprises, we don't have the luxury of dedicating several full time employees to enforcing processes and procedures. Instead, we must put a solid framework in place and rely on our people to enforce the necessary processes. Setting up a SOA Center of Excellence and an IT Steering committee under the watchful eye of a strong executive sponsor (CIO, Chief Architect, etc.) is one way to approach it.

There is no silver bullet here. Each company must decide for themselves how much process to put in place. If they put too much process in place, they can get bogged down and never meet expectations. If they don't implement enough process, then they will eventually spiral into mass chaos and won't realize the benefits of SOA like reuse, reduced maintenance costs, and increased flexibility.

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 5, I will focus on Lack of Process.

Many people in IT think of process as paperwork, overhead, or even a total waste of time. I have seen some processes that fit those descriptions. But in those cases, somebody implemented processes for the sake of having processes instead of implementing a set of processes that help IT deliver quality software and services.

Companies with no processes or ineffective processes have the following issues:

1. Reactive mode, constant firefighting
2. Consistently deliver late and over budget
3. Sweat shop mentality, working hard instead of smart
   
4. Low morale
5. High turnover

All five of these issues are extremely expensive. If you owned your own company and it had these issues would you ignore them? Many IT shops that have these issues look to offshoring as the answer. Can you say doomed? If you can't manage your own internal resources and projects, what makes you think you can manage a group of people in another country? Even if you pick the best offshore resources in the world, the overall success of your projects still rely on your ability to manage them. In other words, it depends on your processes.

There are many types of processes and methodologies that are proven. They range from strict methodologies like CMM and its 5 levels to Agile Methodologies and Extreme Programming (XP). The proper methodology depends on your company culture, your products and services, and your budget. If you are sending a man to the moon, you should use a very strict methodology like CMM. When lives are on the line or millions of dollars are at stake then no short cuts should be taken. If you are implementing infrastructure projects then the PMI methodologies can be a good fit. They provide a good step by step or check list approach that helps you assure that you have not missed a step. If you are delivering applications on the web or providing features for internal or external customers then you probably want speed and that is where Agile and XP come in. With these methodologies, you want to iterate through all phases and deliver in quick intervals. These methodologies focus on getting the right features into the hands of the users quickly and discourage trying to anticipate every user need.

But process isn't just about delivering new software and services. Project prioritization and production support are two critical areas that need to be managed effectively. If either of these two areas are not under control, your chances of success are greatly diminished. Here are the effects of not having a good prioritization process:

1. Over allocation of resources
2. Not working on the most important projects
3. Constant changing of direction, lack of focus
4. Frequently run over budget and delivering late

Here are the effects of not having effective processes to manage production support:

1. Putting out the same fires on a daily business
2. Poor quality applications due to constant patching
3. Poor customer satisfaction
4. Low morale and burn out
5. IT unable to launch strategic initiatives due to high cost and resource constraints
   

So what should you do? Two things. First, implement portfolio management. I wrote an article that could help you get started quickly. Second, look at implementing change management or service management best practices like ITIL or Cobit. By using the best practices for managing change and support, you can reduce your costs, improve your quality, and free up resources to work on high priority projects.

I grew up in a family business and brought the entrepreneurial spirit with me into corporate America. I struggle to accept how some IT leaders do not manage IT like it is their own family business. These leaders are smart people (usually) and I know that they would be taking a different course of action if it was their own family fortune that was on the line. For you IT leaders that live in the world of chaos and firefighting like I have described throughout this series, if you won't drive change for your company, consider doing it for your people. Working hard instead of smart is not what we all envisioned when entered the exciting world of computer science.

This wraps up the 5 part series on running IT like it's your business. I will follow up with a conclusion that discusses how to implement some of these initiatives. Thanks to those of you who have stayed with me for this long series. Please provide some feedback. I would be happy to clarify any points or dive deeper into any topic.

There are several good articles about running IT like a business (here and here). I would like to ask the question, "Are you running IT like it's your business?" What are some of the 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

If you owned your own business would you let those obstacles get in the way of making your business more profitable? I didn't think so. So why should your shareholders tolerate it? In today's world of IT, there is a lot of pressure on CIOs to cut costs, pursue outsourcing, improve delivery, and enable the business to grow. If your shop is spending most of its efforts "keeping the lights on" are you really just managing a cost center?

Let's discuss the five barriers to success that I listed above. First is resistance to change. According to Prosci, the experts on change management, the top reasons for resistance to change are:

• Lack of understanding around the vision and need for change.
• Comfort with the status quo and fear of the unknown.
• Corporate history and culture.
• Opposition to the new technologies, requirements and processes introduced by the change.
• Fear of job loss.

In order to overcome these obstacles you must manage both the human and business aspects of change. To manage the human side of change you must define WIIFM (what's in it for me) for people at all levels. That equates to having distinct communication plans for Sr. management, mid level management, and non management personnel. You also must constantly reinforce and adjust your communication plan throughout the duration of your change initiative. It only takes one respected person to doubt the initiative and the whole house of cards can come tumbling down.

So define a clear vision, get executive level buy-in, communicate early and often, manage resistance, and measure your progress. I also recommend that you find a partner to help you foster change. Why learn everything the hard way? Accelerate the learning curve and secure a change management partner to guide you to a successful implementation of change.

In part 2, I will discuss the next barrier to success, Lack of Resources.

Stay tuned.

Nick Carr created one of the longest running questions I have ever seen when he wrote his book Does IT Matter back in 2004. There has been so much discussion arguing for both sides of the answer including this article from Harvard's Andrew McAfee. I believe that a key differentiator for a company is the business processes. For IT to Matter, IT must create an architecture that supports the business's need to dynamically change and customize their processes. This allows the business to be more self sufficient and agile, which leads to a better user experience and faster time to market.

This is why the BPMS and SOA vendors are cashing in right now. Many IT executives are starting to understand that IT needs to be more of a partner to the business then a cost of doing business. BPMS solutions allow IT to provide tools for the business to rapidly deploy new systems that can have a huge impact on the bottom line by:

• reducing costs through process reengineering
• identifying bottlenecks and providing what-if analytics for ongoing process improvement
• providing robust, AJAX & web enabled user interfaces
  
• providing visibility into performance metrics with built in business intelligence tools
• providing self service capabilities for the end users, thus reducing the dependency on IT resources

The smart IT executives are leveraging SOA to allow the BPMS tools to talk to the existing legacy systems by providing a service layer that acts as a bridge between the user interface and the backend systems. This allows IT to rapidly deploy new systems without having to throw away the huge investments made over the years on their existing systems.

So to make a long story short. Does IT Matter? It can matter if IT recognizes that "Process is King" and that the business and IT need to work hand in hand to provide solutions that create a competitive advantage.

I am beginning a long journey to implement both a BPMS and SOA solution at work. What I am finding out is that the technology is the easy part (and it is not all that easy). The real key to success is change management. The reason I say that is when I list out and rank the barriers to success, the top 5 are not related to technology. Number one: Resistance to change. Number 2: Becoming a process centric culture. Number 3: Governance. Number 4: Conflicting project priorities. Number 5: Lack of in-house skills.

If you look at this list you can see that all of these issues are related to people and processes. Change management, by definition, is managing the human aspects of change. The 5 barriers I listed are all issues that need to be addressed by either changing the culture, changing the organization structure or processes, or by training people. If we don't address all of these issues up front, then our chance of success is greatly reduced.

I am confident that we will successfully tackle the technical challenges, but we will need some help with the big 5! Any advice would be greatly appreciated.