What is Bimodal IT and How Does it Work?

December 9, 2021 - 7 min read

Kelechi Udoagwu

As technology accelerates work, businesses must make IT transformations to stay ahead. Traditional development processes no longer cut it — IT teams must adopt dynamic ways to maintain current infrastructures while improving their workflows and systems to address changing market demands.

A bimodal IT strategy helps to address this without chaos. Bimodal IT is a concept that was first introduced by leading global IT research firm Gartner in 2014. It is the practice of managing two distinct work modes concurrently – one mode focused on predictability and the other on exploration.

So, what is bimodal IT? This article explains all you need to know about bimodal IT, providing real-world bimodal examples and highlighting the benefits for your organization. You'll also learn how to use Wrike to set up and implement bimodal IT strategies easily.

What does bimodal mean?

Dictionary.com defines ‘bimodal’ as having or providing two modes, methods, or systems. This can be seen in IT and product teams, where members work in two distinct modes. It can also be used in traditional organizations, for example, a transportation company using two forms of carriers, such as air and rail.

In bimodal IT, mode 1 focuses on predictability and work that maintains the status quo, while mode 2 focuses on exploration, innovation, and continuous improvement of the organization's systems.

In the short term, these two modes focus on practices that yield different results. However, in the long term, they share a common goal, which is to ensure the organization uses all available resources to provide the best value to customers.

It is crucial to understand that there should be no conflict between mode 1 vs. mode 2. Both are vital to IT transformation in any organization.

Bimodal IT examples

Every industry can benefit from implementing a bimodal IT strategy. A relevant example is the financial services and banking space. What would bimodal examples look like in a traditional bank? How would their projects and processes differ when approached from the perspective of mode 1 vs. mode 2?

In mode 1, the bank's activities revolve around keeping the lights on. This includes projects and activities that support stability and high performance, such as uploading and securing internal work applications, ensuring fast and reliable internet connections, and training staff to maximize their technical abilities within their teams.

In mode 2, projects are focused on finding innovative ways to satisfy customer expectations and needs. An excellent example would be implementing biometric security to enhance customer account security or designing intelligent chatbots to reduce wait times on customer service calls.

Understanding the bimodal IT modes

To clarify how to categorize tasks in your bimodal IT strategy, here are precise definitions of mode 1 vs. mode 2.

Mode 1

In a bimodal IT strategy, projects and tasks must fall into well-defined and predictable areas to be categorized as mode 1. Therefore, any software development project where team members are familiar with the process and have clarity of project requirements can be considered mode 1. The project result is predictable and even expected by involved stakeholders.

Mode 2

Projects focused on eliminating inefficiencies or delivering new products by exploring uncharted areas are categorized as mode 2. Usually, IT teams test a hypothesis on a small scale before going all-in on mode 2. Implementing this IT mode in small iterations prevents huge losses, risks, and large-scale issues from occurring.

Mode 2 is often conducted using the Agile project management framework. Agile allows for quick requirement changes throughout the development process, giving teams fluidity to respond to changes in customer preferences and market demand.

Mode 1 vs. mode 2

The two bimodal IT modes differ in four main ways:

Approach: Mode 1 implements traditional IT service management (ITSM) frameworks to deliver a project. Mode 2 follows a more Agile and iterative process.
Governance: Mode 1 projects require governance and clear, pre-approved plans. Mode 2 projects are more experimentative and unpredictable.
Goals: Mode 1 focuses on maintaining the reliability of current systems and software. Mode 2 looks to the future to implement improvements in the efficiency and speed of the current systems.
Value: Mode 1 commences a new project based on the predictable, expected value achieved upon completion, while mode 2 focuses on improving performance for improved customer experience and brand reputation.

What is Bimodal IT and How Does it Work? 2 — Photo by Marvin Meyer on Unsplash

Benefits of bimodal IT

There are several benefits to implementing a bimodal IT strategy. Some are:

Innovation

The limitations of a legacy system do not hold back the IT and product teams. Time and resources are managed more productively by focusing equally on maintaining efficiency and acquiring innovations.

Speed

Separating projects and goals for different teams helps deliver complementary solutions faster. This prevents the need for one project to be put on hold while developers work on another.

Flexibility

More established industries are disrupted by startups using advanced technologies from the beginning. Having an Agile team to keep up with changes in the industry gives an organization flexibility to meet market demand.

Zero or minimum downtime

Taking several days to fix an issue is no longer acceptable. Having a dedicated team to ensure business-as-usual tasks are attended to eliminates the need to postpone innovative work to address current problems.

Reduction of shadow IT

Shadow IT refers to when teams and clients use third-party applications to solve problems due to the incapability of a current system. Having a team focused on innovating addresses both internal and external IT needs in the best way.

Drawbacks of bimodal IT

Like every business concept, a bimodal IT strategy may have some drawbacks when a company adopts it as part of its IT transformation plan. Some of these are:

Us vs. them mentality: The separation caused by creating teams with different goals can cause an unintentional divide. One team may feel their objective deserves precedence, while the other may feel they do not receive enough resources.
Misuse of resources: Some businesses with great IT transformation goals may not have the know-how to innovate or build infrastructure that supports their goals, leading to a misuse of time, money, and talent on mode 2 projects.
Misaligned stakeholders: As great as innovating sounds, some employees and stakeholders may refuse to change from the status quo or reallocate resources to new projects.
Unclear requirements: It is difficult to know when a project is 'done' when exploring new solutions and technologies. This can lead to significant issues such as scope creep. If project requirements are not defined, time and resources can easily be wasted without tangible results to show.

How to plan a bimodal IT strategy with Wrike

A bimodal IT strategy can lead to losses and expose your business to risks without proper management and execution. Changing or redirecting the IT infrastructure of an organization is no small task. You need the right tools to facilitate change effectively.

Wrike provides powerful project management software, complete with the tools and templates you need to ensure your bimodal IT strategy and implementation come together. Managers, teams, and other key stakeholders can see all aspects of ongoing projects, draw progress reports, and estimate how much resources can be allocated to achieve the organization's overall goals.

Wrike enables both mode 1 and mode 2 projects to be run efficiently and without conflict. It equips IT managers with all they need to carry out day-to-day activities such as service requests, incidents, and change requests. It also has advanced capabilities to empower and facilitate Agile mode 2 teams in iterating and making progress with their projects.

Is your organization in need of an IT transformation while still dealing with current daily requests? Get started with a two-week free trial of Wrike to synchronize your bimodal IT goals and strategy.

Kelechi Udoagwu

Kelechi is a freelance writer and founder of Week of Saturdays, a platform for digital freelancers and remote workers living in Africa.

#IT #Tools & Software Advice

Project Management 10 min read

How to Create the Ultimate Risk Response Plan

What is a risk response strategy and how do you create one for your project? Learn to create a risk response plan with the 4 risk response categories.

Project Management 10 min read

The Definitive Guide to Aggregate Planning

Aggregate planning is the process of balancing capacity with customer demand. Learn more about the best aggregate planning strategies with Wrike.

Project Management 10 min read

Everything You Need to Know About Rough Order of Magnitude (ROM) Estimates

A rough order of magnitude estimate, also known as ROM, is an estimation of a project’s level of effort and cost to complete. ROM estimates take place early in a project life cycle and guide strategy and planning choices. In this article, you’ll learn more about ROM estimates and how they are used in project management. Plus, keep reading to discover examples and how Wrike could be used to assist in creating a template for your own rough order of magnitude. What is the rough order of magnitude? A rough order of magnitude estimate is a general estimate of a project's level of effort and cost. It's usually performed during the selection and approval stage of a project. Generally, it’s used for estimating a project budget that doesn’t have a lot of detail. Project estimating is a vital aspect of project management because it helps determine the total budget for the project and whether or not it’s feasible companywide. It also helps keep track of the project's milestones and budget at the very beginning (more on that later). A rough order of magnitude is most commonly used for project screening. ROM is typically meant to be given to executives who need a high-level overview of how much work might cost. This is especially helpful when they don’t yet have the mandate to do a deep dive into the scope and requirements of the work. Comparing the ROMs of different projects helps identify which projects should be prioritized and which ones should be shelved. It can also help uncover and prevent scope creep later on. This tool also helps decision-makers at other levels of the organization make informed choices regarding the project's complexity and costs. That information is critical for proper scope planning before project kickoff. It’s important to know that a ROM estimate is often used for information purposes at the beginning of a project and it’s suitable for use for the lifetime of the project. How to make a rough order of magnitude estimate Estimating a ROM is often thought of as an art. They are quick to make, but the trick is learning how to make them well. Those who are more experienced in coming up with these estimates may have their own way of executing this process. Regardless of how well you understand the rough order of magnitude, it is important to consider the various factors involved in developing one. These include: A guesstimate range of what resources the project will require based on the information you have on hand Opinions from experts and/or higher-ups who hold a stake in the project A variance of at least -25% to +75% Keep in mind that, when calculating ROM, the goal is to provide a rough estimate that is largely accurate even if it’s not necessarily convenient for your plans. By this, we mean you may find it tempting to choose figures on the more conservative side in order to achieve a more desirable outcome. Unfortunately, using inaccurate stats defeats the entire point of creating the estimation in the first place. Great research can help illuminate areas of your rough order of magnitude estimate where it may be tempting to let bias enter into the equation. All that being said, a ROM estimate's variance is not significant enough to deter you from creating one. A ROM estimate provides a starting point for moving forward in much the same way a budget estimate is also used to determine your base. For example, instead of just presenting single-point estimates, managers should present budgets as a range. Remember: the estimate is derived from the available information. If information is missing, you’ll have to make do with what you do know for sure and move forward from there. In fact, you can expect to improve the estimate as the project moves forward. During the planning and implementation phases, the requirements and information will be refined. As you go along, you’ll learn through trial and error what the reality of the project actually is. Rough order of magnitude techniques One technique for creating a rough order of magnitude estimate is known as a definitive estimate. A definitive estimate is a technique that involves estimating an individual project phase or task's level of effort. Planning with this information upfront makes it easier to plot out workloads on visual charts while keeping your team on the same page. This step typically takes a number of hours to complete, but it is a successful way to get an accurate idea of the time and cost of any project. Other popular techniques and procedures for estimating costs include PERT time estimation, COCOMO, and function point analysis. Program Evaluation Review Technique (PERT) PERT charts are used to plan out tasks that will take a certain amount of time to complete. They can also be used to coordinate team members. Constructive Cost Model (COCOMO)COCOMO is a regression model that can be used for estimating the various factors involved in tech and software project management. It is typically used for estimating the size, effort, cost, and quality of a project. Function Point Analysis (FPA)Function Point Analysis is a method of estimating a company's clear business significance. It helps in the evaluation, management, and control of software development. When estimating ROM, it is best to try and estimate in buckets of time and costs. Doing so helps minimize the number of, well, numbers that are required to provide a complete and accurate estimate. Rough order of magnitude examples There are two ways to think about estimating ROM. You can create effort ranges or buckets with approximate figures that any task can fit into. Alternatively, you can use historical data to guide decision-making. Here are some hypothetical rough order of magnitude examples: Creating buckets In this example, a project manager will define effort ranges such as small, medium, and large. Within each range is a total number of hours, personnel, and/or budget needed for tasks that fall in that category. For example, a small bucket may indicate that a task will take two to four hours and is relatively simple or affordable to complete. It all depends on the specific project. Here is a very simple example. Let's say you're considering eating a sandwich for lunch. You know that tasks such as spreading peanut butter and jelly onto two slices of bread would fall into the small category — low effort, low time, and perhaps even a single knife instead of two. However, if you noticed that you're currently out of bread and you know it would take 20 minutes to drive to the store, that task would fall into the medium category because it would take considerably more resources to complete when compared to the spreading task. Historical data Historical data means pulling information from past projects. These projects may have similar tasks, goals, or outlines. This information is good to have on hand in your project management solution. You can use data from projects that didn't go as well as you'd hoped in order to refrain from repeating his mistakes. You can also use data from projects that went above expectations to see where you can replicate those choices here. Let’s continue with our sandwich example. You may have found that in the past when you were craving peanut butter and jelly, it was worth it to you to make the drive. In fact, it also allowed you to run several other errands (a.k.a. projects) at the grocery store. Based on this historical data, you may find that, despite the effort involved, the payoff was worth it in the end. So choosing this path again will be profitable. First-hand experience First-hand experience refers to how experienced the person creating the rough order of magnitude is in this particular field, project type, or as a project manager in general. An expert who understands project management will likely come up with a more accurate ROM than someone on their first day of work. First-hand experience is valuable because you have plenty of anecdotal evidence to back up your estimations from other related projects. It's also helpful because it allows planners to be intuitive about the process and consider the people involved. For example, you may find that a particular supplier often experiences delays. Although the supplier representative promises otherwise, you've seen it happen time and time again. Knowing this, you can factor that into your rough order of magnitude. Now we’ve come full circle with our peanut butter and jelly project. You may have learned from first-hand experience that, despite your intense craving for it, these sandwiches aren't actually worth it for you. You may even have regretted eating them right after you finished and wished you’d opted for a turkey sandwich instead. Knowing this, you may draft an estimate that confirms the amount of resources and effort needed will not have the ROI expected and it would be better to not move forward with it after all. This information isn’t something you can necessarily track with a report. It’s simply a memory of what you’ve experienced in the past. Using this knowledge will help you make better, more informed decisions in your ROM with information you can’t find elsewhere. How to use ROM in project management Project estimation techniques help managers identify the most critical elements of a project and provide them with accurate estimates. These techniques can also be used to plan for resource allocation. It is important that you have an estimate in place before you start a project. Without an estimate, you may not know how long it will take or what resources will be needed. Cost is often one of the most challenging constraints in project management. Having enough money to complete the project is one of the most critical factors in managing it. Creating a ROM will help you understand whether or not it’s financially viable before you even begin. Another key component of a project is time. Having the ability to determine the duration of the work and when specific tasks will take place is very important to project planning. By estimating your project schedule, you can arrange for the people and resources that you need when they are needed. It also allows you to set expectations for the clients. You can create a rough order of magnitude for any project. But there are several project management situations in which it may be necessary to come up with a ballpark idea of what resources will be needed: Larger than normal projects where you will need to provide more detailed information about the project Projects that involve teams across different countries where there may be varying costs and exchange rates Projects that are customized to the client or unique to your team where the product or service is innovative and the scope of the project is being managed through Agile project management methods Even if your project doesn’t fall into one of these categories, a ROM can be used to determine whether or not it’s viable. This is helpful when you’ve got limited resources and more than one project to choose between. Using Wrike to create a rough order of magnitude template Wrike is a project management tool that streamlines the process of organizing, creating, and coordinating a rough order of magnitude. First, start by checking for any historical data from relevant projects you’ve successfully completed. All Wrike users have access to their own detailed project reports. If you have historical data, you can go straight to a more detailed cost figure. It will give you a more accurate and detailed estimate. If you don’t, continue creating your ROM. Then, start breaking the big components of the project down into smaller pieces. Some planners use the top-down approach or the bottom-up approach, both of which can be accomplished with the help of Wrike. A top-down estimating technique breaks down a project into discrete phases and tasks. This method works by estimating the overall time for the project, as well as the phases and work tasks that will be completed within that time frame. If a client tells you that the project has to be done in six months, a top-up approach allows you to estimate how much time you can dedicate to each activity within the project. A bottom-up estimate is a technique that works by estimating multiple tasks and aspects of a project. This step-by-step process combines the various estimates into one final project estimate. In project management, orders of magnitude are typically referred to as broad-brush categorizations of sizes. So use a range when adding in timelines for individual phases and expenses. Tip: don’t forget about project costs spent preparing the ROM and the project management itself. This will take up about 20% of your estimated total time allotted to the project. Next, go above and beyond by using Wrike to calculate risk. Project risk is a set of events that could significantly affect the quality or schedule of a project. It can be triggered by various factors such as unforeseen delays, budget cuts, and legal issues. By estimating the risks involved in a project, you can plan for how those risks will affect the project and develop a risk management strategy later on if you feel that the ROM is convincing enough to adopt the project. Tip: If you’re stuck, talk to your finance department to see if they can help you get a better idea of what things cost. Finally, consider what project planning may look like. Project planning for Agile projects is usually done in phases, with estimates being created initially before the beginning of the sprint. These estimates are then updated during the sprint. Estimation can also happen during a sprint retrospective, where you update the backlog based on the outcomes of the previous sprints. It can also be done during the sprint planning session. The project team is responsible for estimating projects and managing the estimates. They are also involved in the development of the project's documents and databases. Having one central hub for all project estimates makes it easier to organize and communicate your vision and ROM results. As you progress through the project, you should start to produce smaller ranges for accuracy. Over time you will reach a cap for each category that is both realistic and attainable. As the project details become more detailed, the accuracy of the ROM estimates decreases until they are no longer accurate. In conclusion The more data you have about your project, the better it is to draft current project estimates. A project estimation tool can help you build up estimates and track against actuals. It can also help you improve your estimates by recording errors and lessons learned. Discover how Wrike can help you improve your planning and execution with our free trial.

For Teams

Use cases

Apps & Integrations

Explore Wrike

Learn and connect

Become Wrike Pro

What is Bimodal IT and How Does it Work?

What does bimodal mean?

Bimodal IT examples