Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Fri, May 18, 2007 2:29 EDT
|
Posted by: Michael Kavis in Best Practices Topic: ArchitectureBlog: Delivering the Goods
Current Rating: |
One of the biggest reasons why enterprise initiatives fail or never get off the ground is that the scope and target audience is often too big. Don't bite off more then you can chew!
Many IT leaders are trying do the right thing and implement change in their organization in areas like enterprise architecture, business process reengineering, service oriented architectures, and many other bold initiatives. Where they often go wrong is that they try to implement these initiatives across the entire organization right out of the gates.
As we all know, large scale change is extremely challenging and even intimidating. The larger the scope, the longer it will take to implement. The longer it takes to implement, the more likely it will fail.
Here's a better plan. Find a key project with high visibility. Implement the desired change for that project and measure the cost/benefits. This gives you several advantages. First, it shortens your time to market. Second, it limits your risks. Third, it gives you an opportunity to learn from your mistakes and refine your approach before implementing enterprise wide and finally, it reduces the amount of your initial investment.
Here is a real life example. At a mid sized company, IT had been campaigning to implement a business process management (BPM) initiative for a long time but could never convince management to make the investment. One day, IT discovered that an executive in the business was being asked by the CEO to streamline operations and cut costs. IT then partnered with the business executive and focused the initiative on a specific area of the business, as opposed to the trying to implement BPM enterprise wide.
Now IT had a key executive sponsor who didn't need to be convinced to change and was willing to fund the initiative. In addition, the scope was reduced to changing about 5% of the business's processes and impacting only about 10% of the company's staff. As the project progressed, other areas of the business started lining up to be the next guinea pig. The team also collected metrics to show ROI and operational improvements.
The team is now well on its way to delivering huge cost benefits to the business. Funding for the next initiatives will be easy to justify. The company will be able to gradually adopt BPM and evolve over time without any interruption
This does not only apply to big integration and infrastructure projects. It also applies to just about everything we do. When you try to do everything at once, it is harder to justify. It takes longer than you expect. By the time you get it implemented, the business has changed and what you are deliverying may no longer apply. With every initiative, I would suggest you break it down into the smallest logical components, then prioritize the small pieces by how much value they can supply to the business. It's a lot easier to get a month or two for an initial pilot or partial implmenatation than it is for a two year mega project. Once you deliver value, it's a lot easier to get buy in for the next set of value.
Pilots and small subprojects are a great way to get started or test out new ideas. You just have to be careful that you have a cohesive vision that encompasses all these small initiatives. Otherwise you can find yourself with a bunch of disconnected pockets of systems which have to be maintained. A couple of tactics can be employed to keep this manageable, including technology standards, templates for software development, and development practices that look to the larger picture by planning up front for the piece being implemented to be integrated later into a larger infrastructure. Most important, though, is to have a big picture idea of how each subproject will fit and connect into the information architecture you are building.
Thomas M. MacKay
I agree. As I said above "With every initiative, I would suggest you break it down into the smallest logical components, then prioritize the small pieces by business value."
They key parts of this are "break it down into smallest logical components" which requires some knowledge of how those components can fit back together.
The second part of that is "business value". I would argue that small well built but disconnected components that deliver the highest business value are better than a very well integrated behemoth that delivers a lot of unused or low priority functionality.
The third part that I did not spell out before is that you should be willing to periodically throw out stuff that is no longer working. Something that delivered great value a year ago, but is now disconnected and not well behaved should be reworked, refactored or even thorwn out and completely rebuilt.
As long as you are continuously giving the business the highest value deliverables, you are not likely to go too far wrong for very long.
I couldn't agree more! I've done the same thing with software process improvement and not only is it much more likely to succeed, you can start saving money and reducing pain sooner.
SMALLER IS NOT ALWAYS BETTER EITHER
WHen you just focus on a smaller area you can optimise part at the expense of the whole — reducing both the returns to the company and its future options.
I suggest an alternative strategy.
Think of scope in two dimensions — problem scope and solution scope.
Then analyse the needs of the whole area. This is our 'problem scope'.
Then, having a clear idea of what you want to do over time, you select a portion of this and implement the solution (the solution scope).
You then move on to the next portion and so on over time until the whole solution has been implemented. This may take 18-30 months, but is delivered as a series of