Jon, thanks for the positive feedback. I'm going to give your "Files and Folders" a try. From the looks of your web site and the write-up in the App World it looks very appealing.

Mark, spoken like you've suffered such "over management" engagement on a few IT projects in your career? Thanks for stopping by.

Shim, thanks for the positive feedback. Glad my stats wrap-up prompted you to get your Google Analytics up and running again!

Bob, sorry, it looks like my wording is indeed poor. The original list price for the 64GB PlayBook was $699. RIMM's recent (and I believe still valid till early Feb. this year) price reduction has the 64GB PlayBook selling online through shopblackberry.com at $299 with free shipping. I'll reword my article to be more clear on this point.

Scott, agree completely. I was trying to convey the notion that you need to think in the terms senior management does. I have to check myself because I still find my default approach is to dig into the details, sort out the relevant facts that support a particular decision/recommendation and then repeat those facts. In repeating, I fail to take into account that others didn't do the research and thus those facts don't resonate with them as they do me. I have to force myself to "relate" those facts to the goals and objectives of senior management. Hence, I have to force myself back to those 5 steps I've outlined to make sure my message, in story form, is digestible by my audience.

It sure is hard sometimes to break out of the engineering mindset of facts and data and focus on structuring a message that resonates to senior management.

I wish there was a "google translate" for senior management indeed! I've always struggled with finding that balance between enough technical detail to be credible and convincing while not getting so detailed that the message gets muddied. In my current role I seem to be constantly putting together presentations to get consensus on technical direction/approach and thus my presentation skills are getting stress tested. I got some great feedback recently. I've turned that feedback into a "design spec" in my mind that makes the effort more structured. And you know what technical people tend to prefer: structure over chaos.

Thanks for stopping by!

Scott, Great points on the need for device manufacturers to improve their security offerings. I believe the biggest challenge is how to provide a stronger device profiling capability for banks to leverage in the user authentication process while somehow not allowing shady marketers to use that profile information for less than optimal purposes. Device profiling is just one element of the evolving on-line banking security landscape. I'll be interested to see if voice bio-metrics becomes a realistic option. Consider one holding their phone, making a payment to someone/something they haven't previously paid and briefly speaking into their phone to confirm whom they are in order to complete the transaction. You always have your voice with you (compared to a one-time password token) and voice prints are pretty unique to their originators.

Time will tell. Thanks for stopping by as always and sharing your thoughts!

Tim, you bring up some very valid points. I did assume a rather nimble bank IT department that probably rarely exists in any tier 1 or tier 2 US bank that could deliver such a complex project in even approximately 10 months as I've suggested. I don't believe I emphasized enough the assumption/need for senior management to focus the middleware and backoffice teams and dependent groups on this effort as the top priority. Of course, any veteran of large IT shops knows the extra noise associated with projects deemed "top priority" by management that can further stress an aggressive project schedule.

Having about 12 years working in IT and IT security for tier 1 and tier 2 banks, I can really only recall one situation where a very strong delivery team with strong alignment with the product team they were supporting had the ability to pull off a similarly complex project. This situation I recall was an extremely rare collection of timing, senior and seasoned folks that new how to work together and deliver cross-functionally (without a heavy external vendor dependency). Unfortunately, that impressive cross-team structure was broken up by yet another senior management change and subsequent re-organization. Even though some of that project leadership remained, the technical and security partners were split up enough that they never really regained that same delivery cadence.

So in working on hundreds of banking delivery projects, the likelihood that this project as outlined above would deliver exactly on time and on budget is probably an aggressive 10% chance of success. One slight delay in the procurement process or up front requirements prioritization and you can throw the rest of the schedule out the window and re-forecast.

"... make a silk purse out of a sows ear." is an excellent analogy for such a project en devour.

Tim, thanks for stopping by and sharing your experience and perspective!

Shim, thanks for sharing your perspective.

I agree that what I am proposing here is less than scientific. From my experience in working in IT departments that are part of companies that their primary products aren't IT (manufacturing, legal services, natural resources, financial services, etc.), the emphasis hasn't been on very strong, proven methodology based approaches to work estimation. In multiple cases, I have had to work a new team to figure out how work estimation was done prior to my arrival (seat-o-the-pants) and help coach the team to implement something slightly more formal. Thus, this post is the culmination of that first step of helping technical people add a bit of process and formality to their work estimate communications. My next step, if I ever can get to the next step, would be to try and add some evidence based data to the estimation process (consider what Joel Spolsky has written on the subject here: http://www.joelonsoftware.com/items/2007/10/26.ht... When I do and have enough data and experience under my belt, I plan to add to this post to describe how others can take that next step and what benefits they will realize.

Again, thanks for taking the time to stop by and share your feedback.

Scott, good question but the conference is focusing on securing stuff so bad guys don't get in to do bad stuff. In all compromise situations, companies, banks, etc. engage law enforcement that then "own" the process of tracking down the bad guys. Thus, unfortunately, the conference doesn't have any real law enforcement perspectives. I'll keep my eyes peeled for any info regarding the tracking side while getting overwhelmed with all of the new protection approaches.

Never a dull moment in security ... once you think you have a good handle on a particular attack pattern a totally new pattern emerges.

Thanks for stopping by, sorry I don't have a good answer for you.