6 min read

Leadership required when moving to Cloud and Digital

By Christopher Pepe on Apr 6, 2021 2:32:00 PM

Blogpost-display-image_Leadership required when moving to Cloud and Digital

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.

Topics: blog efficiency finance plan saas cloud culture digital-transformation leadership frameworks
7 min read

Root Cause Analysis: Leonard, Howard, and the 5 Whys

By Amanda Babb on Mar 10, 2021 9:50:40 AM

Blogpost-display-image_Root Cause Analysis- Leonard, Howard, and the Five WhysDIY or DIE!

For those of you watching from home, I have been on a home improvement journey for quite some time. Applying an Agile mindset to home improvement (or really anything I do) is one of my passions. Even at my most recent Women in Agile meeting, we discussed applying Agile concepts to daily life and feeding these back into building a great resumé. One of the principles of the Agile Manifesto reads: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We all know this applies to Agile development practices, but it also applies to IT Service Management. Specifically, Incident and Problem Management. For me, it applies to my recent home improvement adventure. 

Strong fences make great neighbors

My neighbor and I spent the better part of a Saturday fixing our mutual fence. You see, I have two dogs: Leonard and Howard.

 IMG_4511IMG_4512Both are rescues. Leonard is eight and was "free to a good home" while Howard is four and was adopted from my county's animal shelter. Both dogs have been with us since their puppyhood and, as any dog owner will say, they are the BEST. DOGS. EVER. Except when they're not. This was not the first time my neighbor and I had to work on the fence. Observe one of the troublemakers in his natural habitat. 

IMG_4507This epic saga started in May of last year. I would diligently fix loose boards, prop items against the fence to "patch" holes, and monitor their outdoor activity while I was awake (awake being the key word here: 3am barking and fence-patching sessions are no fun). I supplied my neighbor with fence planks because, well, they're my dogs. We fixed the section above and let the others lapse until a series of shenanigans prompted my neighbor and I to spend our Saturday replacing three additional sections. My neighbor and I became united in making sure my two didn't escape. While my neighbor "doesn't care" that my dogs are in his yard, my (very good) boys take the opportunity to break out of his fence and wander the neighborhood. Howard usually comes back, but Leonard meanders through the streets, swims in pools or the lake, and generally causes mayhem until I can coax him in my car to come home. 

IMG_4508

Not in my back yard...

Before this latest patch, I was determined to find the root cause. Previous to May of last year, this was not a problem. My puppers would frolic in the backyard and simply bark at other dogs in the neighborhood as they walked by. I made sure they were let out several times per day to make sure they were relieved in addition to daily walks. While I was traveling, they were also well-taken care of and monitored. What changed? 

Root cause analysis is, simply put, problem solving. While it is widely used in sciences and engineering, it is also a key element of IT Service Management Incident and Problem Management. When reacting to an incident, the team must restore functionality as quickly as possible. Upon resolution, root cause analysis helps us understand why. It then prompts us to ask, "Is there an action I can take to prevent this from happening again?" Incident Management leads to Problem management and through root cause analysis, we can move from a reactive organization to a proactive organization. 

Of the many techniques of root cause analysis, my favorite is the "Five Whys". It is the simplest technique: ask why until you've identified the root cause. Not like a petulant child, however. Asking the first why should be easy, then continuing to ask well-curated questions based on the previous answer helps you determine the root cause. I applied this to my situation: 

  • Why do I have to replace parts of the fence? 
    Because the dogs are chewing through the fence.
  • Why are the dogs chewing through the fence?
    Because they can access the backyard whenever they need.
  • Why can the dogs access the backyard whenever they need?
    Because we installed a dog door.

IMG_4509HA! I found it. The root cause. And it didn't even take me all five whys. 

Any root cause analysis technique does not stand alone. There exists a plethora of other techniques. Pareto charts determine that 80 percent of your problems are derived from 20 percent of the causes. An Ishikawa (fishbone) diagram looks at measurement, materials, methods, machines, management, and mother nature. Scatter plots let us look at correlation and causation. Was the dog door the root cause? The existence of a dog door doesn't change the behavior of my boys. Having access to the backyard doesn't make them chew through the fence planks. Did we ask enough questions to actually identify the root cause? Did I also consider a Pareto analysis, an Ishikawa diagram, or a scatter graph to understand why I was constantly chasing my boys through the neighborhood? 

I stopped at three whys: "I have a dog door."

What happens if I keep asking why? 

  • Why did we install a dog door? 
    Because Howard wasn't fully potty trained. 
  • Why wasn't Howard fully potty trained? 
    Because I didn't take the necessary time to train him. 

AHA! My Ishikawa diagram identified "management" as the issue. My Pareto identified the 80 percent as my time to train my puppers. My scatter plot showed the amount of time spent correlated to the amount of dog-induced shenanigans. I would add these to the post, but won't because...reasons. More importantly, I simply kept asking, "Why?" until I identified the root cause. 

Actions speak louder than words

Now that I have a root cause, what is it that I can do to prevent this issue from recurring? When looking at Incident and Problem Management, Atlassian products such Opsgenie and Statuspage can ingest, aggregate, correlate, and trigger the creation of Jira Service Management issues. With Confluence, we can create specific root cause analysis templates to be shared with our customers and stakeholders. However, it's up to our techniques and processes to help us determine the actions we need to take going forward. 

For me and my puppers, it's simple. 

  1. Take at least 30 minutes out of my day for dedicated doggie exercise
  2. Reinforce good behavior while in the yard
  3. Lock the dog door overnight (no more 3AM "let me sing you the song of my people" moments)
  4. Finish replacing the aged planks on the fence

By taking these actions based on my root cause analysis, I should have this solved quickly with redundancies built in. My puppers will be safer and happier, I will have a beautiful new feature of my home, and the three of us will have less stress day-to-day. Using root cause analysis techniques, and Agile mindset, and drawing from IT Problem Management, I can easily solve this problem and any additional ones around my home.

BRB, gotta run and get some more fence planks.

IMG_4510

Topics: blog confluence plan problem statuspage incident-management itsm women-in-technology agile opsgenie jira-service-management health-check
5 min read

Tips for Performing a Successful Root Cause Analysis

By Mary Roper on Mar 5, 2021 10:55:01 AM

Blogpost-display-image_Tips for Performing a Successful Root Cause AnalysisRoot Cause Analysis: The Under-appreciated Hero

When implementing an IT Service Management (ITSM) system, I always look forward to spending time on root cause analysis (RCA). Of course Incident and Problem Management play the central role in ITSM design- it's crucial to give your teams, customers, and systems intuitive ways to communicate when something has gone wrong. However, it is equally important that organizations spend time identifying the key driver of these problems by performing an RCA to prevent them from reoccurring. This is because, at the end of the day, incidents and problems cost your organization money, and a good RCA can help save it. It's this viewpoint that has led me to dub RCA the under-appreciated hero of ITSM and in this post I will share with you the aspects of a successful RCA that can help vanquish problems once and for all. 

It's important to distinguish between Problem Management and Incident Management. In broad strokes: the goal of Problem Management is to get to root cause, and we can understand its goal to be increasing the meantime between failures by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident; in this sense it's a proactive approach. On the other hand, Incident Management's goal is to reduce the meantime to recovery by responding and resolving fast; its approach is reactive.

What is Root Cause Analysis?

The core function of root cause analysis is to uncover the core reason why a problem occurred. While there are many different tools and approaches to perform an RCA, I've consolidated the key steps into the diagram below: 

Root Cause Analysis Blog Post

  • Define the problem: First, make sure you and your teams align on "What happened?" and are speaking to the same problem.
  • Collect Data: Then, the focus needs to be "How did this happen?" and gathering data around the problem, whether customer testimony or incident reports.
  • Identify Casual Factors: Casual factors also help to answer "How did this happen," and in this step, teams should be guided to identifying fixable causes.
  • Identify the Root Cause: Next, teams should leverage one of the techniques of the RCA process, such as the "Five Whys," Fishbone Diagram, or Fault-Tree Analysis, to drive to the root cause of all the causal factors. 
  • Recommend and Test the Solution: After the root cause has been identified, teams should work to develop a solution that gets recommended to the Executive team for approval before testing can begin. Once approved, the solution should enter a testing phase, where it can be rolled back if not successful. 
  • Implement and Monitor: Once the solution is implemented, teams should continue to monitor it in the production environment to ensure that it is working as expected. This active analysis step is why RCA is depicted as a cycle; if the solution did not resolve the problem, it could be that the problem was a casual factor and the team needs to begin the RCA process again. 

Why Does It Matter?

I've worked with teams who have a well-defined RCA process and others who are just beginning. I reference this diagram when we focus on RCA because it helps to illustrate how simple of a process RCA can be. There aren't rigid guidelines or rules to follow; organizations can adopt their own RCA policies. What many don't realize, especially those who have yet to adopt RCA as a business process, is that it has a big pay-off: cost savings.

Root cause analysis can be a cost saving tool for organizations for a couple of reasons. First, identifying and acting on problems early saves money. The longer a problem goes on the more money it costs the organization, and a properly deployed RCA process is built to help organizations become more proactive rather than reactive. Second, the main goal of the RCA process is to prevent incidents from cropping up again. If the incident does not reoccur, then there won't be downtime or lost production, saving money in the long run.  

How Can I Help My Organization Embrace RCA?

When working with organizations to implement an RCA process, there are several aspects that I help coach my clients on which can help the organization embrace RCA. They are:

  1. Talk about what went well.....and what could have gone better
    1. When the team is starting the RCA process, guide them to start by discussing what happened and framing the problem. Then, go one step further and document what went well. This will provide you data and help to explain what is not the issue or what not to blame. It's equally important to talk about what could have gone better, as this will likely begin the discussion and documentation of your causal factors. 
  2. Make it work for you
    1. In some organizations, "Root Cause Analysis" can be viewed as too formal and intimidating. I've come across some resistance to them due to their structure or even the invitee list. For these reasons, it's important to make sure you're adopting a RCA structure that feels natural for your organization. This could mean:
      1. Being mindful of the attendees, especially if the invitees include senior management and above. Ensure you include the right people in the room at the right time. Your front line team has the most firsthand knowledge of the systems or processes, and you will want them to feel comfortable participating candidly in any discovery meetings. 
      2. Having a neutral party leading the meetings. The leader shouldn't have anything to gain by the results of the RCA process and should be able to maintain a "blame free" atmosphere.
      3. Reframing RCA as something more approachable, such as a "Lessons Learned meeting,"  where the RCA process is still followed, but in a less formal way. Feedback and idea can be gathered via sticky notes and shared on a board so that it is anonymous for example. 
  3. Root causes can only solve one problem
    1. Remember that the main goal of RCA is to avoid future incidents. Teams should not be applying a previous root cause to a current or future problem- if that is the case, then it indicates that rather than identifying the root cause, the team actually identified a casual factor. In these instances, I've coached teams to go back and take their RCA process one step deeper, for example asking another "Why" question if the "Five Whys" is used. 

The goal of Problem Management is to get to root cause. Incident Mgmt goal: reduce the meantime to recovery (by responding and resolving fast); reactive
Problem Mgmt goal: increase the meantime between failures (by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident); proactive.

Ultimately, where incidents and problems cost your organizations money, RCA saves it. It is for this reason that I think of RCA as an under-appreciated hero of ITSM. While the biggest barrier to accomplishing RCA can be time, putting in the time upfront to accomplish the RCA process will prevent repeat incidents from cropping up, saving your company time and resources in the long run. By implementing a few of these tips, I hope you come to appreciate RCA as I have, and if you have any questions let us know, we'd love to help. 

Topics: blog plan incident-management itsm health-check
3 min read

Should scrum teams track their time?

By Amanda Babb on Feb 5, 2021 8:03:49 AM

Blogpost-display-image_Should scrum teams track their time-"How many hours are in a Story Point? Pink. Because penguins don't like ice cream." -Amanda Babb in every conversation about hours and story points. 

While I use this example as a cheeky way to say the two methods of estimation (hours and story points) don't coincide, the reality, of course, is much more complex. Business and product teams typically think in terms of dates and schedules. Development and operations teams typically think in terms of level of effort. That's not to say story points and dates do not nor will ever coincide, it's a matter of how to speak each other's language. 

What is a Story Point?

Our Dragon of the West, Christopher Pepe, explained it well in a previous post. Humans are terrible at numbers. That's why we have so many ways to express things without using numbers. For example, I have Big Dog (Leonard) and Tiny Dog (Howard). Tiny is small in comparison to Big Dog. However, at 50 pounds, he's not small compared to, say, a Chihuahua. This is what we call relative estimation in the agile world. This thing is larger or more complex than the other thing over there: it will take a larger level of effort to complete. 

Computers, on the other hand, are wonderful at numbers. It's part of the reason we invented them. In Jira Software, a story point is simply the numerical expression of a relative estimate. When we need to understand the level of effort of more than one thing, we aggregate the relative estimate into a total level of effort. This is known as the commit in a velocity chart. As we complete work, we burn down the level of effort until we understand what's left. At the end of a sprint, we determine whether we met our commit or not. The completion of the work over several sprints determines our velocity. From there, we can reasonably predict the level of effort we can complete during a sprint. 

Why can't a team estimate in hours? 

It's not a matter of can't. At Praecipio Consulting, we've seen many teams succeed well in estimating their level of effort in hours. However, this involved a significant effort to run time studies on routine tasks for the team. In a time study, an outside party will watch a person do a task and time it. Then watch them do it again...and again...and again. Then, the outside party watches another person perform the same task several times. The outside observer will continue with this until they feel they have sufficient data to make a reasonable assumption (read: average) of the time it takes to complete said task. Rinse and repeat for all tasks all personnel complete in a day and through out the week. 

Estimating in hours works well in repetitive work environments. The same tasks must be completed the same (or similarly enough) throughout the day and week. However, when we're thinking about software development, we all know this is rarely the case. What may seem like a simple feature request can become a significant effort when looking at how the new feature interacts with the rest of the services, modules, or products. Yes, we've done something similar before and it took four hours. But what has changed since the last time we implemented something similar? What else have we deployed? Did we change our methods? Are we integrating this with another system? Have the APIs been updated or changed? How many releases have been performed since the last time we did this? 

The shoulds and shouldn'ts of tracking time in Scrum

Why are teams being asked to track time when they estimate and understand level of effort in story points? In a word, Money. Under complex financial and regulatory practices, most businesses report quarterly earnings to regulatory bodies and markets. The best way a business has to gather and report this information is through complex financial systems that aggregate data from inputs across the organization. One of the more critical inputs? Time tracking. So how should we and shouldn't we track time in a scrum team? 

  • You should establish the minimum time guideline such as 15-minute or 30-minute increments
  • You should not expect accuracy down to the minute for a given task
  • You should expect the team(s) to continue to estimate their level of effort in story points
  • You should not make the team switch to hours to estimate their level of effort
  • You should centralize where the team should track time
  • You should not expect the user to log in to multiple tools to track time
  • You should download our Lean Budgets White Paper which details different ways of managing the data and provides a solution in Jira Align
  • You should not expect to implement a fundamental change in financial tracking and reporting across your organization without help

At Praecipio Consulting, we have implemented several solutions to this problem across industries and with all sizes of organizations. For help regarding how your teams can balance time tracking, scrum, and financial reporting, feel free to reach out to us! 

Topics: blog plan process scrum lean-budgets agile
3 min read

Last call for new Server Licenses: What you need to do NOW...

By Brian Nye on Jan 20, 2021 10:49:41 AM

Blogpost-display-image_Last call for new Server Licenses, what you need to do nowAtlassian announced last year that its Server products will be sailing off into the sunset in three years (2024) but the first big date is upon us... February 2, 2021. On this date, the following will happen:

What this means is that you will no longer be able to purchase new licenses for Server-based Atlassian products. You may experience a price increase on your Server-based products, Atlassian has outlined them in their Future Server Pricing FAQ. For new instances of the Atlassian stack on or after Feb 2, 2021, you will need to implement either the cloud or Server versions. If you are currently running Server, you have time, however, you need to start thinking about what your long term plans are for your Atlassian technology stack.

So what do you need to do now?

The answer is simple, start to plan for the future. Most of you will not need to take any immediate action as Server is not "going away" and business will proceed as usual. But over the past seven years, I've seen a lot of Atlassian instances and some of you have some work do because what you've done will make it hard to go to Datacenter or Cloud. "Why will it be difficult?" you may ask...well some instances would be a good candidate for "Hoarders, Atlassian edition". Some of you have not seen an app you didn't like while others want to keep every issue and page ever created. Sprinkle in bad practices and untrained administrators, you've got a mess that needs to be untangled. 

Three years will go by quickly. Many of you work for companies that take a long time to make decisions and then want miracles to happen in the 11th hour. My recommendation is you start planning now to figure out what is the best solution for you. With that being said, you should start by looking at the following areas:

Apps: Not all apps are created equal. Many were built with Server in mind and some do not have an equivalent in Cloud or Datacenter. You should start evaluating what this will mean for your user community if the app goes away or the functionality changes. 

Data: Moving a ton of data is never easy, especially if you're moving from Server to Cloud (which most will). Data comes in the form of issues and pages, as well as configurations. You should be questioning if you need to bring it all over. You should also evaluate if you want to bring over all the crud that's associated with the data (poor configuration setups like custom fields and statuses).

Customizations: Outside of apps, many have customized templates and files to control UI behaviors. These are usually not able to be replicated in Cloud or will break the multi-node Datacenter infrastructure.

Every instance is different from the rest and while those are generally the first places to start on your journey. Plus you must factor in the cost of operation with the security stance of your company. There is a lot to think through and this is why you must not wait until 2024 to start down this journey.

Here are the remaining dates that you should be aware of:

  • Feb 2, 2022: End of Server upgrades and downgrades
  • Feb 2, 2023: End of new App sales for existing Server licenses
  • Feb 2, 2024: End of Server support

Need help or don't have time to think about this? Praecipio Consulting can help guide you through this transition by helping you plan and perform the migration when the time is right for you. Our consultants can evaluate your current set-up and provide a path forward customized to your unique situation. 

Topics: atlassian blog plan server licensing
8 min read

Transitioning to SaaS: Pizzas and Pitfalls

By Christopher Pepe on Dec 29, 2020 1:14:00 PM

Blogpost-display-image_The Gotchas of SaaS blog

What is SaaS (Software as a Service)?

COVID-19 has changed the world in many ways, accelerating the pace in which the digital transformation has upended traditional modes of working and living. Whatever your organization was planning to do in 2020, whatever 5-year plan you had, is no longer valid. No matter what sort of business you are, your dependence on technology has escalated. You have probably built the services in the table below or at least run them on your infrastructure, managed by your IT teams.  COVID-19 has forced you to ask the question: do I still need to run and manage this service internally, or can I save money and time by letting someone else perform this service for me?

Traditionally in-house Managed Services

Human Resources and Payroll

Web-based services

Customer support

Internal communications

Finance reporting, accounting, and invoicing

News and knowledge sharing

Project Management

Enterprise Data and Service management

Security

Sales and Marketing

 

The definition of SaaS by the East Sussex Council highlights what software is achieving today as businesses move towards a digital future: "SaaS is the focus for innovation and investment for major system providers and is specifically designed to meet the needs of an agile and mobile workforce, enhancing self-service business processes and significantly improving the use of management information. (Cabinet Office report for East Sussex council)".

Another view to help the discussion comes from Albert Barron using pizza as a stand in for software, with this fun visual of how the transition to SaaS changes from "You do IT" to "They do IT for you". 

Screen Shot 2020-12-05 at 10.03.18 AM

There are caveats that you need to be aware of such that your experience with a SaaS provide is valuable to your organization and customers: it's vital to go through these with your team before making decisions.  The rest of this article explores these and if you have any questions, please let us know.

1: Security, Risk and Data

Your data is now their responsibility!

  • Who in their organization has access to it?
  • How is it backed up and does that comply with your regulatory bodies?
  • Where is the data stored and does that contravene any local laws?
  • If they have an issue, what is their business continuity plan and how does that align to yours?
  • If they are compromised, what processes will they enable to let you know, but more importantly, protect your customers?
  • Will they agree to participate in your business continuity tests and decide on their role in a business continuity event?
  • Will the transference of data from you to them be exchanged safely and securely?
  • What will it cost to perform the data transfers and tests?
  • What level of access will your staff receive? Even if they assume responsibility for an activity, you are still accountable to require some level of access over time.
  • What defense does the vendor offer against hackers, and is this an extra-tiered service or part of the basic package? If extra, you might want to look elsewhere.
  • What processes need to change within your organization to enter, use, modify, delete, backup or restore information and have you been trained by the vendor appropriately?
  • Your data is now their responsibility. How portable is it if you want to switch?
  • Does the vendor support MFA
  • Do they allow penetration tests?
  • What policies have you introduced to manage your data in the SaaS provider cloud?
  • If the SaaS vendor changes the schema or worse-cancels it, what impact will that have and are you contractually protected?

2: SaaS Vendor Performance

The perception and experience of your staff and customers are now based on the SaaS provider's performance.

  • Did you create a clearly defined view of expectations supported by metrics and examples? Do you know bad from good from great service?
  • How did you explain to your customers and staff that you were now going to use a SaaS provider? What was the reaction?
  • What happens if your customers complain? What happens if your customers leave you because of a SaaS performance?
  • Is it contractually clear under what circumstances a complaint can be made, the timeframe it must be addressed and any penalties that could be applied for non-conformance?
  • Who does the customer or staff call if there is an issue? Your teams or the SaaS provider?
  • What level of support do they provide and how will you test that the service is delivered as expected?
  • What messages do you receive in case of a data entry issue or general performance issue?
  • Do you have regular performance and improvement meetings with the vendor?
  • If you want a new feature based on customer feedback, is the SaaS provider responsive?
  • If the SaaS provider changes their product procedures, what will be the impact on your customers? Can you pilot the changes? If you do not want the new procedures, can you leave the SaaS provider?

3: Vendor lock-in

SaaS vendors bet that once you let them perform an activity, that you will remain a customer for several years. In other words, you are locked-in to their practices, processes, support, improvements and remediation and so are your staff and customers.

  • How does the SaaS vendor recruit, train and keep their staff? You do not want a constantly changing workforce and there are examples where 30% of a SaaS workforce changes every 90 days.
  • You might have saved money by not having to hire or train your staff, but what will you do with the knowledge they possess?
  • Contractually obligating certain staff to remain until the transition is complete is best practice.
  • Your IT is now their IT. If you want to benefit from the latest technology and they do not support that product then you are stuck. Make sure your contract allows for changes or even cancellation if needed.
  • If the vendor changes their price, what protections have you contractually initiated to ensure that you should remain with that vendor? How will you prove value over time?
  • COVID-19 has seen a number of vendors have issues causing them to default on a service or even go out of business. How will you protect yourself in case this happens to your provider? 
  • SaaS vendors price in three main ways: by user license, by use, by feature. Make sure that you have chosen the model most appropriate for your needs and that if your work model changes, then you can move to another tier without penalty.

4: SaaS requires an internet connection and belief the cloud is secure

  • What if something terrible happens to your web servers? Do you have backups of your metadata? You might want to consider using third party backup services such as SpanningBarracuda, and Backupify.
  • If you have communication issues from your office, what is your backup to ensure that the SaaS service remains accessible?
  • If your staff are working from home and they have issues, then how will they continue to work until normal service is restored?
  • Can your staff download data to their home office? If so, this is a security and perhaps even a compliance risk. How will you know?
  • If they invoke contingency, does this place your business in a location where you
  • What is the web page loading time? How complicated is the page to read or use?
  • If data is transferred to other applications to complete the journey, can this be monitored for security and improvement?
  • Is the SaaS service usable across a variety of mobile devices or internet browsers?

5: Integration into your other software

SaaS implies that all of the technology required to perform a service is now under the control and management of the vendor.

  • How easy is it to transfer their data into your systems such as corporate finance?
  • What happens if they make a change to a schema that you were unaware of and this damages your data or causes you lost time to introduce new ways of addressing their change?
  • Everyone performs regular maintenance activities and how will this be coordinated?
  • If you use multiple SaaS vendors (Accounting and Sales for example), how will you keep them in sync with each other and any internal applications you maintain?
  • How do you test that interoperability remains as expected?
  • What is the impact to your business continuity of multiple SaaS providers?
  • If a vendor has an issue, how will that impact other vendors you rely upon?
  • Will you require 3rd party to help you integrate their software with yours? This can be costly.
  • Not every vendor follows standard APIs, protocols, and tools, so the impact to your business practices should be piloted prior to accepting the SaaS provider.

6: You may have to change your business practices to use the SaaS

  • This is a culture change for your staff. How will you prepare them?
  • What training and documentation will you receive and is it sufficient?
  • If something requires customization, is that even possible or practical? Many SaaS vendors will only allow this if a significant number of customers also request that feature.
  • How will you ensure that other business practices can pivot based on competition, compliance or performance needs?
  • How will you ensure that the SaaS provider supports all of the ways your customers want to interact with you? Browsers, mobile technology, VPN, etc.?
  • What and when is their maintenance window? How does that impact your business customers? What happens if a change goes awry?
  • What information do you receive on incidents related to you? Is it in a format that your ITSM tools can read and archive?

SaaS is a brilliant technology capability that can benefit your organization. You must closely manage them if you are to remain in business, service customers safely, and receive the expected cost benefits. Ensuring that you have a way to mitigate this list of caveats will ensure that your experience is as valuable as possible. Letting go of services you have built in-house can be hard, and moving to a SaaS model can be intimidating: have no fear, Praecipio Consulting is here to help. Contact us for any questions you might have of successfully transition to a faster, more efficient way of doing business.

Topics: plan saas digital-transformation
2 min read

Thanks to Portfolio for Jira, Everyone Has a Seat at the Table

By Praecipio Consulting on Nov 21, 2017 11:00:00 AM

Thanksgiving is right around the corner, we can't help but think about our favorite things this time of year. We have opportunities to see family, friends and relatives, enjoy good food, and talk about everything that happened throughout the year. It is great to catch up and visit about what's happened, and what's going to happen. It's a time when families and friends reflect, collaborate, and even begin planning for the next year (because all families get along perfectly, right?).

What if you had a holiday table year-round for your organization?

If a project is delayed, or a change needs to be made, wouldn't it be nice to update the entire plan and everyone on the team at once?

Atlassian's Portfolio for Jira is the solution. 

The core of Jira Software is a workflow engine. It allows you to track issues and tasks in a predefined, customizable workflow. Now, take this awesome workflow capability, and lay a forecasting and visualization tool on top of it - that's Portfolio for Jira. Atlassian’s Portfolio for Jira is the road mapping and visibility tool used to forecast and track long-term plans, increasing visibility and business alignment. Portfolio provides a living, breathing plan for teams and leadership to stay up-to-date on existing plans, all while forecasting new long-term plans.

The best part? It's not just for software teams. 

Portfolio for Jira organized existing marketing tasks (entered as issues) into releases and themes, giving our entire team the visibility we needed to stay on track.

Teams that can benefit from Jira Software: 

  • Human Resources
  • Operations
  • Marketing
  • Procurement
  • Legal
  • Sales
  • And more 

Because we track just about everything we do - including marketing activities - in Jira, the marketing team at Praecipio Consulting was able to use Portfolio for campaign planning and execution. As a test case, we launched a product marketing campaign for our newest add-on in the Atlassian Marketplace, Turbo Kit for Jira. Portfolio for Jira helped our team plan, forecast, manage, analyze, track and report on our campaign efforts. 

Change happens – all the time. Portfolio can help you, your team, and leadership stay well-informed on project and planning statuses, and it can also help you see the big picture and track business goals (not just your team or department!). It is the ultimate visibility tool. 

We'll dig into this a little more in our upcoming webinar Portfolio for Jira: Best Practices. Be sure to grab a seat at our table to learn more!

Learn more about Portfolio for Jira in the Atlassian marketplace.

 

Topics: jira atlassian blog marketing plan release training jira-software marketplace-apps
4 min read

Hey Atlassian Users: Easy Release Management with Bamboo 3.2!

By Praecipio Consulting on Jul 28, 2011 11:00:00 AM

Bamboo 3.2 Now Available

Automate your complete release process down to one-click, add manual Stages to your deployment process, and re-run failed Stages with the newest version of Atlassian’s continuous integration server, Bamboo 3.2.

What’s New in Bamboo 3.2

1. Release Management
The dream scenario with any release process is to automate all of your release activities down to the click of a single button. Bamboo 3.2 and the new Release Management plugin for the Jira bug tracker aims to do just that – one-click release management.

  • Prevent mistakes from being made as part of a long, manual release process
  • Remove the barrier to release
  • Speed up the release – the more often you do it, the faster you will make it
  • Manage all your releases from a centralized and controlled location
  • Use the same streamlined, automated process every time you release

Release in Jira, build in Bamboo! Create a release pipeline in Bamboo to automate your release process: use Stages, Jobs and Tasks to build, run tests, generate release artifacts, publish and deploy your release. Then initiate your release activity or event with one-click directly from Jira when you’re ready.

Run a release build in Bamboo from the Jira Versions tab without leaving Jira. 

When releasing a version in Jira you will have the option to run Bamboo builds.

If the build is successful the version will be released in Jira.

Automate the steps that traditionally are performed to release an application:

  • Building and testing
  • Tag the releases, assign a version
  • Create and populate the release branch
  • Deploy the release to a a deployment server or production environment
  • Release the new version in Jira, move the unresolved issues to the next release
  • Release or activate the new version in Production

Bamboo ships with a number of Tasks to build and deploy including Tasks to tag or branch a repository.

For Jira-Bamboo users the latest release of the Bamboo-Jira plugin is now compatible with Jira 4.3 and provides this release management functionality.

2. Manual Stages
Manual Stages allow you to interrupt/halt/suspend automatic build execution at a specific Stage in the build plan. For Plan execution to continue a user must manually trigger the Stage.

  • The default behavior of any Build Plan in Bamboo is to go to the next Stage upon successful completion of the current stage. Depending on your needs you may need to introduce a manual checkpoint into your build plan before going on to the next Stage:
  • Use a manual stage for deployment to give your QA team a chance to perform a few manual tests before your software goes into production
  • In a release pipeline, you may want to separate your ‘publish’ step from your ‘install’ step and install only after backups or clean shutdowns have been confirmed
  • Introduce a ‘quality’ gate, between build and deploy stages, to allow members of your team to approve and promote a particular build
  • Any other step that’s difficult to automate or that requires special attention

 

 

3. Re-run Failed Stages
It’s not always the code that is broken. Infrastructure problems and other issues can cause a Job, and therefore the Plan, to fail. In these scenarios Bamboo can re-run failed Jobs without having to re-run the entire Plan once you’ve resolved the problems. This can save heaps of time and build resources.

 

4. Filter Bamboo Dashboard by Labels
Bamboo now allows you to label your build Plans. The Bamboo Dashboard can be filtered to only show plans with labels that you are interested in. Filter out the noise on your Bamboo Dashboard.

Hint: When viewing a Plan use the keyboard shortcut “l” to bring up the label dialog for the Plan. When viewing the Bamboo Dashboard press “l” to filter the dashboard by label.

And More…

  • Improved Jira integration – delegate user management to Jira, easier application linking
  • EC2 improvements

This release has over 50 new features and improvements implemented. Check out the full release notes for more details.

Also make sure to check out the new agile testing tool for Jira, Atlassian Bonfire.

Ready to download?

Download Bamboo 3.2 now to get started with a 30-day FREE trial or upgrade your current instance.

Topics: jira atlassian blog automation bamboo confluence dashboard management plan process release software deployment environment integration marketplace-apps
1 min read

Forward Planning in Greenhopper

By Praecipio Consulting on May 6, 2011 11:00:00 AM

Atlassian’s GreenHopper has a ton of features to help you organize and plan projects. But some features are harder to find than others. Christine Bang’s new post series The Three Pillars of GreenHopper highlights out-of-the-way features you can use when planning your projects.

Check out Christine’s first post in the series here, discussing how to view project backlogs, working with statistics, and deciding on new project tasks.

Topics: atlassian blog plan project greenhopper

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us