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?