Archive for July, 2008

It’s harder getting out than getting in - improve your RFPs

Posted by Shahid N. Shah in Decision Making on July 20th, 2008

We’ve all seen it: we spend weeks or months in the “sales and demo cycle” for our applications. If we’re lucky we consider all workflows, if we’re even luckier we test drive the UI and make sure training goes smoothly, if we’re smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it’s been installed for a while.

Why is getting out important? Because every application becomes “legacy” sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (”barrier to entry”) is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?

If you can’t answer the “how, in 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle.

When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:

  • Do you own your data or does the vendor? Make sure it’s explicit in your RFP.
  • Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary. In the RFP make sure it’s clear that you want this documented and provided to you.
  • Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data. Make sure the RFP explicitly states you want the data formats.
  • How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
  • Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.

If you have other considerations, share them here.

No Comments

Traits of good architects and technical leaders

Posted by Shahid N. Shah in Decision Making, Leadership on July 20th, 2008

Many of my younger colleagues often ask about what some of the most important leadership aspects are for technical managers like team leads or architects. There are no hard and fast rules but here are some things I’ve learned over the years:

  • Make Decisions. This is one of the most important aspects of leadership — just making a decision and not analyzing for weeks or months. No amount of evidence or information will ever “be enough” and at some point you’ll need to make a decision. Your team can see if you are timid or if you take risks. Leadership is about decision making and if your decision making skills or risk taking ability are limited, don’t bother trying to lead. I’ve seen many architects and so-called “team leads” that try to get their bosses to make their decisions for them so they don’t get in trouble for making “the wrong ones”. Big mistake.
  • Lead by Example. Leadership is about direction and if you want to lead, you’ll need to make sure you take charge and establish that you know where you want to go. But, be prepared to demonstrate that you do what you ask your team to do. If you ask everyone else to do something but don’t do it yourself, your team will lose respect.
  • Be transparent. You work with bright people and although they may not be your equals in experience or knowledge, they will know when you are making decisions based on whim or reason. If you can’t explain your decisions in a way that your team can comprehend then you’re not a good leader.
  • Mentor. Good leaders create the next group of leaders, not just bark orders. If you’re not regularly mentoring and training, you’re not doing your job. And, if you mentor well you can let your team make many of the decisions without you and you’ll be able to trust that their decisions will be as good as yours.
  • Be inclusive. You’re the leader and can make all the decisions and everyone knows that. But, if you’re not including input from everyone you’re losing valuable data and a chance to build a cohesive team.

No Comments

If you can’t repeat it, don’t bother automating it

Posted by Shahid N. Shah in Project Management on July 20th, 2008

There’s been plenty of discussion in both literature and general media about “most software projects failing.” There are plenty of reasons for failed projects: from inadequate requirements gathering to poor project management to plain incompetence. Some of the problem starts at the C-Suite where projects are actually identified and started — for asking to automate (presumably with software) something that maybe has no business being automated.

My simple advice to most architects, CTOs, CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is “no” then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can’t at least be repeated consistenly manually.

This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That’s pretty easy to figure out. What’s not so easy to figure out is: why is the workflow so hard to gather requirements for? It’s probably because the workflow, while it seems consistent at the high level, isn’t repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn’t.

So, as a senior executive that may not be leading the project, but may be greenlighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology.

No Comments