“They gave me a book of checks. They didn’t ask for any deposits.”
– Congressman Joe Early (D-Mass), at a press conference in answer to a question about the House bank scandal.
When Are Technology Steering Committees Effective?
Just about every client we have utilizes a technology steering committee of some sort. These committees range from formal groups of 8-10 to a subcommittee of ALCO. Most of them have the same general goals – set a technology direction for the bank, prioritize major projects, resolve major issues/disputes.
Good goals, but execution has been – ahem – mixed, to say the least. Here are the major things that we see make the difference:
1. Setting limits
Let’s be honest – most banks have too many projects on the table and realistically have the money and people to only do 25%-50% of them well. An effective steering committee kills (or delays) 50% of all potential projects before any serious work begins on them. How many times lately has your bank said “no” to a project?
2. Ranking projects against each other
Every project looks more important viewed one by one in isolation. Effective committees look at all projects, ranking them at the same time. When a comparison is made all at once of the importance of, let’s say, CRM, cash management, a Windows teller system, bill payment, Baker Hill, off-site ATM, data warehouse, and check imaging projects, and a priority list is produced from the comparison, the committee has earned its keep (lunch at Elaine’s and other post-carnage bonding is neither required nor desirable). Does your bank have a one-page summary of all the projects being considered or under way, with some ranking?
3. Standard write-ups
Effective committees require the same write-up for each and every project – description, cost justification, industry best practices, potential vendors, resources needed. Look at how your loan committee has standardized write-ups – copy that. And don’t let people sneak around this requirement!
4. Consistent logic for approval
Good committees apply the same ranking criteria to every project. Truthfully, there are only three big ones – how it supports bank strategy, how and when it pays off, and if it is required whether we like it or not (known as the “wheezing its last sorry breath” syndrome).
5. Resource management
In most banks, the same employee group tends to work on the majority of projects (usually “extra credit” after their regular jobs). Look for them getting overwhelmed, because many of them are. Do you know the number of project hours key employees have been “volunteered” for in 2001?
One final thought. The biggest risk in technology projects is not that projects don’t get done – it’s that they get done poorly and get left half-baked.
Can your bank afford that? -tr