I've been involved in many planning meetings. In today's environment of technological expansion, institutions of all sizes must face the planning process with technology in mind – almost regardless of the initiative. But too many times, I've seen the process stumble, often from easily avoidable mistakes. To kick off planning for 2013, here are the top 5 easily avoidable planning mistakes I've witnessed the most often.
It is surprisingly common for senior-level strategic sessions to occur without a senior technology expert in the room. In fact, many small and mid-size institutions still treat IT as a junior-level concern, unworthy of promotion to the executive suite. By contrast, large institutions, such as Navy Federal Credit Union, employ some very highly qualified, strategically minded, tech-savvy executives – and listen to them.
Without including a knowledgeable IT voice from the very beginning of a strategic discussion, any organization is highly likely to make some major mistakes. And these mistakes are costly, not only in financial resources, but in time, customer relations, opportunity cost, not to mention tensions in the executive suite. So, my number one mistake is simply planning without knowing what you're doing. I know it sounds basic, but it's only too true.
Many projects begin with a vision of everything the product will do. Requirements are determined in detail, often for a large amount of work, then the project gets under way. But where is the real value in the project? It's important to prioritize where, in all that work, lies the most value, whether it be realized revenue, operational efficiencies or another strategic goal, then attack that piece first. This approach requires less work, less time and less money before the most important part of a project is actually delivered. We call this process value order. The goal is to obtain the minimum viable product, doing the least we can do, and make it worthwhile.
Typically, we find that about 70% of the total value of the initially planned project is achieved in the first release when we do this, way sooner, and at less cost than if we'd just started cranking on the entire project. Often, when we've stripped down a big project to its core set of actually valuable deliverables, we've made the rest of the project obsolete. The goals are achieved, but with much less work, money and time spent overall.
Big banks are investing many millions in the development of innovative, attractive, sometimes downright seductive new technological capabilities. But very few institutions can keep that kind of pace. Nevertheless, it often occurs that a small or mid-size institution attempts to close the gap with a flashy new capability equal to that of the big boys. And that's fine, if it's strategic.
But in too many cases the decision is made based on sensationalism, trendiness or just vanity. It's OK – in fact it's wise – to match a selection of your competitors' capabilities. But it's vitally important to choose wisely. What do your particular customers value the most? What does your brand promise to them? Where do you make the most revenue? What do you do best already? These are the questions which must be considered when planning a technological investment. Not "what's the very latest tech gimmick put out by Bank of America?"
Too often, and usually as a result of limited technological know-how, institutions invest in technologies, software products, gadgets and devices which will be obsolete or in need of major upgrades in a few short years. Or, just as often, they'll invest in areas that don't serve the institution's long-term strategic growth plans.
This is despite the fact that it's possible to make solid, long-term improvements and expansion to any technological capability. It takes top-level discussion, involving knowledgeable, experienced IT expertise, to bridge the gap between a strategic goal and an IT reality. This typically produces a better product, but also helps ensure that the product is in alignment with an institution's goals and market reality – for the long term.
Planning often produces a list of requirements. This list is in alignment with the organization's long-term goals, and is part of a well-considered strategic initiative. The organization finds a cheap off-shore code shop which promises to build the product to their exacting specifications. And they do. And the product doesn't work.
The problem here is that, despite their promises, companies that simply code to requirements simply code to requirements. This doesn't work well for organizations that need to seamlessly integrate new software to a variety of systems they're running, while interacting with their very human clients online and at the same time, are only beginning to understand what they really need the product to do in the first place.
It is the reverse of the best way to produce code. The best way is to develop that product in an iterative, fluid manner, testing all the time, and retaining the ability to make changes. None of that can happen when coding to rigid, contractually binding requirements.
1. Planning IT – Without IT expertise
It is surprisingly common for senior-level strategic sessions to occur without a senior technology expert in the room. In fact, many small and mid-size institutions still treat IT as a junior-level concern, unworthy of promotion to the executive suite. By contrast, large institutions, such as Navy Federal Credit Union, employ some very highly qualified, strategically minded, tech-savvy executives – and listen to them.
Without including a knowledgeable IT voice from the very beginning of a strategic discussion, any organization is highly likely to make some major mistakes. And these mistakes are costly, not only in financial resources, but in time, customer relations, opportunity cost, not to mention tensions in the executive suite. So, my number one mistake is simply planning without knowing what you're doing. I know it sounds basic, but it's only too true.
2. Missing the Value
Many projects begin with a vision of everything the product will do. Requirements are determined in detail, often for a large amount of work, then the project gets under way. But where is the real value in the project? It's important to prioritize where, in all that work, lies the most value, whether it be realized revenue, operational efficiencies or another strategic goal, then attack that piece first. This approach requires less work, less time and less money before the most important part of a project is actually delivered. We call this process value order. The goal is to obtain the minimum viable product, doing the least we can do, and make it worthwhile.
Typically, we find that about 70% of the total value of the initially planned project is achieved in the first release when we do this, way sooner, and at less cost than if we'd just started cranking on the entire project. Often, when we've stripped down a big project to its core set of actually valuable deliverables, we've made the rest of the project obsolete. The goals are achieved, but with much less work, money and time spent overall.
3. Keeping Up With The Johnsons
Big banks are investing many millions in the development of innovative, attractive, sometimes downright seductive new technological capabilities. But very few institutions can keep that kind of pace. Nevertheless, it often occurs that a small or mid-size institution attempts to close the gap with a flashy new capability equal to that of the big boys. And that's fine, if it's strategic.
But in too many cases the decision is made based on sensationalism, trendiness or just vanity. It's OK – in fact it's wise – to match a selection of your competitors' capabilities. But it's vitally important to choose wisely. What do your particular customers value the most? What does your brand promise to them? Where do you make the most revenue? What do you do best already? These are the questions which must be considered when planning a technological investment. Not "what's the very latest tech gimmick put out by Bank of America?"
4. Investing in Obsolescence
Too often, and usually as a result of limited technological know-how, institutions invest in technologies, software products, gadgets and devices which will be obsolete or in need of major upgrades in a few short years. Or, just as often, they'll invest in areas that don't serve the institution's long-term strategic growth plans.
This is despite the fact that it's possible to make solid, long-term improvements and expansion to any technological capability. It takes top-level discussion, involving knowledgeable, experienced IT expertise, to bridge the gap between a strategic goal and an IT reality. This typically produces a better product, but also helps ensure that the product is in alignment with an institution's goals and market reality – for the long term.
5. Off-shoring to requirements
Planning often produces a list of requirements. This list is in alignment with the organization's long-term goals, and is part of a well-considered strategic initiative. The organization finds a cheap off-shore code shop which promises to build the product to their exacting specifications. And they do. And the product doesn't work.
The problem here is that, despite their promises, companies that simply code to requirements simply code to requirements. This doesn't work well for organizations that need to seamlessly integrate new software to a variety of systems they're running, while interacting with their very human clients online and at the same time, are only beginning to understand what they really need the product to do in the first place.
It is the reverse of the best way to produce code. The best way is to develop that product in an iterative, fluid manner, testing all the time, and retaining the ability to make changes. None of that can happen when coding to rigid, contractually binding requirements.
Friend us on 
Follow us on 
Follow us on 