Why Mobile Centers of Excellence Suck

Why Mobile Centers of Excellence Suck

There’s nothing wrong with the intent of having a Mobile Center of Excellence (mCOE) inside a large company. The problem is that, rather than reducing shadow IT projects, the bottleneck of the mCOE is backfiring and having the opposite effect.  Let me explain.

Big enterprise IT analysts were quick to promote the recommendation that large companies build and maintain an mCOE.  The argument was that business users were making far too many mobile decisions on their own yet didn’t possess the necessary knowledge to make well-considered decisions for the company.  Topics such as data security, legal and HR compliance, and app performance were often not considered until after a solution was in place.  IT would often be brought in to solve a problem situation despite having not been involved in the planning of the solution.  Of course the idea of a cross-functional team to help establish some rules of engagement around mobile, ensure compliance to higher level company objectives and policy, and provide the technical guidance needed to make smart decisions sounds like a great solution.  Unfortunately, we’re seeing examples of the exact opposite happen.

Authorized to say “NO”, but not empowered to say “YES"

The fundamental problem we’re seeing with mCOE teams is that the bureaucratic tendencies of large companies have infiltrated the pure intent of the group.  What was intended to provide a mechanism to get stuff done has become a bottle neck in the process.  Rather than acting to remove friction, these groups have sometimes become a black hole where there are so many restrictions and barriers to approval are so high that they’ve become cemeteries for innovative concepts (the place where great ideas go to die).  Worse, we’re seeing more business units seeking support directly from outside vendors in hopes of skirting the mCOE process entirely in order to get a much needed business application built and in use.  Of course this proves we’ve gone full-circle where the mCOE is responsible for the exact scenario it set out to avoid.

Let’s rename this group “The App Factory"

Of course changing the name doesn’t, by itself, change how things operate.  But the idea of an “approval council” as the mCOE was described, lends itself to long arduous processes that may or may not lead to results.  Changing the name to “The App Factory” instills a sense of productivity.  A factory still has to consider important topics such as safety, security, economies of scale, etc.  But the idea of creating a factory sends the message that “we’re focused on getting things through the process”, or “we’re focused on producing an output”.  This subtle change in positioning will have dramatic influence over the expectations of participants.  Rather than setting barriers in place, participants should be looking for ways to reduce barriers while still maintaining compliance.

Enterprises need to position themselves to provide solutions in an agile, speedy fashion while still maintaining compliance with corporate policy and security architecture.  Rather than letting a group of experts build taller barriers to entry, we should leverage the tools and practices available to us to provide 2-speed IT and solve for both at the same time.  We should build an App Factory that get’s shit done.