A big focus during the first couple of days at the conference has been on Business Analysis Centers of Excellence (COE).  There have been a number of sessions where the speaker has shared their experiences with setting up and maintaining a COE.  There is a desire among BAs at an organization to have a community where the analysts can share ideas, create standards, develop best practices and document templates, and learn about what it takes to be a better BA.  There were some instances where management iniated the creation of the COE, but in most cases it started as a grassroots effort among the BAs in the organization.  

The purpose of a COE is to setup processes, controls and templates for the business analysis community within an organization to follow.  More and more companies are realizing the necessity for this and are looking for ways to implement it.  There are a few important things I learned during the conference about setting up and managing a COE.

Today was the first full day of the Building Business Capability Conference.  This is the 2nd year of the conference and first that I have attended.  The conference is made up of 4 tracks

• Business Analysis Forum
• Business Process Forum
• Business Rules Forum
• Business Architecture Summit

I am mainly focused on the BA forum.  My goal is to take some things back to CapTech that can be used to increase the effectiveness of our BSA practice and also understand more what are some of the pain points in the industry and what can be done to relieve them.  I attended five sessions today and took something away from each.

1.

In the past I've never understood what people really mean they say "think outside the box" but Jim Harris, in a recent OCDQ blog post, helped me figure it out.

Mr. Harris ends with this provocative line: "the bottom line is Google and Facebook have socialized data in order to capitalize data as a true corporate asset."  The post starts with a cold war analogy and proceeds to describe how Facebook and Google have made big money as "internet advertising agencies:" offering free services with which users (like us) serve up personal data in return for use of the service, then selling advertising space based on our data (hopefully anonymized).

I’m a data modeler, so I enjoyed Jonathon Geiger’s recent article entitled “Why Does Data Modeling Take So Long”.  But why does he say it like it’s a bad thing?

Mr. Geiger’s bottom line is exactly right: “Most of the time spent developing data models is consumed developing or clarifying the requirements and business rules and ensuring that the data structure can be populated by the existing data sources." On the projects he describes, no one took time before modeling to determine available data sources and identify business entities of interest, relationships among them, and attributes that describe them before database design started, so the data modeler had to do it.

Information Management Newsletters recently posted an article by Tony Hotko entitled "The Evolving Skill Set of the Information Worker." The article explains how industry trends and the ripple effects the global financial crisis are changing the skills requirements for knowledge workers. The focus, according to Mr. Hotko, is shifting from technical aptitude to adding value via business knowledge and soft skills.

As IT consultants, we often find ourselves aligned to (read: paid by) either business or IT, but to implement successful technology solutions we have to work in concert with both business and IT stakeholders. We have to avoid the mistakes that follow from putting IT at the center of the universe to the detriment of the business users. IT supports business, and we always have to work with that at the forefront of our minds. Below are a few tips that I've found that are helpful in putting the needs of the business first.

1. No IT project is ever and end to itself

I’ve often thought that conceptual data modeling was an underused tool in the arsenal available to requirements analysts, and in a recent conversation I found that many were surprised that it would be used in the requirements phase at all.  Checking the Business Analysis Body of Knowledge (BABOK) I found data modeling listed among the tools available to requirements analysts to “to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.”  There’s also Steve Hoberman’s excellent book on the topic, Data Modeling for the Business, an introduction to data modeling aimed at a business audience

"Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success." - Pablo Picasso

It is an old story: about 30% of IT application projects succeed, 45% are "challenged," and the other quarter fail altogether.   That's the consistent result over the years of the Standish Group Study of Project Outcomes.  Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994.  Not a pretty picture, right?  Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called "Lies, Great Lies, and Software Development Project Plans," which itemizes the strategies commonly used by IT project managers to "stay out of trouble" when schedule/budget results don't match initial estimates.  For example, "18% change the original schedule to reflect the actual results".