Waterfall and Agile are both process methodologies with very different approaches to achieving the same goal: developing high-quality products. Where Waterfall focuses on strict requirements and planning, Agile provides a more adaptable approach where it's much easier to adjust requirements and timelines as the product develops. Both methods have their pros and cons, hopefully this article will help clear up which one is right for your project!

What is Waterfall?

Waterfall is a linear and sequential process methodology. It breaks up projects into several distinct phases, with a complete product being delivered only after the final phase is successfully finished. An example of these phases may be something like: 

Requirements > Design > Development > Testing > Implementation

These phases are completed in order, where all tasks associated with that respective phase are complete before the next phase can begin. The teams required in each phase can be distinct, and may require only slight overlap between phases. Both the customer requirements and timeline are established early on within the product development life-cycle. The Waterfall methodology really excels when product requirements are strict, and the goal is to provide complete product within a specified timeframe and budget.

As someone that comes from a background developing manufacturing processes, the waterfall methodology was basically a way of life. Every new product life cycle began with Advanced Product Quality Planning (APQP) and its phases:

Planning > Product Design & Development > Process Design & Development > Product & Process Validation > Production

These processes are followed in order, with a review at the end of each phase by their respective team. In most cases, shortly after beginning production for one project, the planning phase for the next project would already have started, and so on. The strict product requirements, tight deadlines and long lead times to design and build manufacturing equipment lends itself well to waterfall. Lead times for manufacturing equipment can range anywhere from 3 months to over a year depending on complexity, so establishing clear product requirements early is imperative. Any change to the product or process requirements could result in extreme delays to the project.

Pros

• Project timelines, budget and progress are easier to manage and measure throughout distinct phases.
• More hands-off for customers after initial requirements and timelines are established.
• Detailed documentation is more readily available.

Cons

• Need strict requirements very early on, changes to these requirements can be costly.
• Less overlap and communication between teams makes collaboration more difficult.
• The testing phase occurs much later in the project, so any issues found can be expensive and delay projects drastically.
• Distinct teams, rigid timelines and budget constraints make it difficult to move back to a previous phase if issues arise.

What is Agile?

Agile is an iterative and highly adaptable process methodology. Agile focuses on breaking down projects into small product releases that can then be iterated on to make improvements. These iterations go through all phases of a project simultaneously. This allows a team member to be testing out one feature, while another is designing a different feature. With all of the phases of a project moving simultaneous, having a fully cross-functional team engaged throughout each iteration is imperative. After each iteration is complete, clients can review the most recent release and set priorities and goals for the team in the following iterations. The Agile methodology excels when requirements may need to adapt as the customer's needs develop, and there aren't strict requirements for timeframe and budget.

Software development is one of the key uses for the Agile methodology. With new product requirements frequently coming up and an on-going timeline for completion, breaking the project down into continually improving iterations is a much better way to control changes. With each new iteration, clients will find new beneficial features they'd like implemented, and these feature requests will be turned into tasks to be planned for future iterations. The average time for an iteration is usually between 1 and 4 weeks, so clients frequently get a look at the current state of the product and are able to evaluate priorities for future iterations accordingly. Agile works incredibly well when requirements are not fully established up front, which is usually the case with software development projects.

Pros

• Highly adaptable and works well when customer requirements are not completely established up front.
• Fully cross-functional teams promote higher collaboration than distinct teams.
• Frequent customer communication helps ensure requirements are being met and customer satisfaction is high.
• Testing is performed concurrently with development during each iteration, leading to faster identification and correction of issues.

Cons

• Tracking timelines, budget and project progress is more difficult across multiple iterations.
• Additional iterations can lead to lengthened timelines and increased budget.
• Documentation is usually lacking between iterations.

At Praecipio, we have more than 15 years of experience helping clients big and small become the best version of themselves; if you have questions on Waterfall, Agile, or any other process methodology, reach out and let us know, we'd love to help!

Organizations are rapidly moving toward new work management styles, especially in the age of digital transformation. If you work in project management, you've probably heard the term "Agile" at some point in your career. Maybe you've considered taking this approach with your teams, and have already done some research. "Scrum" is another term you've most likely heard during your research. Although this is a term used in rugby, it is also a specific methodology teams use to work in an Agile manner. At Praecipio Consulting, we've assisted many teams 

with their move to Agile, using the Atlassian toolset to support and ease their journey. We've also worked with many teams who use Scrum specifically, but many use different frameworks - using Scrum is not a requirement to be Agile. Let's take a moment to understand the difference between Scrum and Agile.

What is Agile?

Agile is a project management style in which organizations use an iterative process to continuously deliver work while consistently receiving and incorporating feedback throughout the process. Flexibility is key, so teams can quickly adapt to market changes and customer needs. Agile has a set of principles and values organizations are expected to follow, laid out in the Agile Manifesto. The Agile Manifesto does not delve into specific practices and activities teams should follow in order to work in an Agile way: it serves as a north star for organizations to align to in their Agile journey. There are a few Agile frameworks teams can use to work in an iterative manner, such as Scrum and Kanban. Agile puts an emphasis on people over processes and tools, and gives autonomy to the people on those teams. With that being said, it is up to the teams to decide which framework works best for the way they work and the work they're delivering. 

What is Scrum?

Scrum is one of the many frameworks teams can use to work in an Agile manner. It is mainly used by software development teams, and relies on time-boxed iterations called Sprints. Sprints are made up of the work developers commit to completing within that iteration, typically 2 weeks. The work scheduled in each sprint is based on priority and team capacity, and is carefully estimated to ensure teams can commit the work they've delegated to the sprint. This framework is very detailed, and prescribes a set of specific roles and events, including:

• A Scrum Master, who protects the teams and ensures they are able to do their work without impediments.
• A Product Owner, who manages and grooms the product backlog ensuring the anticipated work aligns with the needs of the customer and business.
• The development team who actually complete the work in the sprint.

As I mentioned above, Scrum is a way teams can work if they're on their Agile journey, but it is not the only option. There are other Agile frameworks that may work better for teams.

How Do Agile and Scrum Differ?

Now that we know a bit more about Agile and Scrum separately, it's easier to lay out the differences between the two. Agile is more of a general philosophy that paints a broader picture around working in an iterative, flexible manner. Scrum is a specific Agile framework and is more granular than Agile. Although both rely on iterations: in Scrum they're specifically time boxed and called Sprints. Scrum also prescribes specific roles and ceremonies, while Agile focuses on the overall principles in the Agile Manifesto. Scrum is also more focused on the team level and the delivery of work. Agile can be scaled across an organization using other work frameworks such as the the Scaled Agile framework, or SAFe, as well as Large-Scale Scrum, styled as LeSS. 

With that understanding in mind, maybe you're ready to start your Agile journey! The Atlassian tools, such as Jira and Confluence, are built to support Agile and the specific frameworks. Jira Software makes it easy to get started with Scrum by providing an out-of-the-box Project template. At Praecipio Consulting, we focus on ensuring the Atlassian tools facilitate your Agile journey by implementing best practices and incorporating our extensive experience working with Agile teams. Reach out if you have any questions around Atlassian and Agile - we're here to help.

The change to remote work has forced Information Technology (IT) teams to quickly and efficiently serve their customers. Due to this, many people talk about using ITSM processes or ITIL strategies to help their teams.

ITSM vs. ITIL

When looking at ITSM and ITIL, it gets confusing. Are they the same? Or completely different? What does an IT team implementing these practices look like? To answer these questions, we first have to understand the differences between ITSM vs. ITIL.

What is ITSM?

Atlassian defines Information Technology Service Management (ITSM) as a way IT teams manage the end-to-end delivery of IT services to customers. This includes a defined set of processes to design, create, deliver, and support IT services. 

I think of ITSM simply as a set of tools you can use to improve your IT team. Just like you would use a handsaw to cut a piece of wood or a screwdriver and a screw to connect two pieces of wood together, you have to think about what you would like to accomplish with your IT team and which tool would be best for the job. 

ITSM processes focus on your customer's needs and services rather than the IT systems behind the scenes. These processes, when implemented properly, can help cross-department collaboration, increase control and governance, deliver and maximize asset efficiency, provide better and quicker customer support, and reduce costs across the organization. Just look at how this global leader in electronic payments saved $4 million by implementing ITSM best practices.  

What are some of these magical processes? Glad you asked! 

1. Service Request Management
   Any incoming inquiries asking for access to applications, software licenses, password resets, or new hardware is classified as Service Requests. These requests are often recurring and can be made into simple, duplicable procedures. These repeatable procedures will help IT teams provide quick service for the recurring requests. Applying well-designed practices to your Jira Service Management application can streamline the process for an organization's customer to create Service Requests and for internal IT teams to act on the Service Requests.

2. Knowledge Management
   The process of making, sharing, utilizing, and managing data of an organization to attain its business objectives can all be a part of Knowledge Management. Creating a Knowledge Base (KB) for IT teams to create content is crucial for teams to learn from the past and maximize productivity. Having a collaborative workspace, such as Confluence, for all teams to work within can help create one source of truth of information. KB articles can also be shared with your customers through the Jira Service Management portal to help resolve common or simple Service Request without having to contact the IT Team.

3. IT Asset Management (ITAM)
   IT Asset Management (also known as ITAM) can help ensure valuable company resources are accounted for, deployed, maintained, upgraded, or properly disposed of. Because assets have a relatively short life-cycle, it is important to make the best use of all assets. Integrating tools such as Insight with your Jira instance can help track all valuable assets throughout your organization conveniently within Jira issues in real-time.

4. Incident Management
   Any process that is responding to an unplanned event or downtime will fall under the Incident Management bucket. The only goal of Incident Management is to make sure that problematic services are brought back to their original operational status in the shortest time possible. For any incident to be quickly resolved, the original reporter has to be able to quickly communicate with the proper IT team asking for help and the IT team must be able to easily communicate back with the reporter to gather any relevant information needed to solve the problem. Jira Service Management can help make this crucial communication effortless.

5. Problem Management
   Taking lessons learned from an incident and determining the root cause of the problem so that future incidents can be prevented or, at minimum, limiting downtime is the basis of Problem Management. Once a root cause analysis is performed on an incident and documented within your Confluence instance, the impact of future incidents can be reduced.

6. Change Management
   Change Management can be used to control and understand the impact of changes being made to all IT Infrastructure. The Change Advisory Board (CAB), a group of individuals tasked with evaluating, scheduling, and validating a change, can be leveraged to better maintain and ensure the stability of your IT Infrastructure. By taking advantage of Jira, employees can easily suggest changes and the CAB will be able to review the proposed changes, approving and scheduling the change as they see fit.

To see these processes in action, let's consider a tangible example that will help bring it all together:

"Austin Snow" is a new employee at your company. As part of the onboarding process, they will need a brand new laptop. As their manager, you submit a Service Request to your IT team through the Jira Service Management Help Center. An agent in your accounting department is then assigned to this task. Using information from a KB article that has been built out in a Confluence page, the agent can see that they are supposed to put in a purchase order for the new device. From the Confluence page, the agent also knows to add this new asset in Insight and assign ownership to Austin.

Once the laptop is delivered and Austin tries to access an application and finds that they get a 404 error message. Austin reaches out to the IT team through the Help Center to create an incident with them. The IT team then proceeds to investigate this issue. They can find the root cause of the problem and fix it. Using the lessons learned from this incident, the IT team performs a root cause analysis (RCA) for the problem. As a result of the RCA, it is found that a change to the organizations' infrastructure can help prevent this problem in the future. The IT proposed the change to the Change Advisory Board (CAB) who then investigates the impact of this change, weighs pros and cons and schedules an outage window to perform this change. 

As can be seen in this example, ITSM processes can help quickly fulfill requests, transfer knowledge, keep track of assets, respond to problems, identify the cause of a problem, and implement any changes needed to prevent problems in the future. 

What is ITIL?

Information Technology Infrastructure Library (ITIL) is a set of best practices designed to support a company's IT operations. ITIL was introduced in the late 20th century as a series of books by a government agency in Great Britain in an attempt to help the British Government provide a better quality of IT service at a lower cost. ITIL v2 condensed all of the content in the early 2000s into nine publications. These two older versions are seldom used; most organizations currently implement ITIL v3 or ITIL 4.

ITIL 4

Most recently, ITIL 4 took into consideration the latest trends in technologies and service management to help organizations as they undergo digital transformation. ITIL 4 consists of two main components; the four dimensions model and the service value system (SVS).

The four dimensions model lays out four key areas to consider to ensure a holistic approach to service management. These four dimensions are Organizations and People, Information and Technology, Partners and Suppliers, and Value Streams and Processes. The four dimensions have to work together to help ensure that any Product or Service provided to the customer is able to provide value in an effective and efficient manner.

For example, in the above Austin Snow use case, the Organizations & People would be the HR Team performing the onboarding, the IT team helping deliver the laptop, the Support team handling the outage, and Austin Snow themself. The Information & Technology would be all the tools, Jira Service Management, Insight, etc. that were used to help Austin. The Partners & Suppliers would consist of the internal IT team in charge of the service request and incident management or any other external team that was leveraged to deliver the request or fix the incident. Finally, the Value Streams & Processes would consist of any well-defined procedures that were used to help deliver the service to Austin.

Source: AXELOS, “ITIL Foundation: ITIL 4 Edition” (2019)

The service value system lays out how all the components of an organization have to work together to provide maximum value. To accomplish this, 5 main elements are used to produce Value from an Opportunity or Demand; Guiding Principles, Governance, Service Value Chain, Practices, Continual Improvement. 

Guiding Principles help define how an organization will respond in all circumstances. These principles should be considered when making any decisions. Governance defines how an organization is directed and controlled and always stems from Guiding Principles. The Service Value Chain is a set of inter-united processes used to deliver a product or service to a customer. Practices are resources to help perform work. Continual Improvement is how the process can be improved to help provide the most amount of Value to an organization. When all of the elements of the SVS are implemented and used properly, an organization will be able to capitalize on every Opportunity. The four dimensions must be considered with all elements of the SVS to ensure a great quality of service is provided to your customers. 

How are ITSM and ITIL Different?

Now that we have laid down a foundation for ITSM and ITIL concepts, let's discuss ITSM vs. ITIL.

These two concepts are not opposing ideas. ITIL is a framework of ITSM, meaning ITIL takes the concepts and values of ITSM and lays out a set of defined best practices that organizations can easily apply to their business to help improve IT services. In other words, ITSM processes describe the "what" while ITIL best practices describe the "how". 

ITIL is not the only ITSM framework; frameworks or processes such as DevOps, Kaizen, Lean, and Six Sigma are also implemented by organizations. ITIL is the most popular ITSM framework to help improve IT service delivery.

Modernizing Your Business Operations

To summarize comparing ITSM vs. ITIL, ITSM is a defined set of processes to design, create, deliver, and support IT services. ITIL, a framework of ITSM best practices, can be used as a set of guidelines to quickly adopt ITSM principles into your organization. 

Praecipio can help modernize your operations by extending service management capabilities to all teams in the organization.  We’ve seen it all when it comes to poorly managed ESM, and our team of experts brings together your people, processes and technology to meet your business needs. 

If you have more questions on ITSM vs. ITIL, contact us to learn how your organization can benefit from these powerful methodologies.

2020 – What a change!

By now, every technology leader has torn up their plans and strategies as they began a ten-month tactical, fire-fighting effort to move their organization to virtual. In some cases, they were able to assist with changing how people performed their jobs, not just their staff but everyone, in which case they now joined the Digital Age.

CIOs further realized that moving to digital required a move to the cloud, and with it completely new ways of working that took advantage of the internet capabilities and bandwidth. Transferring your data center to a cloud service provider is no more going to cloud than moving your teams to Zoom makes you digital. Cloud requires a different mindset, skillset, and culture on how technology will enable your organization.

2021 is the year CIOs can own the Digital watercooler and change their role to being a Business Technology Officer, integrating software into every aspect of how their company performs tasks and services customers. But first, CIOs must address new ways of hiring, financing, and benefitting from technology, their people, their processes, and their IT. Accelerating the path to digital and cloud is the only way to remain sustainable, competitive, and compliant going forward.

The path has two main steps: funding and the creation of a new operating model

1. The innovation funding model – iterative investments using VOI as the guide to obtain technology value sustainably

Before you decide on your cloud service provider (CSP) partner and how to migrate your applications, you will need to determine how you fund the migration to enable your organization to do work better, sooner, and safer. You need to separate the process of budgeting – a plan on what resources will be required – and funding, which is the action of providing those resources.

Current budgeting practices limit moving to the cloud and digital by:

• Asking individuals to annually decide what they will need – and how would you know in this VUCA world?
• Constricting work to be feature-focused but with no indication of what it will add to customer satisfaction or help staff perform better
• Adding to technical and cultural debt with no strategy as to paying it off

The central dilemma of every executive board is how to plan, fund, and prioritize technology activities. The current best practice is not to use cost savings as a goal and instead let that be an outcome as you do things differently aided by software. You can prioritize by:

• Application review
• Moving from a Project mindset to a Product culture
• Cost of Delay
• Creating platforms for products
• Decide on the WHY of moving to the cloud and digital, on HOW it will help, and WHAT tasks will accomplish your goals
  • Faster time to market
  • Reduction of manual activities
  • Making work more compliant
  • Creating workflows that provide agility and flexibility to meet customer demand, staff requirements, competitive threats, and external issues such as Brexit or COVID19
• Get your entire workforce and significant suppliers to be part of the planning and allow them to focus and contribute to the proposed strategy

Shift-left! Think as your customer or staff and deeply analyze your applications, products, and services. Which ones are unique to you, and which ones could you source from a SaaS provider? Which ones do you no longer need? Now group the applications into product groups and allow your IT teams to create platforms (see next section) to service these groupings from the cloud.

Many organizations follow McKinsey's advice to create a FinOPS team of cross-functional product business leaders or at least a team comprised of IT, Finance, Risk, and HR. FinOPS will frequently negotiate with stakeholders to allocate resources (money, people, etc.) to continue the innovation or improve services. They will base their decisions on the value of investment towards the company. Frequently repeating and communicating this interaction creates the ability to pivot or stop work quickly, creating new behaviors, and embedding new disciplines on technology use.

FinOPS will rely on analytics, reporting dashboards with real-time data, and automated processes to make decisions visible and linked to business activities. Leaders will have to coach a new culture of moving from CAPEX funding to OPEX. This team will also introduce training to upskill the entire organization on how technology is applied and that by making use of cloud and digital, they will not lose their roles.

Where needed, a partner such as Atlassian and Praecipio Consulting can help you begin this journey of becoming a sustainable business, maximizing resources while reducing costs and making the entire process transparent.

 2. You have the funding model, and now you need the digital cloud operating attitudes, behaviors, and culture to achieve scalability, agility, and continuity

Can you answer these questions?

• Which business workloads are most important to your company?
• What are your goals by business line for the next quarter and year?
• What are your obstacles to these goals?
• What are your strengths for achieving these goals?

Taking the answers to these questions, review what activities you have planned in your IT department. If a user story or request is not helping solve a problem or achieve a goal, stop it. The FinOps should ask these questions monthly, which will influence resource allocation decisions for technology tasks. Visualizing findings to the company will illustrate the importance of product stories while embedding the capability of pivoting or stopping work, as necessary.

Your operating model will require:

• A compensation model mapped to the technical activities that are not divisive
• A full review of your applications mapped to the business lines
• A map of the way data flows throughout your organization
  • What it entails
  • How it is used
  • Storage, archival, and continuity requirements
  • Security and access obligations
  • Tools that maintain the applications
  • A full list of proposed enhancements
  • Server, network, storage, and operating system supporting them
  • If provided to a specific location, why and how

Using this list, technology leadership needs to help the company move from a project model to a product model. Services must be led by an owner fully accountable for the resources and associated workload, including packaging software into chunks (platforms) that can be used interchangeably throughout the company.

FinOPS and the Product Owners can collaborate on which business domains would benefit most from enhancing the applications used to provide their services. Management can utilize the model to ensure that the right CSP is chosen for each platform. As you mature, you can empower your development teams to decide the best CSP for designing and deploying platforms, be they SaaS or containers. At the beginning of your journey, the strategy should be to communicate the intent and collaborate on the outcomes.

FinOPS also needs to be cloud-savvy. The pricing and SLA options are numerous and complicated. You need to ensure that what you choose is the right decision. You also need to affirm the best path for migrating your application and data to the CSP. Should you port it as it is (provides little benefit), rewrite the application, switch the workload to a SaaS provider? Remember that the avoidance of technical debt, adding to cloud migration's complexity, must be avoided.

There is no shortcut or other option to having Product Owners. You cannot interject a translator or business analyst between what people call the business and your IT. You are all part of the same company, and technology needs to be owned by the business area that provides that service. Further, the people that support these services need to feel that they also own and contribute to these services. This change in attitude and behavior will reduce incidents, increase innovation agility, and enhance your employees' satisfaction, who will feel empowered to see their contribution to the business goals.

The cloud offers the capability of completely altering the way you use technology. Do you need a new instance or environment? Build it, use it, dismantle it, and all within a few minutes at a minimum cost. The software lifecycle of products will be a combination of IaaS, PaaS, and SaaS, depending on the services' platform. Data lakes can share information across the company powered by analytic and reporting tools that would not be accessible to you unless you are quite large.

Security and continuity are other strengths of the cloud as you adopt the framework used by your CSP. Using IAM and Zero-trust security concepts will ensure that you do not become front-page news. Product Owners will have to maintain the governance model required and test it as part of any software change using DevSecOps practices. Scalability, both up and down, is another cloud and digital feature, enabling you to offer new products that can sense and respond to demand.

Are you worried about regulations? Globally FinOPS and Product Owners are finding that regulatory bodies, such as the Bank of England, are moving to the cloud themselves and more than willing to help ensure that their mandates are provisioned accordingly by your CSP. Even if you use a hybrid approach of more than one CSP, which leadership needs to consider, the governance and management models exist via SIAM® to support cloud and digital operating models' best strategies.

The business product operating model is not to become vendor dependent but instead use microservices and containers so that you can migrate your applications as needed to another CSP or a different offering with little effort. This abstraction mode offers the best efficiency in technology enablement. The FinOPS and Product Owners will help to create the loose guardrails to be used by your staff and IT teams as they develop software provisioned products and workloads of your business

In summary

Done correctly, the number of technology instances and applications you currently maintain will decrease but not the requirement of technical skills. Your business flexibility behaviors should be to create agility via innovative use of software, cloud, and digital. Done correctly, the time to market and lower technology costs will be your outcomes. Let all of your organization be involved in the migration strategy as you join the Digital Age, and if you need help, Praecipio Consulting is here for you.

Michael Porter, a former Harvard professor, is one of the founding fathers of business strategy. He lent credence to the field by developing several ideas, frameworks, and theories around strategy that have been utilized, debated, and taught for four decades now. You may be familiar with his 5 Forces model, which is used to analyze the competitive landscape of a given industry, or his course titled “Competition and Strategy”, a requirement for all first-year Harvard MBAs. Though his ideas and theories are certainly not perfect and have evolved over the years, they laid the groundwork for modern businesses to think about their strategy, their position in the market, and their ability to move forward.

And when you think about it, it’s weird that some consider Enterprise Service Management to be a new business process management trend. Let me explain. 

In 1985, Porter co-authored an article with Victor E. Millar in the Harvard Business Review titled “How Information Gives You Competitive Advantage”. In it, he laid out a central argument that said with the explosion of computer usage, companies would have access to a ton of information, flowing freely through the organization, that would allow managers to make more informed decisions faster. This, Porter argued, would fundamentally change how business was done and provide new ways for companies to stay ahead of their competitors. 

Consider this excerpt from Porter’s article:

“The value a company creates is measured by the amount that buyers are willing to pay for a product or service. A business is profitable if the value it creates exceeds the cost of performing the value activities. To gain competitive advantage over its rivals, a company must either perform these activities at a lower cost or perform them in a way that leads to differentiation and a premium price (more value).”

In other words, to gain an advantage over competitors, companies must perform their value activities at a lower cost or in a way that adds more value. Porter foresaw the drastic increase of information that would be available to businesses with the shepherding of the digital era. He logically concluded that such information, if used and communicated correctly, could be advantageous to managers looking to make decisions around the value-added activities in which their business engages.

The prediction of a sharp increase in the amount of information has certainly come true. In the era of big data, companies gather, store, process, and use more data than ever before. The problem is that typically this information is siloed, only about one particular subject, or only accessible and understandable to a few highly-skilled workers. This is the problem that enterprise service management will solve to bring Porter’s 35-year-old vision to fruition once and for all.

Enterprise Service Management (ESM) holds that the (mostly digital) processes that have been championed and used to gain efficiencies by IT teams for so long apply to the business as a whole, as seen by the adoption of similar processes and technologies in departments like HR, Facilities, and Procurement. ESM suggests that an organization should have a tool, which typically takes the form of a piece of software, that allows information to flow easily, quickly, and freely through the organization (sound familiar?). At Praecipio Consulting we have grown fond of referring to this as an operating system for business - one central piece of software that is used nearly ubiquitously in the organization, one that allows work to flow from division to division, team to team, teammate to teammate, with no loss of information and an attached, rich history.

Consider the typical lifecycle of the development of a new offering by a business - whether that be a software feature, physical product, or a new service offering. Marketing will research the market and determine where gains can be made. They will pass intel along to Product, which will develop these insights into a new product idea. The Product team will work with Development to create requirements, Dev will build it, QA will test it, and then it will be released to the market. Along the way, Marketing will generate buzz, Sales will sell, Legal will validate legality, HR will manage employees working on the offering, so on and so forth. In short - it takes a village, a coordinated effort among teams from different parts of the organization to deliver the new offering to market. 

The logic of a single system which transmits work in this lifecycle with no loss of info and rich history is apparent, as is the cost savings garnered from a single license paid to a single vendor, maintenance and training for one system instead of several, and usage of an efficient process unmarred by clunky handoffs to other systems.

To achieve this business process nirvana, we have long advocated for the usage of Atlassian’s Jira, Jira Service Management, and Confluence products. Similar to Apple, Atlassian set out to develop products that work together seamlessly, but unlike Apple, Atlassian has retained that characteristic and further developed it to the point that these three products work together in harmony. The malleable and flexible nature of these products has helped them evolve from those used exclusively by software development teams for bug tracking to those used by IT, HR, Legal, Marketing, Customer Service, and several other business units. The ability of these products to merge these disparate units within a business shows an exciting step forward and potentially a culmination in Porter’s vision of a connected and integrated business.

In the next articles that will form part of this ESM blog series, we will further explore the logic and numbers behind enterprise service management, and why and how it can help your company.