Tag Archives: process

Are Processes Killing Your Productivity?

Share twitterlinkedinmail

Every IT organization knows that good processes are critical to the success of a company. The right processes can improve efficiency and create an organized workflow. However,when taken to the extreme, processes can kill productivity and ruin your team’s morale.

Let’s take a step back and talk about processes and why they matter.

Processes are a defined sequence of tasks that keep the organization running smoothly. Processes provide organizations with a way to measure progress and productivity, which can help a team feel more efficient and accountable for their work. Standard processes create a consistency of work and provide a foundation for continuous improvement. Lastly, defined processes enable automation, which helps IT become more responsive to business demands.

So we can all agree that processes are a good thing in business. Except for they when they get in the way or go out of control. Many studies are showing that processes are beginning to hinder productivity across the globe.

In a study of U.S. and European companies, The Boston Consulting Group found that “over the past fifteen years, the amount of procedures, vertical layers, interface structures, coordination bodies, and decision approvals needed…has increased by anywhere from 50 percent to 350 percent.”

The same report found that in larger and more complicated organizations, managers “spend 40 percent of their time writing reports and 30 percent to 60 percent of their time coordinating  meetings.”

This does not leave much time to actually accomplish the work that needs to be done.

How can you tell if your process is working or if it is killing your productivity? There are a few ways you can test your processes.

1. Does the process accommodate all projects?

Processes cannot take a narrowly-defined, “one size fits all” approach. l. As an IT organization, your team is most likely handling a wide variety of projects. Your processes have to accommodate the variety of projects while at the same time providing needed consistency.   

Agility is just as important as having a standard process. Today, new technologies are coming to market at lightning fast speeds.Businesses are adopting technologies quickly and demanding that the IT department keep up with supporting these new technologies.

IT needs to be able to react quickly to these needs. If a process was not designed for agility or to accommodate the variablity found within a specific project, IT cannot react quickly. When you insist the process stay exactly the same for every project, you are asking your employees to try to sprint while attached to a ball and chain.

Too many organizations fall into the “process for process sake” mindset. They insist on maintaining every aspect of a process for every project, even when it doesn’t make sense.

If you find that your process has worked really well for some projects but did not work well for other projects, we recommend examining where the process stopped working. Take a look at the areas where flexibilty or a different approach is needed. Don’t lose sight of the end-goal for the process and the goals of the projects.

2. Are you focusing more on the process than the people?

No matter what innovative technology exists, it’s the people who make your business run, not the technology. Process should enable people to take advantage of the technology, not inhibit the use of technology.

When leaders focus too much on the process and ignore the needs of their team, the team doesn’t feel empowered to do their job effectively.

It’s not empowering when individuals are given more responsibility yet still have to obtain a large number of approvals and sign-offs to get anything done. This signals a lack of trust to your team.

Leaders need to start relying on their team’s expertise and experience just as much as they rely on the process. When you start to do this, you can often improve your processes because your team feels empowered to do so.

It’s critical to empower with action, not with permission. When your team is empowered to take action to get the job done, they feel a greater sense of pride in their work, are more invested in the project and more appreciated by their bosses.

When jobs depend on meeting metrics or process approvals, the creativity and innovation of teams suffer. The last thing you want is a team who can’t – or won’t – find ways to innovate and improve.

3. Are you relying on tools too much?

We’ve seen it time and time again. Organizations invest in a very pricey tool. They implement it one way and create a process around it and then they try to force that tool and process onto every problem that arises in the business.

Tools are fantastic but they are not problem solvers. People are problem solvers and your tools and processes should be built around the people and the problem that needs to be solved.

Processes built around tools are doomed to fail but processes built around problems and supported by employee action will always work.

4. Do you have process silos?

Organizations that are siloed will always struggle with processes. For example, what happens when IT has a process for onboarding a new employee and HR has their own process for onboarding and they are completely separate? Undoubtedly, it causes unnecessary extra work and possibly, some confusion for the new member who is being onboarded.

This is where cross-departmental communication and collaboration must come into play. Linking processes across departments and achieving buy-in from team members in both departments will avoid wasted time and energy.

Again, this will rely on your process being agile (see the first point) as you may need to adjust several of your processes to become cross-functional with other departments.

Work with other department leaders to understand their processes and determine how you can combine the two into cross-functional processes. Then clearly define and document these processes so that there is no confusion across teams.

5. Have you avoided process audits?

If you’ve learned anything from this article, we hope you’ve learned that processes are ever-evolving. They are constantly shifting to adapt to the growth of the organization and the specific project at hand.

So it’s necessary to perform regular process audits to ensure your processes are working to the best of their ability and improving the productivity output of your team.

How do you perform a process audit? It’s best to start by looking for any drops in productivity during the process or where output slows down. Additionally, monitor for signs of unhappy teams. Do you see resistance from the team at any certain stage?

Look at your processes and determine if any piece of it does not add value. If you’re unsure, speak with your team on this. Since they are using the processes, they will know what are the most valuable and impactful parts of it.

Let’s be clear on one thing: I am an extremely big fan of having documented, well-defined processes in your organization.

But I want to encourage you as the business leader to always be monitoring processes and keeping your eyes on the end goal and the people implementing and using the processes.

Focus on people and improving communication and innovation so that you can solve business problems. The process will fit naturally and be more powerful when they are viewed as the means to a goal and not the goal itself.

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

Nine signs that it’s time to expand ITSM into the Enterprise

Share twitterlinkedinmail

I read a lot about how organizations have stood up a centralized service desk, a self-service portal, and called that “enterprise service management”.

While these two deliverables may be good things to do, I don’t think that these two deliverables in and of themselves represent “enterprise service management”.  Such an approach only perpetuates what many organizations have done with ITSM – just address the (relatively easy) operational aspects of service management, without doing any of the needed work to identify and underpin the end-to-end flow of value within IT.

What expanding ITSM could do for the enterprise

Having said that, I do think that expanding ITSM into the enterprise could have a significant and positive impact on the organization.

Expanding good ITSM into the organization would standardize how work gets done.  Standardized work improves both the productivity and the throughput of work through the organization.

ITSM would bring clarity and transparency into how value flows through the organization.  Good ITSM would result in the identification and definition of services and processes that underpin the organizational value streams of a business.

Good ITSM across the enterprise would bring repeatability, reliability, and measurability to all aspects of the organization.

All of the above are good things that expanding ITSM could do for the enterprise.

But how do you know its time to expand ITSM into the enterprise?

Nine signs that it may be time to expand ITSM beyond IT

Here are my top nine signs (in no particular order) that it may be time to expand ITSM beyond IT.

  1. Published IT performance reports depict business measures or results, not IT or technology metrics. Published reports reflect success measures that are outcome-based and relevant and meaningful to the business.
  2. Business colleagues outside of IT take an active, engaged role in service management activities. Business colleagues actively participate in CAB meetings; the ITSM steering committee has significant participation from business colleagues, and some (most) services have a service owner that does not work within IT.
  3. IT is a valued contributor and partner in business strategy development. The IT service portfolio is regularly reviewed by key business decision-makers and is a critical input to technology investment decisions, work prioritization, and managing demand.    IT personnel – at all levels of the organization – participate in business strategy and planning meetings.
  4. The IT-Business relationship is one of being “colleagues”, not “service provider and customer”.  With IT and business colleagues working as an integrated entity, efforts are focused on the true customer – the person or business that ultimately buys a company’s products and services.
  5. Business colleagues have a consistently good experience in their interactions with the IT organization. Performance is predictable and consistent. Communications are appropriate, relevant, and timely.  Issues are addressed and managed in a professional manner.  There are active, positive business – IT relationships.
  6. The IT organization is working as an integrated team. There are no “Dev vs. Ops vs. QA vs. Security” attitudes within IT, but rather a culture of collaboration. The IT organization has recognized that there is no “one size fits all approach” and has learned how to effectively incorporate and leverage the strengths of different methodologies to deliver business value.
  7. ITSM processes are lean, effective, and provide “just enough” control. Processes are as simple as possible, friction-free, and have little, if any, waste.  Roles and responsibilities are clearly defined, understood, and embraced.  Processes facilitate getting work done, rather than act as a barrier to getting work done.
  8. The IT organization acts and communicates in business terms. The service catalog articulates what IT does in terms of business value and outcomes. IT consistently demonstrates good business acumen. The business relationship management function is established and proactively ensures that the business realizes value from its investments in IT.
  9. IT promotes and communicates how ITSM is benefitting the organization. ITSM successes (and learnings) are regularly publicized – and the business is feeling the positive impact from ITSM implementation and use.

But even if all nine (or most) of these signs are present, it still may not make sense to expand ITSM into the enterprise.

The ultimate sign that it’s time to expand ITSM into the enterprise

What is the ultimate sign that it’s time to expand ITSM into the enterprise?

Your business colleagues ask for it.

Just because IT thinks this is a good idea isn’t sufficient justification for expanding ITSM across the enterprise.  Expanding ITSM into the enterprise must be a business initiative, not an IT initiative forced upon the business. Why?

Business colleagues may not know anything about ITSM.  They may not even be aware that the IT organization is doing service management.  But, business colleagues feel that they have consistent, good experiences in their interactions with IT.  They get real business value from services delivered from IT. They see how wider use of the concepts being used by IT can benefit the organization.  And, most importantly, they want to expand those concepts across the enterprise.

But to have success with expanding ITSM concepts into the enterprise, Enterprise Service Management (ESM) is not as simple as dropping the ‘IT’ and adding an ‘E’. The business must own ESM.   The business must dedicate and invest resources to ESM.  There must be commitment to ESM being successful.  There must be a willingness to do the required “care-and-feeding” across the organization, not just within a department or two.  The enterprise must adopt an attitude of continual improvement.

Getting ready to expand ITSM into the enterprise

While there is much that can be leveraged from a good ITSM implementation to jumpstart an ESM implementation, here are six steps that will ensure that ESM will be successful.

  • Build the compelling business caseBusiness value consists of five factors – increased revenue, decreased cost, improved productivity, competitive differentiation, and improved customer satisfaction. The business case for ESM must address at least one of these five factors; doing so will help you get the support and funding needed for ESM.
  • Form a cross-functional team – Again, ESM has to be a business initiative. This means that a cross-functional team consisting of both business colleagues and IT staff are required for ESM success.
  • Identify enterprise-level services – An IT service only depicts the “middle part” of an enterprise-level service. There are business activities that occur both before and after the IT service is consumed. What are those activities? Who is accountable for the quality and results of those activities?  Identifying and defining enterprise-level services is critical for ESM success.
  • Identify organizational value streamsHow does work get done across the enterprise? Just like an IT service often involves multiple parts of the IT organization, the same can be said for enterprise services.  Rarely (if ever) does an outcome or result delivered to the customer only involve a single department or work group within an organization. ESM must underpin an organization’s delivery of value.
  • Define good processes – IT’s expertise in defining good ITSM processes can be leveraged to help the enterprise identify and document its processes. But processes must facilitate, not control, getting work done. This may represent a mind shift change for those new to service management.
  • Take an iterative approach – As with ITSM implementation, ESM implementation must be an iterative activity. Start with a smaller enterprise value stream.  Define and apply service management concepts, learn what worked well, identify improvements, then repeat the cycle with the next enterprise value stream. There is no need to “boil the ocean” – make steady, incremental progress toward ESM goals.  Adoption and success will be much greater.

The digital consumer is demanding that businesses act as unified entities, rather than collections of parts.  This means that all parts of an organization must collaborate to deliver the value and results that the digital consumer wants.  Expanding good ITSM into the enterprise is a way to meet the demands of both the digital consumer and the digital economy.

Share twitterlinkedinmail