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. 🙂

Countdown to Boulder Startup Week

Image result for startup

Photo courtesy of small-bizsense.com

I’m really looking forward to attending my first Boulder Startup Week next week and have registered for as many sessions as my brain will allow! The crew coordinating it have done an awesome job of scheduling each day, making it easy to view your schedule on your phone / mobile device.

I’ll be blogging after Boulder Startup Week in order to give you an overview of the sessions that I attend, including feedback on the amazing people and startups I’ll meet along the way during my adventure.

If you’re on the fence and not sure if you want to make the drive or flight to Boulder Startup Week, my advice is to go for it! DIA (Denver International Airport) isn’t too far from Boulder, but you will need to rent a car. When you’re renting the car outside of the airport, they’ll ask if you want the Toll Road fee included in your rental. I would recommend paying for it upfront since the E-470 toll road heading to Boulder is expensive and paying upfront actually saves money (even though it doesn’t feel like it at the time!). Also, taking the E-470 toll road will save you from the crazy traffic inside of Denver.

From a lodging perspective, many hotels in Boulder are probably booked up at this point, but you can stay outside of Boulder in Broomfield, Superior or even Westminster. Staying in these areas will put you about a 10 to 20 minute drive to Boulder, taking Route 36 (not a toll road). The traffic to Boulder can get congested during rush hour, so leave early if you’re staying in these areas and want to get to Boulder by 8-9 am.

Are you heading to Boulder Startup Week? If so, let me know – it would be great to connect with you! See you there!

The Price of Innovation?

Image courtesy of Telephonica

Image courtesy of Telephonica

BMC sues ServiceNow. Cisco sues Arista. SAP / Ariba sues Coupa. Is this the ultimate price of innovation?

Start ups are built with hunger, passion and innovation. Oftentimes, they are built with the minds of those that have worked for BMC, Cisco and Ariba. But, is this wrong? In the eyes of the law, it’s wrong when your ideas infringe upon the patented or copyrighted ideas of those that came before you. However, without the experience that those employees gained from being at BMC, Cisco or Ariba, could they have built a better system? Probably not. But, I’m not here to opine on whether BMC or ServiceNow are right. I’m here to open a discussion on today’s price of innovation and the uncanny surge of enterprise companies such as BMC and Cisco suing their nimble and hungry counterparts.

Did these start ups roguely take the ideas of their former employers? Or, are the large, enterprise conglomerates just looking to take down their up and coming competitors? Here’s a great article that’s a few years old, but still relevant entitled “Patent Wars: A New Age of Competition”.

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!

What Happens to Bad Software?

sadThere are a lot of things that happen to bad software. Back in the early 80’s, Atari decided to bury their bad software in the New Mexico desert. Literally, bury it.

It’s not 1983, but bad software still gets buried. It gets buried in a different sense. It gets bought by another vendor and “updated”, it’s “transformed” from a server-side application to a “cloud-based platform”, and lest we forget the “let’s customize the heck out of it until it’s unrecognizable and works better” (or worse in many cases) approach.

If you’ve been in technology for any length of time, you’ve probably worked with bad software. What makes it so bad? The bugs? The worthless GUI? The endless hours of futile user acceptance testing?  To me, it seems that there’s a gradual tipping point for bad software where the project goes from “Wow, let’s buy it” to “Well, let’s see how the requirements and design phases play out” to “did they even unit test this?” to “the end users hate user acceptance testing because the bugs are so bad”.

How can bad software be fixed? Or, can it be fixed at all?  Honestly, bad software is a real challenge.  You’ve got users who are being told by their managers that they have to use it, senior managers who are trying to ensure that they’re not scalped by their CEO / CFO for purchasing bad software, and a technical team managing so many workarounds related to the bad software that there are workarounds to the workaround.

If your project is using the Waterfall software development life cycle approach, the decision to pull or somehow salvage bad software has to be made early.  Don’t attempt optimism in the case of bad software.  If it’s broken and you know it, go back to the vendor and work with them to fix it before you roll it out to your end user population.  Keep in mind that this will probably throw your project into the red and you won’t be the most popular person until you get the project back on track, but it’s worth it. Talk to your stakeholders and explain the situation, because end users shouldn’t be held responsible for unit testing a bad software product.  However, if your project is using an Agile approach, you’re usually in a better place, as the 30 day sprints are more flexible and allow iterative changes to be made to the product.

As project managers, we’re responsible for the entire project, including (unfortunately) bad software. So, come up with a game plan to work with your vendors, stakeholders and project team to ensure that you aren’t rolling out bad software. Your end users will thank you!