Tag Archives: Implementation

The Opportunity of Failed IT Plans

Share twitterlinkedinmail

What went wrong in 2020?

I know, it’s a big question and most people would probably say “Everything.” Or at least, many CIOs would confess that the original strategic plans they had for 2020 were not executed.

There were many initiatives that just failed to get off the ground in 2020 due to COVID-19.

Now that 2020 is winding down — what happens to those initiatives? Should you try to execute on them in 2021? Are they even still valuable to your organization? Will you still have the capital for them? How can you afford them?

Smart CIOs know they can’t carry on as normal. Just because something was on the plan for 2020 doesn’t mean it should continue to be on it for 2021. Yes, strategic projects are still strategic, but it’s time to address whether the strategy has changed. If it has, the CIO has to know how to protect IT’s budget while shifting initiatives.

This is where the opportunity of a failed plan presents itself and where innovative CIOs can reset their priorities, align themselves with the rest of the organization, and ensure budget protection for 2021.

Revisit Your Organization’s Existing Strategic Plan

First, it’s important to understand what impact COVID-19 has had on your organization. This means more than just a workforce that is now working remotely. How did it impact the way your business operates and delivers value to customers? Did business models change? Did you add any new capabilities that are still contributing to ROI?

Now look at your existing IT strategic plan. Does it incorporate the changes made because of the impact of COVID-19?

It’s possible you could have some major changes to make to the IT strategic plan. For example, if your organization has added new revenue streams, then you may need to completely change the strategic plan to incorporate those new streams.

Look for Opportunities in your Value Streams

As you review what has changed in your organizations, you should also be identifying the opportunities for IT inside of this new strategy.

This exercise is best if you know the value streams in your organization (whether they are brand new as a result of COVID or they were already in place). If you don’t know the value streams of your organization, then now is the time to map them along with other members of the executive teams.

Remember, this is a chance for meaningful, impactful change. It’s no longer “business as usual.” We can’t say “Well this is the way it’s always been done” because organizations have proven they are capable of agility and making big changes quickly. When mapping value streams and looking for opportunities, don’t be afraid to open up to possibilities that might have seemed impossible a year ago. After all, most people would have said taking an organization completely remote in 48 hours would have been impossible this time last year but by now, most IT organizations have accomplished exactly that!

Fix any Value Leaks

Now, after you’ve reviewed value streams and are fired up about the new strategic projects you could bring to the organization in 2021, there’s a big question to answer: Where do you find the budget for it?

Some IT organizations were fortunate enough to have larger budgets this year while they enabled remote working — but those checkbooks won’t be as open in 2021.

Here’s what you can do right now to protect your budget in 2021

Look for the value leaks in your organization. Value leakage is a common problem in every organization but few leaders know to look for it. Businesses don’t operate on a consistent basis every single day. Value leaks can occur when changes in business workflows aren’t reflected in technology workflows, or people weren’t trained on new products or features, or when services or products aren’t retired appropriately. Value leaks occur due to poor communications, or when the organization fails to fully understand the costs and risks of any change, no matter how slight it may seem. If no one is monitoring value streams and measuring how value is delivered, then value will start getting dropped along the way.

In the context of protecting the budget for 2021, you can start finding and addressing the value leaks that are happening right now in 2020. When you start to fix the leaks, you can prove to the organization that you’re creating more value. The more value you bring to the table, the more you can justify your future budget and protect the budget for those bigger strategic projects you identify when mapping your value streams.

The Key is the Big Picture

The most important thing any CIO can do to seize the opportunity of failed plans is to not lose sight of the bigger picture. 2020 didn’t go to plan for anyone and every organization experienced shifts that will impact future strategies.

Your strategic projects from 2020 might still make sense in 2021. Or they might not. What’s important now is to look at how the organization delivers value to its customers and the opportunities for IT to enable and co-create that value. Then look at how IT can create even more value by fixing existing value leaks.

I think everyone will say that 2020 changed everything. But only the most innovative CIOs will be able to say that 2020 changed everything in the best way possible.

Share twitterlinkedinmail

What is DevOps?

Share twitterlinkedinmail

“What is DevOps?”

Taken at face value, the question may seem a bit rhetorical, but allow me to explain.

There is no single definition of “DevOps”. If you ask five people “What is DevOps?”, you’ll likely get five different answers.

Need some examples?

Here’s how Gartner has defined DevOps[1]: “A change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.  DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams.  DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

 Take a look at “The DevOps Handbook[2] by Gene Kim and others.  It states that DevOps is “…the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.  DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others…the result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and InfoSec.”

 One of my favorite definitions is from Rob England (aka “The IT Skeptic”). Rob describes DevOps as follows[3] : “Agile is the approach of working with complex systems anywhere. Lean is the approach of optimizing the flow of work anywhere. DevOps is the application of Agile and Lean to the acceleration of value work through IT.”

DevOps Defined?

Perhaps the best definition of DevOps is credited to Jez Humble, one of the co-authors of “The DevOps Handbook” who coined the term “CALMS”.[4] CALMS is a conceptual framework for integrating development and operational (DevOps) teams within an organization.  CALMS is an acronym for:

  • Culture – A culture of shared responsibility
  • Automation – Automate as many tasks as possible
  • Lean – Visualization of work-in-progress; limit batch sizes; eliminate waste; continuous improvement, focus on customer value
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – There are user-friendly channels for facilitating on-going communications

In most DevOps thinking and reading, CALMS seems to be a common theme.  But I also encounter a lot of DevOps “anti-thinking” as well.

What DevOps is not

Here are a few examples of DevOps “anti-thinking” that I’ve encountered.  DevOps is not:

  • A standard – There is no documented “DevOps” standard.
  • A tool – There are literally hundreds of tools (I’m not sure if this is a good or bad thing) that claim to be “DevOps” tools. The point is buying a tool does not make your organization a “DevOps” organization.
  • A best practice – There is no defined “body of knowledge” or designated reference for DevOps. In fact, there are literally hundreds of books about DevOps, and some (highly visible) examples of organizations that have successfully adopted DevOps thinking. But there is no designated DevOps “best practice”.
  • Just automation – While automation is perhaps one of the most visible aspects of DevOps, automation alone is not “DevOps”.
  • A silver bullet for IT issues – Just saying that you’re “doing” DevOps is not the same as addressing communication issues, collaboration challenges, wasteful processes, poor measurement practices, eliminating technical debt, and other organizational problems.

What is DevOps?

So, what is DevOps?  At its core, DevOps is a mindset; a way of working together. DevOps is:

  • About building trust and teamwork, sharing knowledge, taking accountability – Teams build trust when members can rely upon one another. Trust is built when team members openly and willingly share their knowledge and contribute to the success of the team.  When mistakes happen, the member making the mistake acknowledges the error; but more than that, there is no blame; the team works together to resolve the error.
  • About tearing down the walls that exist between working groups within IT – DevOps can only be successful when all parts of the IT team are part of the success.
  • About creating a culture of experimentation and learning – Too many organizations work in fear of failure. Much about DevOps is about empowering and learning.
  • About improving the productivity of the overall organization – Sometimes that means searching out and eliminating waste or streamlining the process. If it’s taking too long to get code to trunk and then tested, what can be done to improve that?  If standing up a new development environment requires manual intervention, what could be done to standardize that work so that manual intervention is no longer required?

Avoiding DevOps “Ditches”

Knowing what DevOps is and is not will help you get on the road to success. Here are five ditches to avoid to achieve success with DevOps.

  • Purchasing and implementing tools before anything else – DevOps adoptions taking this approach usually fall into the old “hammer and nail” syndrome (“when all you have is a hammer, every problem looks like a nail”). Well, just because you own a hammer and can swing it doesn’t make you a carpenter.  One of the most common mistakes with DevOps adoption is too much focus on tool implementation and automation of (often poorly or even undefined) processes. When all you have done is implement a tool without designing processes or developing teams, you’ve not “DevOps”- you’re just using a tool – and likely not getting the full benefit of that tool.
  • Getting hung up on semantics – Developers and operations both have developed their own specific languages for what each group does – and this often causes confusion. Take the time to define and agree on a shared terminology.
  • Developers running over everyone else in the organization under the flag of “we’re doing DevOps” – Once, while at a client site, I heard a “DevOps engineer” (seriously) tell a sysadmin that “I’m about to automate you out of a job.” Not a very collaborative, teamwork attitude, huh?  DevOps is about building teams whose members trust and rely on each other- not trying to dominate or control.
  • Arbitrarily throwing out existing process and procedures – Although a process may not be performing as effectively and efficiently as desired, don’t overlook the fact that there was a good reason why that process was defined and implemented in the first place. In my experience, process design and implementations have been treated as “one time” activities and rarely revisited to identify improvements or needed changes.  Before getting rid of an existing process, first understand the reason for the process, and if that reason still exists today.  Then look for ways to improve that existing process, rather than just throwing it away.
  • Ignoring the need for organizational change – DevOps adoption represents a significant change in the way IT does its work. Without good communication, appropriate training, and a shift to a “thinking / experimentation / learning” mindset, DevOps adoption will fail.

Keep CALMS and DevOps on

Knowing what DevOps is and is not is key for success in adopting DevOps.  Following the CALMS model ensures that you’re addressing the complete extent of DevOps adoption, and not just being fixated on a single aspect.

Need help answering the question “What is DevOps?”  Want to build a fundamental understanding of DevOps?  Tedder Consulting offers the DASA-accredited DevOps Fundamentals class.  Visit  our training page to register for an upcoming class! 

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Picture Credit: Pixabay

[1] https://www.gartner.com/it-glossary/devops , retrieved 8/11/2018.

[2] Kim, Gene, et al. “The DevOps Handbook”. IT Revolution Press, LLC. 2016. Portland, OR

[3] http://www.itskeptic.org/content/laymans-definition-devops, retrieved 8/11/2018.

[4] https://whatis.techtarget.com/definition/CALMS , retrieved 8/11/2018.

Share twitterlinkedinmail