IT is about delivering solutions. Every company in today’s world have it’s own IT landscape. Small business can rely on just a few systems (perhaps outsourced or SaaS), large companies usually employ hundreds of systems with complex interdependencies. Technology, on the other hand, is developing at such a rapid pace, so it comes as no surprise, that those systems/solutions are aging and no longer fit for purpose - that’s why they are subject for regular review/evaluation. No matter if you’re a CIO or a Sysadmin, but if you’re the one responsible for proposing/evaluating IT solutions you have to do it professionally. And by professionally I mean do your homework, so you got questions answered before your CEO ask them.

Questions CEO ask

So you got your sleevs up for the next solution you’re going to present to your boss. Unless you have answers to those questions don’t even try.

Why?

If you don’t have clear understanding of what drives your project you should turn to your key stakeholders. If it’s only you - you have to take time and think what this project will bring in terms of business value (f.e. system upgrade will improve customer satisfaction due to increased performance). If it’s someone else - go and identify them.

How much does it cost? What is expected ROI?

Your boss need this information in a perspective, meaning you have to layout both CapEx (buy) and OpEx (run) costs. My experience shows, that presenting 6 years TCO is pretty efficient as it covers both CapEx and OpEx plus next technology refresh. If you wander why 6 years exactly or how to calculate CapEx and OpEx I advise you to read my post on Cost Calculation.

Have you evaluated X as well?

CEOs don’t live in isolation and exchange ideas with their peers. Therefore you should not be surprised if she asks you why you propose solution X, when some other company is happy with solution Y (at half the cost)? Being professional also means staying ahead of such questions - and that’s where all the fun begins!

Step 1: Collect requirements

Identify key stakeholders

Before you can start collecting requirements you have to understand who will work with solution in one way or another. Those are usually split into two groups:

  1. Customers or users who will directly benefit from this solution
  2. Parties who will be affected/impacted by this solution (those could include your operations team, customer support, security group etc.)

You have to approach both groups and collect their requirements and expectations. Better yet - try to capture some quantitative estimates. Even if you know those by heart, I strongly suggest to document them and get them reviewed by those groups.

Make sure, your requirements are captured as well. If you are in IT operations as myself, you can find it useful to review my Operational Readiness check-list.

Step 2: Market assessment

No matter if you already know one solution that fits your needs perfectly - you have to review market for other available options. While this might seem like a waste, it pays off big time if your decision will be challenged.

Target of this step is to prepare “long-list” of prospective solutions. What if you don’t know where to look for the options? Here are few good starting points:

  1. Wikipedia - it have articles for most common IT solutions. You might be out of luck though, if it’s a niche product.
  2. Gartner Magic Quadrants - even if not available directly from Gartner, those are usually re-published by the vendors from top 2 quadrants.
  3. Google - enough said, most probably you aren’t first person with that kind of a problem.
  4. Your network - reach out to your peers from other companies / industries to exchange ideas.

Step 3: Prepare shortlist

Target for this step is to reduce “long-list” using high-level criteria from your Business Case down to few (3-5) solutions worth evaluating. If a “long-list” is huge, you can iterate on it using requirements both horizontally (checking requirements starting with high priority) and vertically (going deeper into details for each requirement).

Step 4: Evaluate

Evaluation phase usually consists of more in-depth assessment of each requirement. Scope for this phase is naturally defined by previous steps and consists of shortlisted solutions. As bare minimum, all key stakeholders should rate each solution as per criteria they provided. There are several approaches to perform evaluation depending on your organization and expected impact (in order of increased complexity):

  1. Doing ‘paper-exercise’ reviewing solution specifications/documentation or interviewing vendors
  2. Demo/Pilot hosted by a vendor
  3. Deployment of Proof-of-Concept environments (including necessary components)

Word of caution - don’t blindly trust vendors/distributors, especially sales representatives - this can cost you career - always try to verify critical requirements (at least using 2nd approach listed above or interviewing technical representatives).

I suggest you to prepare a comparison table of all short-listed solutions gauged against all defined (or at least important) criteria. Make sure you save evaluation results for the future, this will provide you with:

  1. “Plan B” if something will go wrong during implementation of selected solution
  2. Migration options if support for selected solution will be terminated by vendor
  3. Migration options if your business requirements will change

If you did your job in Step #1, by the time you get to this point you already know by heart what could be the right choice. For the small shop this might be enough, but still I suggest you, as a sanity check, to complete Decision Analysis and Resolution (DAR for short) exercise. There are several approaches to chose from - depending on solution and your organization you can choose from set of techniques as simple as Approval Voting to sophisticated ones like Decision Tree. Personally I prefer Force Field for relatively simple comparison (like 2 items on a short list) and a Grid Analysis for more complex tasks. Despite the technique you choose, you should always keep an eye on:

  • People - they could be insufficiently educated on a topic, pursue their personal agendas or have their cognitive biases
  • Resources - there could be lack of time and/or money to perform through assessment
  • Assumptions - some unspoken expectations could easily turn the tides in favor of other solution