We’ve all heard the old joke about “Ready, Fire, Aim” but for many execs in government and business that we speak with, and who are being pressed to quickly respond to mission-critical operational requirements or competitive pressures, it’s not so funny. “Agility” has become the standard by which the effectiveness of executives and organizations is measured. To be agile, you need to be nimble and fast, but to be agile AND effective you also need to be right. Too often though, in the race to be agile, the delivered systems miss the mark. Sometimes, if the miss is not far of the mark, you can quickly recover; but mostly we see a lot of scrambling to get a temporary fix in place to buy some time. For our first few posts in the Blog, I’d like to share some thoughts with you about steps that can be taken to ensure success while avoiding the pitfall of “paralysis by analysis.”
I’ve always felt that business process re-engineering (BPR) sessions provide an invaluable opportunity to ensure that you’re automating the right stuff and getting the most value from the technology investment; but many execs are wary of conducting BPR sessions as part of the IT development process. They fear, and rightly, that BPR sessions can take too much time and encourage the development and inclusion of requirements that add complexity, risk, and cost, without a lot of value. BPR just doesn’t seem to fit in with the concept of “agile.”
But it doesn’t need to be that way. You can get the benefits of BPR while being agile – in fact, BPR may actually be one of the best tools available to enable you to quickly focus on the most important requirements, to validate the system approach, manage risk, and ensure that the delivered system provides maximum impact. But you have to plan to make this happen. As the late Ozzie Davis wrote, “It’s not the rap; it’s the map,” and our map, and the subject of a series of blog posts over the next few blog entries, will include some thoughts on: a) getting stakeholder buy-in and commitment, b) re-structuring the review of your “As Is” business processes or technology environment to focus on high-value activities, c) developing a blueprint for your “To Be” environment in stages, and d) rethinking how we put together and execute a transition plan.
