Contact ITInvolve
x 


ITinvolve Blog

ITinvolve Blog

Archive for the ‘Change’ Category

Knowledge is Power:

Monday, June 16th, 2014

A breakthrough approach for Change, Config, and Release

Today, we were thrilled to find out the ITinvolve has been awarded the best-in-class designation for Change, Configuration, and Release Management by the independent ITSM Review.

This award acknowledges what our customers already know and reflects the vision, innovation, and effort that ITinvolve’s R&D organization has put into building a breakthrough solution for a rather stagnant market. The result of a months-long evaluation that included extended demonstrations and deep dive Q&A with an independent expert, we are simply glowing at what they had to say:

“ITinvolve has taken huge strides in the ITSM arena with Service Manager by embracing the adage “knowledge is power”.  We feel that the developments that ITinvolve Service Manager has made with the fundamentals of knowledge and collaboration, ensuring that all relevant information is available to the right people at the right time (and in a straightforward way), enables risk assessment capabilities that far outweigh those of other ITSM solutions. This provides increased value to its Change, Configuration and Release capabilities.”

“The way that these capabilities support and mold Change, Configuration and Release creates a product that gives control, intelligence and awareness back to the IT organisation.”

“ITinvolve Service Manager is a progressive and ambitious product. Uniquely combining knowledge capture, analysis, and social collaboration, Service Manager proactively delivers timely and relevant information whenever needed.”  

“…regardless of the size of your organisation, we strongly believe that you can’t go wrong with considering ITinvolve Service Manager as your ITSM tool for Change, Configuration and Release.”

Learn more about ITinvolve Service Manager and sign up for a free trial.

Matthew Selheimer
SVP, Marketing

 

What’s Your Discipline?

Friday, March 14th, 2014

For those of us working in IT, it’s pretty impressive the list of disciplines that have been defined over the years to manage an IT organization and the functions it’s responsible for.

In response to this, some vendors have built different applications for every discipline, which creates or reinforces silos in processes and organizational entities. At ITinvolve, we’re interested in a different approach; an approach that is grounded in information and knowledge sharing, that reinforces collaboration across silos, and arms IT knowledge workers with the information and analysis they need to do their jobs more effectively without having to go hunting for information across applications.

Our approach takes the elements you manage in IT every day from requirements to releases, servers, network devices, firewalls, policies, and much more and puts the information you need in context of those elements and the relationships that bind them together.

In this way, the information you need can be accessed and managed from multiple perspectives. For example:

  • Show me all applications that are governed by our PCI policy
  • Which requirements made the cutline for the next release?
  • If I take this server offline to upgrade the OS, what will be impacted?
  • Who is responsible for this middleware component?
  • Let me see how many instances of that database version we have running production
  • What’s in our service catalog?
  • Is there a known workaround for this issue?
  • What parameters are in this automation?
  • What are the fragile settings for this application?

This is a very small sample list of the powerful types of questions you can ask and the information freely available at your fingertips in ITinvolve.

While ITinvolve doesn’t cover every discipline in IT, we do support quite a few of the disciplines you will find in any good size IT organization.

Check them out:
Disciplines We Support

Matt Selheimer
VP, Marketing

5 Problems With the IT Industrial Revolution

Wednesday, January 22nd, 2014

Over the last several years there’s been lots of talk about the need for an ‘industrial revolution’ in IT. We’re actually pretty big fans of the metaphor here at ITinvolve.

I think it’s well accepted that IT needs to improve both its speed of service delivery and quality. These are classic benefits from any industrialization effort, and they both create ripple-effect benefits in other areas too (e.g. ability to improve customer service, increased competitiveness).

But despite all the talk and recommendations (e.g. adopt automation tools, get on board with DevOps), there are five common problems that stand in the way of the IT industrialization movement. A recent Forrester Consulting study commissioned by Chef gives us some very useful, empirical data to call these problems out for action.

#1 – First Time Change Success Rates aren’t where they need to be. 40% of Fortune 1000 IT leaders say they have first time change success rates below 80% or simply don’t know, and another 37% say their success rates are somewhere between 80% and 95%. You can’t move fast if you aren’t able to get it right the first time, because it not only slows you down to troubleshoot and redo, but it hurts your other goal of improving quality.

#2 – Infrastructure Change Frequency is still far too slow. 69% of Fortune 1000 IT leaders say it takes them more than a week to make infrastructure changes. With all the talk and adoption of cloud infrastructure-as-a-service, these numbers are just staggering. Whether you are making infrastructure changes to improve performance, reliability, security, or to support new service deliveries, we have to get these times down to daily or (even better) as needed. There are a lot of improvements to be made here.

#3 – Application Change Frequency is just as bad. 69% of Fortune 1000 IT leaders say it takes them more than a week to release application code into production. Notice that it doesn’t say “to develop, test, and release code into production.” We’re talking about just releasing code that has already been written and tested. 41% say it still takes them more than a month to release code into production. Hard to believe, but the data is clear.

#4 – IT break things far too often when making changes. 46% of Fortunate 1000 leaders reported that more than 10% of their incidents were the result of changes that IT made. Talk about hurting end user satisfaction and their perception of IT quality. What’s worse, though, is that 31% said they didn’t even know what percentage of their incidents are caused by changes made by IT!

#5 – The megatrends (virtualization, agile development, cloud, mobile) are intensifying the situation. As the report highlights, these trends “cause complexity to explode in a nonlinear fashion.”

So what can you do about this if you believe that “industrialization” and, therefore, automation is the answer (or at least a big part of the answer). Well, first, you have to make sure your automation is intelligent – i.e. informed and accurate. Because we all know that doing the wrong things faster will make things worse faster.

This is the problem we’re focused on at ITinvolve; helping IT operations and developers – by giving them the knowledge and analysis they need, then facilitating collaboration to validate accuracy. Good automation must be driven by a model that fully comprehends the current state of configuration, the desired state, and the necessary changes and risks to get there. It’s only when armed with this information, can automation engineers effectively build out the scripts, run books, etc. to deliver agility with stability and quality.

Matt Selheimer
VP, Marketing

 
Published in APM Digest:

 

The Ends Justify The Work

Monday, December 2nd, 2013

My first big corporate IT job was with a major electronics company. I did desktop and server support for the smallest business unit in the company that had maybe 200 employees and just north of a billion dollars in annual sales. I loved working for the smallest group in a big company, because I got to know most of the 200 folks that worked there and I had access to all of the resources of a Global 50 company.

About 6 months into the job, the Director of my group left and a new guy was brought in. The new guy was fanatical about customer service and creating a partnership with the business. I immediately liked him. Unfortunately, not too many others did. He wanted to change things in a big way, but no one else wanted to change. He only lasted a year, but in that year he did a few things that helped shape how I approach my work to this day.

One of his first actions was to send everyone in IT to a 7 Habits of Highly Effective People class. Being the good corporate citizen that I am, I negotiated attending the class in San Diego as it was only 90 minutes away from a sales office that I supported just outside of LA. I could save the company money by combining the 7 Habits class with a site visit to the office. Did I forget to mention that this was in February and it was zero degrees where I lived?

I loved the class. 20 years later, the primary thing that I remember and try to use daily is this – Habit 2: Begin with the end in mind.

Basically, how can you get somewhere if you don’t really know where you’re going? This is amazingly relevant to folks in IT, yet rarely practiced.  We usually do a good job at our assigned tasks, but do we really understand why we’re doing them? Everyone from code developers to infrastructure people to support and operations folks are working towards a common goal. That goal is to move our respective businesses forward. Unfortunately, we’re usually too busy being heads down on our individual tasks to see and understand what we’re really doing.

My company, like most companies, had a set of annual goals. As I recall, they went something like this:​

  • Deliver great products and service
  • Service existing customers well
  • Innovate to deliver new products
  • Improve the quality of existing products
  • Improve customer retention

IT plays a key role in the achievement or failure to achieve these goals. For example, the project you’ve just been assigned to that requires you to work late nights over several months wasn’t funded and put in place simply to keep you busy. It was funded and put in place to achieve one of those company goals.Unfortunately, many rank and file IT practitioners aren’t really aware of their employer’s goals, let alone how their daily work supports them. I’d go so far as to say that many managers, directors and even higher ups would struggle to list the company goals for the year.

So, why is this a big deal? Some might say, “I don’t need my database developer to be aware of what the company is doing. I pay her to develop databases.”That’s both correct and completely wrong at the same time. Yes, you might hire her to develop databases,but what is your company actually paying her for (hint: it’s not just to develop databases)? She is a member of the company as a whole, not just some cog in an IT wheel. She is a stakeholder in the company’s success, and chances are she’s pretty good at what she does otherwise she would have been let go or outsourced.

Regardless of how good your IT team members are, I think the majority of them can make more of an impact and feel satisfied by their work just by understanding why the work they do is important to the business.

Case in point – I remember being in a meeting at a pharmaceutical company I worked for some years later. The purpose of the meeting was to discuss how we were going to roll out a new application to support what our Research and Development teams were doing. The conversation got way down into the technical weeds and I blurted something out like – “It doesn’t need to be this hard…It’s not like we’re trying to cure cancer here.”  A very quiet gentleman at the head of the table cleared his throat, stood up, walked over and gave me his business card. He was the VP of Oncology R&D. He was trying to cure cancer. My company was trying to cure cancer and that meant each of us in IT were trying to cure cancer – including me. Talk about a wake up call.

This one meeting was a shot in the arm to remind me again to always practice Habit 2: Begin with the end in mind. If you know where you’re going, it’s going to be much easier to get there and help you make better decisions along the way.

After that meeting, I put some time on my Director’s calendar and asked him to work with me over the coming days to help me map what my team did to what the company’s business goals were. In some cases, it wasn’t that easy. How did a new storage array contribute to releasing 10 new pharmaceutical compounds?  How did a new desktop image enable revenue growth of at least 7%?

This is our challenge in IT, and you have to figure it out. Teach you peers and the folks on your team that by organizing your projects and tasks according to business goals, it’s going to be easier for everyone to prioritize your work and make better decisions. It’s going to be easier for everyone to go through your end of year review and answer questions like – “What did you do last year that was valuable to the company?”

What we do in IT matters. It matters to our customers. It matters to our employers and it should matter to us. But, first, you must understand how your work enables the business to achieve its goals. Only then, will you fully understand why your work really matters.

If you’re a rank and file member of IT that can’t get answers from your boss to help you connect your work to business goals, then keep pushing but also take the initiative yourself. Read your company’s annual reports and SEC filings. Maybe even take the bold step of requesting a meeting with your CIO. Walk into that meeting and say, “Hi, I work in this department and I do X. I want to help our company move forward as best as I can. I’ve been reading about our company goals and I want to be sure the work I do supports them. Can you help me validate that the work I am doing is what the company wants me to focus on to help deliver on our goals?” You may be very surprised (in a good way) at the response you get.

Joe Rogers

Director of Technical Services

Knowledge isn’t free and neither are the donuts

Wednesday, November 20th, 2013

One of my former bosses is a Naval Reservist. Once a month, he goes away for the weekend to do his job for Uncle Sam. In the break room of whatever building he’s working at, there is a sign above a table that says – “Freedom isn’t free, Neither are the Donuts.” The idea is that if you take a donut, you’re supposed to drop some money in the jar so the tomorrow’s donuts can be purchased.

This got me thinking about other things that have costs associated with them, like experience and knowledge. So with a hat tip to the Navy, I submit that “Knowledge isn’t free, Neither are the donuts.”

There is a cost to developing and utilizing knowledge. There is the time it takes to develop the knowledge. For example, someone needs to write it down, make the video, etc. That takes time, which has a cost associated with it. An obvious cost is the knowledge developer’s hourly wage, but what about other costs? What else could that knowledge developer been doing instead of documenting the knowledge? Is their main job to develop knowledge or do they have other duties that have to be put on hold while they document?

We’ve gotten used to having much of the entire world’s knowledge in the palm of our hands via the Internet, Google and our smartphones. We can search for an answer to just about any question we might have, and at least 99% of the time, we can get a reasonable answer. Of course, depending on the question, I may have to spend time weeding through a whole bunch of entries to find it. I may have to ask the question a few different ways, or (heaven forbid) try to remember a little bit of Boolean logic to filter out unwanted results. In this sense, there is a very real cost with not just documenting but also accessing knowledge — my time.  What else could I be working on instead of trying to find this information?  How much time am I spending piecing together information, data or knowledge from other sources to figure out the truth?

Now, let me repeat this exercise, but with my work hat on. I vividly remember a few years ago that I was desperately searching for information to help me with a high priority project I was working on — upgrading the Point of Sales (POS) system. [The project goal was to deploy a newer version with better reporting capabilities for our logistics folks.] In this context, I was no longer going to my phone and googling something, instead I had to find and then go through tons of information about my company’s implementation and use of the POS system. No longer was everything nicely catalogued and key worded. No longer was everything easy to find. There were literally hundreds of places that I needed to go in order to find the data. There were build documents, CMDB entries, a bunch of Sharepoint sites, dozens of emails, file shares, several change management requests, some Wikis, and much more. The stuff was scattered everywhere and I had no idea if the three-year-old Visio diagram that I found was in any way representative of what was currently humming along in our data center 600 miles away.

So that meant I now had to seek out people – experts that could provide me with additional information or at least validate the information that I had earlier found. But first, whom did I need to talk to? The author of the Visio left the company 18 months prior. The VP of Retail Operations, who signed off on the Functional Requirements Spec, now worked for a competitor. Just trying to figure out the people who could maybe get me the information that I needed to do my job was a full time job unto itself. And, this wasn’t my only project, I had 15 other projects at the same time that I was involved with. Unfortunately, those other projects (and their value to the business) had to wait — even though people were waiting on for a number of tasks.

Fast forward a few weeks, and I’ve now got a bunch of information that I’m told through various meetings, phone conversations, and emails is current. I have a bunch of new hard copy documents on my desk, a picture of a white board diagram that a DBA spent an hour drawing for me, lots of emails, word documents, PDFs, you name it. I added that to the information I got from the vendor, information from three of our six CMDBs as well as some reports from three different monitoring tools. Now, I could finally start working on my tasks for the project.

I probably spent at least 30 hours trying to look for and validate this data and information. As an architect, my fully loaded hourly wage was around $75. So just assembling this information cost my company $2,250 not to mention the time that it cost from everyone I talked to which was easily several multiples of that. Plus, they all had other things to do that I was pulling them away from and there is a cost to that too.

Now the fun began. We didn’t have money for new hardware for this project so I had to make sure the new version of the POS software would run on what we had already. I went through all the information I had assembled. The build specs, in particular, were hilarious. Each was 60 pages long and there was so much boilerplate and filler in each one that it was mind numbing to read them all. Our CMDBs were filled with a bunch of useless (for my purposes) information that had been populated by our auto discovery tools, and I quickly started to drown in information. What I really needed to understand were just a couple of configuration settings to see if they were A) required, B) needed to be updated or C) completely irrelevant to what I was doing.

Aside from the Easter Egg hunt that I had to go through just to find the information I needed to do my job, I found the information itself was barely relevant. My company made IT people fill out all of this paperwork when they did something or built something, and most of these folks are IT majors not English majors. The people that came up with the document templates probably had no idea what kind of information would need to be captured, so what you think would be in one section is in another or the information didn’t fit the template so it had to truncated.

At this point, I didn’t have much confidence this upgrade will be successful. There were just too many unknown or little knowns, and it wasn’t from a lack of data. I actually had too much that it was hard to find the proverbial needle in the haystack I needed. What’s worse, what I had was mostly bad, or old or incorrect data. I couldn’t trust it and it didn’t provide the right context for me to effectively use it.

Unfortunately, this situation is very typical of many IT shops – the information and knowledge is not well documented and what is documented is a huge mess. IT information has a lifecycle of its own and the common methods of documenting, collecting, and accessing IT information are inadequate. IT Information is a living, breathing thing that must be nourished and maintained on an ongoing basis as part of daily work, because no one has time to do it after the fact. And even then, we’re really good at burying it in file shares, spreadsheets, emails and Sharepoint sites, so as soon as the information is created, it’s quickly forgotten about and withers and dies.  Then, you’re like me in this story, where all you have left is a corpse of information that might have ben useful once but probably doesn’t have much value today, because we move  so fast and what was true yesterday isn’t true today since that OS patch was put in place or the backup schedule was updated.

So what happened with the POS upgrade? Well, even with my lack of confidence, the change request for the upgrade was approved – because it had to be. There was no testing because we didn’t have a properly configured test environment, but I did ensure we had a full backup just in case something went wrong. We held our breath and we rolled it out. Amazingly it worked out okay, but to this day I feel like we just got lucky. Knowledge isn’t free, and this all to common status quo is no way to run an IT shop when your business depends on it.