The unasked change control question

This change will be cool...it has fire.

This change will be cool...it has fire.

When evaluating change requests, I’ve seen many of the same questions asked:

Do we have the needed budget?
Do we have the right resources?
Have all the business partners signed off on this change?

More sophisticated approaches will also bring focus on the benefits, risks, and added complexities that the change will introduce.  However, I’ve only seen two change control boards ask this question:

What will we NOT do if we accept this change request?

In my experience, raising this topic clarifies much about the change.  First, it validates that the sign-offs referenced above weren’t simply a formality.  For example, I’m reassured when the requester can say that “we looked at these three options…” or “this scope change had a higher benefit than the other two proposals”.

This question also surfaces risks that the change will introduce.  In one case, I saw a very plausible change for a new entry screen proposed.  The costs, resources, and benefits were all in order.  However, the “what won’t you be doing” question produced blank stares.  A few probing questions surfaced what wouldn’t be done: the team has assumed away two weeks of testing effort to make room for the change. 

Request denied.

BI, Deliverables, and Change Control

This post may court the Business Week curse, but I’m highlighting this story on BI and the recession (here) as the jumping off point for a couple of observations.  Rob T.’s comment in the piece (sorry, but I can’t link directly) notes that:

Unlike ERP, BI can be implemented step-wise, first in targeted, strategic areas, and then using a broad brush once it’s value has been proven. A wise strategy for this economy is to start small, pick a problem or area where a quick win is possible and attack it with a 60-90 day effort.

I mentioned this opportunity for short, focused projects in my WSJ interview.  These short cycle times and the nature of BI work pose problems for traditional ERP change control and deliverables definition. 

For example. what exactly is “done” on a BI project?  The traditional ERP definition of deliverables — focused on processes that deliver tangible, measureable outcomes (e.g., Order to Cash, Purchase to Pay, Hire to Retire) — doesn’t work well for BI.  Typically, reporting projects focused on # of reports, explicitly defined.  Also, in analytics projects those reports or queries often spark more ideas for how data can be cross-tabbed, projected, etc.  Do you always want to be presenting a change orders for new reports?

What has worked for you when defining deliverables and change control for BI initiatives?  Now if you’ve read this blog for a while, then you can guess that I’m in tune attacking these issues with a capabilities-focused approach to deliverables.  This approach points one in the right direction when defining what done looks like.  However, many PMs find it hard to grok the requirements and required capabilities of analytics-savvy stakeholders and consultants.

Follow

Get every new post delivered to your Inbox.

Join 1,510 other followers

%d bloggers like this: