The Importance of Vendor Risk Assessments

When buying a car, do you rush right out to the dealership and purchase the first car you find online? Or, do you perform your research and kick the tires, taking it for a test drive? Most of us will conduct our “due diligence” before buying a car and this includes researching the types of cars we’d like to buy, taking several test drives and checking out the mechanics of the car.  This same due diligence should be done for each of the vendors that you plan to use within your company in the form of a vendor risk assessment, regardless of their size. In fact, current vendors within your company should be reviewed every one to two years. For example, did someone review their financials? Do you know if you can get your data back if they go bankrupt? Do you know if they’re governed by laws outside of your country?

In larger companies, vendor risk assessments are typically performed by risk analysts, technology auditors, and information security folks, working in conjunction with the vendor management and procurement departments. In smaller companies, there may be a one or two person team responsible for conducting the vendor risk assessment. In many startup organizations, vendor risk assessments can be an afterthought. If you don’t perform a vendor risk assessment on your vendors today, take a look at this Risk Assessment Toolkit from the State of California’s Department of Technology, Information Security Office to get you started. There are many other sample templates and resources available online, as well. This is a great video on assessing technology vendor risk and security from Monte Ratzlaff, Security Manager, at UC Davis Health System, as he presents “Vendor Risks: Evaluating the Security of New Technology”.

At this point, some of you may think, “well, I don’t need a risk assessment on ____ vendor (insert name of vendor), they’re huge!”. Right? Wrong. I’ve worked with technology audit professionals on the review of hundreds (if not thousands) of technology vendors and yes, some of those “huge” vendors can have red flags for you and your company. Whether it’s the fact that they’re in the middle of a merger, they’re outsourcing their development team, or they don’t have enough insurance to cover you in the event of a breach, the scenarios can vary, depending upon what your company considers a risk and how that risk is categorized. If you need a tool to understand risks associated with the project you’re considering, take a look at this post by BrightHub PM, it has a lot of great info on creating a risk matrix and how to use it.

In the end, just think of a vendor risk assessment as a way to kick the tires of the prospective vendor before buying a lemon whose carburetor is going to explode once you drive it off the lot. If you’re interested in performing a proof of concept or proof of technology with the vendor once they pass the vendor risk assessment, check out a former post that I wrote on this topic and good luck!

Advertisements

Review of Boulder Startup Week

Boulder Startup Week

Photo courtesy of Boulder Startup Week

Hey everyone, hope you’re all well! So, I attended Boulder Startup Week and it was fantastic. There were some wonderful sessions with some awesome speakers.  In listening to the speakers and attendees at Boulder Startup Week, I didn’t feel as if I were alone in some of the project challenges I’ve faced and it was great to hear both their success stories and their failures. I loved the way that the speakers were very candid and that it had an informal yet structured vibe. The presentations weren’t set up as a podium style conference, but as a panel with a moderator.  This kept the audience engaged and allowed us to tweet questions to the moderator as we were listening to the presentation, giving the panel a chance to answer our questions throughout the presentation. The networking events in the evening also gave you a chance to mingle and network outside of the presentations.

I was considering outlining the sessions I attended in a blog post, however, the larger message I have for you is that if you’re in Detroit, Jacksonville, Baton Rouge, Huntsville, Tucson, or anywhere else outside of Boulder, you can build a technology community for your city. Whether it’s a startup week, startup day or a meetup group, it’s important to create a sense of community within the technology world where you live. It doesn’t have to be focused primarily on startups; it could be focused on UI / UX design, project management, or Java development.  From my experience at Boulder Startup Week, the key is to have fun and enjoy networking and learning with those within the tech community.

Building that tech community is a key ingredient and Boulder has built it over the years thanks to the amount of work that their community members have poured into efforts such as coworking, meetups, hackathons and other events.  Don’t worry about the fact that you’re not in Boulder and it seems like you’re in a technology community desert.  Just give it a shot and see what happens! Your city may become the next Boulder, you never know. 🙂

Make Your Next Demo a Success

product_demosVendor demonstrations or “demos” as they’re called in the industry are an important part of the technology product review phase. Unfortunately, these demos are typically despised by both business owners and vendors. Vendors don’t look forward to reciting a dry PowerPoint presentation and business owners don’t look forward to “wasting” two or more hours of their day. The funny thing is that this emotional response is what usually results in its failure. Here are a few tips for both vendors and business owners in order to make your next demo a success.

Business Owners

Prepare Ahead of Time. Prepare for the demo by collecting all of the information you’ve received from the vendor up to this point. What do you want to see in the demo? What should the vendor focus on? Reach out to the vendor ahead of time and send them your thoughts on the demo, noting what’s important for you and your stakeholders.

Ask Questions. I’ve seen many demos where business owners don’t ask any relevant questions. This is your chance to ask the vendor about their product. Prepare a list of questions before the demo if needed.

Respect the Vendor. They traveled to your site for a reason. Sure they’re salespeople and they do this all the time. However, I’ve seen business owners act very disrespectfully to vendor reps during demos. There’s no reason for that, everyone should be treated with respect.

Plan the Logistics. Make sure that the conference room is ready and that the vendors have wireless access (if needed) along with anything else required for the demo.  Reach out to the vendor ahead of time and ask them how many people will be attending. Also, think about questions like “Does the vendor need security access?”, “Do we need to serve lunch?”, or “Do we want to have coffee available?” This may seem like small potatoes now, but I’ve seen hours wasted due to poor logistical planning.

Listen. I’ve been in many demos where business owners ask the same question two or three times because they were checking their phone or weren’t paying attention. Listen so that you don’t waste your time and the time of those attending the demo.

Vendors

Arrive on Time. This is especially true if there are several vendor staff members attending the demo. There’s nothing like starting the demo and having four more vendor staff members trickle in over the course of an hour apologizing for their “late flight”. If flights are that hard to come by to get to the business owner’s site, don’t come in person, instead make it a webEx.

Disregard Pack Mentality. Don’t travel in packs unless absolutely necessary. If this can’t be avoided, let the business owner know up front that you’ll be bringing multiple colleagues.  It throws a lot of business owners off when they’re expecting two people and they end up walking into Oracle World.

Ditch the PowerPoint. Don’t spend an hour on your PowerPoint presentation, get down to brass tacks and show off your product. The PowerPoint is only going to tell your customers so much since it’s a static representation of your product. The PowerPoint presentation can be 10-15 minutes, but from there, start the demo.

Schedule Breaks. The human mind can only process so much information. On top of this, folks need to use the restroom and check their messages. Don’t hold your business owners hostage for 2 hours while you take them through the XML feeds. Schedule ten minute breaks each hour to keep everyone’s blood flowing.

Prepare Ahead of Time. Similar to the advice I gave the business owners above, schedule a discovery meeting with your internal business owner(s) before the demo to understand exactly what they want to see in the demo.

Good luck!

Effective Leadership is Key

Photo courtesy of fit2finish.com

My nephew’s soccer team recently got a new coach and they were playing a pretty tough team. As the kids ran up and down the field, I noticed the differences in the coaches. My nephew’s coach was passive, looking at his phone, talking to his wife and generally not caring what happened in the game. Now, this is a group of 7 to 8 year olds, so they’re not on the Olympic training team. However, the opposing team’s coach was a completely different story. He had a playbook, he walked up and down the field with the kids, he was engaged and cared about the game.

As I watched goal after goal scored by the opposing team, it dawned on me. These kids are so young, but effective leadership is still so important. You could see the look on my nephew’s face as they were losing terribly. His initial enthusiasm waned and he wasn’t trying as hard. The kids on the opposing team were high fiving each other and smiling. It all had to do with their leader. If my nephew’s coach had been an effective leader, they could have won or at least had a fighting chance.

Having an effective leader whether in sports or in an office environment is so important. With an ineffective leader you have ineffective employees. Processes fall by the wayside, things don’t get done, and employees feel let down. A manager’s job is to work with their employees, coaching them, challenging them and praising them. Of course, there are days where all managers feel overhwhelmed and stressed. But, you have to remember that your team is counting on you to lead them through these challenges. Whether your team is a success is up to you. Are you an effective leader or are you looking at your phone like my nephew’s coach, waiting for the end of the game?

Telling a Vendor Your Project Has Stopped

Photo Courtesy of dreamstime.com

One day your project’s on track, humming along. The next day, due to corporate changes, the project has basically stopped. It’s got a faint pulse, there’s talk of a “holding pattern until next quarter”, but you know that pulse is fading fast. The problem is that there have been several vendors involved in your project and they were hoping for some healthy first quarter revenue recognition once the technology solutions were chosen and the contracts were signed.

Breaking the news to your vendors that the project has stopped will suck. On top of this, expect them to be frustrated. So, this is something that needs to be handled carefully. Recognize that the vendors you’re breaking this news to will have probably worked on this potential deal for a year, maybe more. They’ve spent time on the road, away from their families, staying in hotels with bad beds, eating fast food, and basically reacting to your company’s every whim in hopes of closing the sale. You may be thinking, “yeah, but that’s what salespeople do, what’s the big deal?”. Well, it’s a big deal to them, and in breaking the news to them, let them know that things have slowed down and that it doesn’t look like it’s going to work out. Most importantly, don’t give them false hope. Now, if a vendor disrespectfully yells, curses or generally acts like a horses rear-end during the discussion, well…better to find out now then in the middle of your project.

The silver lining in all of this is that the good vendors will be frustrated, but they’ll hang in there with you. They may not return your call within five minutes of receiving it when you call next time, but they’re not going to blame you for issues that were out of your control. When the chips are down, you’ll know which vendors you can count on. The vendors that only cared about the sale and not you as a client will walk away. The ones that know their worth as a company, believe in their product and know that you’ll be an awesome client will stick with you through thick and thin.

Integration: Klingons vs. Elves

Integration is largely dismissed by those interested in purchasing software these days. Quotes like “don’t worry, we’ll make it happen” or “oh, it’ll all come together in the end” are heard in meetings as everyone rushes to sign the vendor’s contracts before the end of the fiscal year. Unfortunately, six months later the same people are saying “the vendors weren’t upfront in their demos with us!” and “I don’t understand what’s so difficult about all this, why can’t they just make it work!”.

If you’ve ever integrated different systems together, you know that integration is where the rubber meets the road so to speak. From a technical perspective, I’m not a fan of bolting two (or more) different systems onto each other and forcing them to talk to one another. However, many times it has to be done and if that’s the case, it needs to be planned accordingly. The best way I can explain an integration effort is this:

System 1, a.k.a. “Worf”: A Klingon who hails from the planet Kronos. Worf has been characterized as a “swarthy humanoid”, doesn’t like cold weather and enjoys a bloody battle. Speaks Klingon.

System 2 a.k.a. “Enel”: An Elf who hails from Valinor in Middle-earth. Wise and immortal, Enel is a skilled hunter and has pledged to preserve the world. Speaks Elvish.

Worf and Enel couldn’t be more different. In fact, they’re completely different in every way imaginable. So, how the heck do you make them talk to one another? Hire an interpreter (i.e. 3rd party software tool) to assist in the language barrier? What similarities does Worf have that Enel can understand (i.e. temporary tables)? What symbol of understanding can be passed between them (i.e. Web Services or APIs)?

To ensure that the Klingons don’t invade the Elven continent of Middle-earth and destroy an ancient civilization, it’s important that you get your Supreme Council in a room (i.e. project stakeholders) along with your Trusted Advisors (i.e. IT architects, etc.) and determine the best way (or ways) for Worf and Enel to communicate with one another before you join their people together as a nation. Otherwise, prepare for Worf’s battle cruiser to enter Middle-earth airspace and it won’t be pretty.

Learning to Swim in the Deep End

Photo Courtesy of perezhilton.com

Photo Courtesy of perezhilton.com

Every project manager has been thrown into the deep end of the pool. By “deep end of the pool” I mean that you’ve been thrown into some weird, technically challenging, scary projects that you probably knew nothing about. How do you initially survive being thrown into the deep end with barely a pair of water wings?  If you’ve been thrown into a project like this, here are some tips:

1) Figure out how to tread water. What can you do right now to understand the project better? Can you review historical documentation? How about talking to current or former team members? At first the project will seem overwhelming, but you’ll need to put your arms around it quickly. What can you do right now to help you keep your head above water?

2) Figure out who your lifelines are. I call them lifelines because these people truly are your lifelines when you’re learning the ropes of a project, especially one that is challenging. I’ve had many lifelines over the years to whom I am eternally grateful and without whom, I would’ve fallen flat on my face! Lifelines can come in the form of a project stakeholder, a project team member or even a project sponsor. These are your go-to folks that can always be relied upon to help you as you work through the beginning phases of a project.

3) Stay organized. You’re going to meet some crazy challenges and that will be much harder if you don’t know where anything is. Trust me on this one!

4) Be honest. If you don’t know Ruby on Rails, PHP, Java or C++, own it. Don’t walk into your first developer meeting and try to go toe to toe with those folks, pretending like you know something you don’t. You’ll be found out in a heartbeat and it won’t be pretty. If you know enough to be dangerous, mention it, but let them do the talking.

5) Avoid crazy drama.  Scary projects can sometimes come with crazy drama. Crazy drama is not your friend. Don’t let it suck you into its vortex of craziness. If anyone says anything remotely crazy, say something like “hmmmm…” or “I’m still getting up to speed on the project, I wasn’t aware of that”. As a friend of mine once said, “you can’t fight crazy” and you’ll end up battling Will Ferrell’s maniacal Anchorman 2 shark (as perfectly depicted above!).

Now, take a deep breath and get ready to dive into the deep end gracefully!