Hybrid Agile-Waterfall Methodology: What is it?

Hybrid Agile-Waterfall Methodology: What is it?

There has been a takeover of the product development methodology of choice happening over the past 10 or so years.

For those of you who started in product development before that time, then you’re familiar with the waterfall approach where phases in the product development cycle happen one after the other. There is little room for overlap. Kind of like a … waterfall.

When I began my career, I didn’t even know this approach had a name. I just thought it was the way software was developed.

More and more, agile methodology has become the choice for software development teams. Just like the name suggests, this more flexible approach focuses on iterative development. This allows for changing customer needs during the development process. 

A ton of great software that has been developed using waterfall. The approach has benefits that made it useful to begin with. And the flexibility of agile can be a huge benefit.

So, which should you choose?

Well, maybe both. 

Because there is another methodology that uses characteristics in each to balance discipline with flexibility: hybrid agile waterfall methodology.

Keep reading to dig into the benefits and challenges of this hybrid agile waterfall methodology. Plus, when to consider using it.

Firstly, What are Agile and Waterfall?

I must say, whoever named these approaches were spot on. So, a big thanks to them for making this all a bit easier to remember.


In a traditional waterfall approach, the system development lifecycle phases occur in succession. When one ends, the next begins. Waterfall is gated approach from requirements to design, development, testing, and release.

This approach has limited flexibility to accommodate changing requirements. Business analysts gather detailed business and technical requirements at the beginning of the lifecycle. Policy changes that require system considerations are evaluated after the application is released. 

In most cases, this means re-starting the lifecycle and going through it all over again. This delays implementation of any new or updated requirements.

Benefits of Waterfall

  • Strict timelines, budget, and scope provide clarity for the development and executive teams
  • Defined requirements and design set expectations for the final solution to be delivered

Challenges of Waterfall

  • In-ability to accommodate changing customer requirements
  • Strict timelines, scope, and budget allow little room for flexibility


In a traditional agile approach, requirements are defined during each version of the application. This flexible approach allows technical resources to adjust as policies change.

Working products are iteratively delivered and tested by business users. Changing priorities and requirements are gathered during each iteration and incorporated into a future one.

Agile provides a method to develop a solution when the full scope of requirements is unknown. High engagement from end users is necessary to continually iterative and improve. However, executives and business owners may struggle with open-ended timelines and a lack of clarity as to what will be delivered.

Benefits of Agile

  • Ability to accommodate changing customer needs
  • Frequent delivery of software updates
  • Iterative development that incorporates customer feedback

Challenges of Agile

  • Open-ended timelines, scope, and budget
  • Lack of clarity into what the final solution looks like
  • Requires a high engagement with the business team during the entire development lifecycle

What is Hybrid Agile-Waterfall Methodology?

To accommodate needs across business and technical teams, there is another approach: hybrid agile waterfall.

Hybrid agile waterfall utilizes characteristics from each of the methodologies described earlier to balance flexibility with rigor. This hybrid approach establishes a baseline set of expectations, delivers frequent releases, and follows disciplined project management.

All of this enables both the business and technology teams to find a common ground.

The Hybrid Agile Development Lifecycle

Agile is iterative, waterfall is not. So, how is this reconciled in the hybrid agile development lifecycle?

In the hybrid approach, development and independent verification and validation (IV&V) is iterative while the rest of the phases in the lifecycle follow a waterfall approach. Think of it as agile development with a waterfall approach to project and product management.

This iterative approach to development and internal testing provides flexibility to refine requirements during a given sprint.

Speaking of development sprints, this is where the iterative magic happens. Quality is assessed based on the health of a sprint. How accurate were estimates? Were requirement changes incorporated? Was a viable solution delivered compared to what was planned to be delivered?

To complement the flexibility of iterative development, a more strict approach is followed for project planning, requirements gathering, design, user testing, and release deployment. This increases clarity in the project plan and budget.

Benefits of Hybrid Agile-Waterfall

There are several benefits of a hybrid approach versus a more traditional single approach:

  • Creation of higher quality end-user focused systems through iterative design-build-test cycles and increased collaboration between business and technical teams
  • Enables requirements refinement, changing customer needs and design flexibility
  • Balances flexibility with disciplined project management to add clarity to the development lifecycle
  • Mitigates uncertainty by setting a baseline set of expectations
  • Delivers frequent, useful and customer-focused solutions
  • Provides a realistic interim approach that can be used as a stepping stone during an organizational transformation from waterfall to agile 

Downsides and Challenges of Hybrid Agile-Waterfall

Of course, there are challenges to the hybrid approach. But, with the right steps, these can be mitigated:

  • Thrives only with the right staff and the right culture – stakeholders need to be open to change and iterative improvements
  • Requires communication, structure and proper feedback 
  • Business and technical teams need to be comfortable with initial uncertainty
  • The difficulty of balancing between a phase-gated approach and iterative approach without settling into the comfort and familiarity of either

Hybrid Agile Control Points

At the end of the day, a solution that meets customer needs is the goal with any development methodology. To continually assess and maintain quality, control points are established. These control points are used to review and confirm the solution is meeting customer needs, budget, and timeline before moving on to the next phase of the lifecycle or development iteration.

Here are the control points used in the hybrid agile waterfall methodology:


Each iteration works against a granular set of requirements. But, a high-level roadmap is used to manage the overall product. The roadmap outlines the end solution to be delivered while the requirements outline the solutions to be delivered at the end of each iteration.

Maintaining an initial roadmap is not only useful from a communication standpoint, it also ensures that the bigger vision is realized. Each granular requirement is reviewed against the roadmap before inclusion in a development sprint. This ensures that at the end of each iteration, the delivered solution aligns with the overall product vision.

Backlog Management

The requirements backlog is where new system features are tracked and maintained. The backlog is reviewed to ensure that new items are not out-of-scope from what is needed for the system. 

In the heat of development sprints, it is easy to lose track of what is and what is not important. By validating that what is being added to the sprint backlog is meeting the business needs prior to the kick-off of a new sprint, the team can fully focus on development tasks.

Minimum Viable Product/Business Value 

It is easy to add too much into development. It happens all the time.

The goal of each development iteration is to deliver a minimum viable product that adds business value. Maximum value is delivered with minimum development is the winning combo.

This may sound difficult. And it can be. 

But, the role of IV&V during each development cycle is to validate that each user story or requirement adds value. This ensures reduced complexity and minimizes wasted effort.

Sprint Planning and Review

At the completion of a development sprint, it’s time for everyone on the team to put their “Monday Morning Quarterback” hats on.

It’s important to continually assess the health of sprints. Not only is development iterative, but so are improvements. By reviewing sprints, improvements can be made the next time around. 

That’s the beauty of iterative development, you’re often fortunate enough to have another opportunity to nail the delivery of a solution that your customer will love.

During sprint reviews, the project team evaluates question such as:

  • What did we say we are going to do?
  • What did we do? 
  • How well did we meet our goals for the sprint?
  • How well were our estimates?
  • Did we incorporate all the changes?
  • Did we adhere to our agile processes?
  • Is documentation – e.g., design, use cases, test results – accurate, complete, consistent and traceability to the product?

Answers to these questions drive the continuous improvement of each development iteration. But, what if your customer can’t wait until the next iteration to realized improved processes and solution delivery? Well, you need a more real-time approach.

Sprint Cycle

In addition to post-sprint retrospectives, there are certain control points that are evaluated within a sprint. Iterative improvements don’t always need to be implemented for the next development cycle. To have a true continuous improvement agile development cycle, the health of a sprint is evaluated on a daily basis. 

During a sprint cycle, the project team evaluates metrics such as:

  • How healthy of a sprint did we maintain? 
  • Is our velocity on target?
  • Is our burndown chart accurate?

With these control points at each step in the development lifecycle, quality of the product and process is continually assessed. Those assessments drive continuous improvement of the methodology to ensure organizational needs are fully met.

When To Use Hybrid Agile-Waterfall?

In most solution delivery cases, a hybrid approach can be substituted for a traditional agile or waterfall approach. There are plenty of success stories and case studies that span industries and product variations.

In addition, there are different ends of the methodology spectrum that could warrant an exploration into a hybrid approach. Maybe you’re using waterfall and would like more flexibility. Or you’re using agile and would like to add more certainty. 

In either case, a hybrid approach could mitigate some of the issues you’re currently experiencing with your development lifecycle.

Here are just a few examples where you may want to consider a hybrid agile waterfall:

  • Your organization is currently using a waterfall approach. But, you’re having issues addressing changing customer requirements during the long development phase. In addition, a lack of cross-functional collaboration is preventing you from delivering high-quality solutions that your customer loves.
  • Business and/or technical stakeholders in your organization are not comfortable with uncertain timelines and budget. However, they value the flexibility of an agile approach.
  • The culture of your organization lacks openness and willingness to change. But, the inflexibility of a traditional waterfall approach is preventing you from delivering. An initial step to a hybrid approach – or multiple even smaller steps that slowly introduce agile processes – can be the first piece of moving to full agile.
  • The project timeline and budget are set in stone. But, a high level of collaboration with a flexibility to address changing customer needs is required.

Ready For a Hybrid Approach?

If you or your organization is looking to move from a waterfall to an agile methodology, then a hybrid approach may be the most realistic first step in the transition. 

Alternatively, maybe you’ve already moved to agile. But, the executive and business teams are uneasy with the lack of uncertainty into timelines and budget. A hybrid approach can help add clarity to project and portfolio management.

There are pros and cons to any development approach. The best methodology is the one that is right for your organization. And that is dependent on your culture, customer needs, budget, and countless other variables.

But, you know the value and importance of testing. So, if you’re interested in learning more about hybrid agile waterfall or if you’d like help to test this approach on a pilot project in your organization, email us at hello@karmaadvisory.com.

For a Conversation on Business Continuity, Check Out the Karma Insights Podcast

How to Ensure Business Continuity During Employee Departure

How to Ensure Business Continuity During Employee Departure

Maintaining “business as usual” after a major disruption in your organization is a challenge.

These disruptions aren’t in your project or yearly portfolio plan. Nor have you aligned resources to overcome.

Disruptions may result from a variety of events. Natural disasters, enterprise technology failures, cyberattacks are a few common ones that come to mind.

But, losing a key resource in your organization – along with their depth of critical system knowledge – is also a significant disruption to the way business is conducted. And this scenario may be more common and struggled with than any of the other potential disturbances to the balance of your organization.

A business continuity plan will help you overcome disruptions that your organizations will face. But, does your business continuity plan include employee departure?

What is business continuity?

The term business continuity refers to how your organization maintains business functions in the event of a disruption. Power outages, natural disasters, cyberattacks and other events that affect your enterprise are common culprits.

But, business continuity also refers to maintaining business functions during smaller scale disruptions. Employee departures may not seem as scary as a cyberattack, but their impact on business functions can be monumental.

Why business continuity is important

Unless you’re a soothsayer, there are going to be disruptions to your organization that you simply won’t see coming. Disruptions that you can’t prepare for.

Or, can you prepare for them?

Well, the answer is yes. In fact, being unprepared is the last thing that you should let happen. Resulting in downtime for the business functions you support.

Picture this… One of your most experienced Business Analysts comes in tomorrow with their 2-week departure notice in hand. This BA has owned your organization’s system of record since it was implemented over 7 years ago.

Will you maintain business as usual when that employee leaves in 10 business days? If the answer is no, then you need to create a business continuity plan. Keep reading to find out how to create a business continuity plan for employee departure.

How to Maintain Business Continuity During Employee Departure

You aren’t just losing a resource when an employee is exiting. You’re also losing their existing knowledge, experience, and informed ideas.

But, with swift and calculated actions, you can create a smooth transition. Business continuity is the goal in any employee exit. And you should treat this employee departure as any other project your organization is executing at a given time.

Here are the steps you need to take to reach that goal and maintain business as usual.

Step 1: Replacement Identification and Onboarding

The type of resource you choose to replace your departing employee will differ based on your situation.

Internally distributing responsibilities will be the quickest way to transition and distribute knowledge. But, there are obvious cons such as overloading current employees.

The hiring process can be lengthy for an external employee. Likely, your newly hired employee won’t have much, if any, overlap with your departing resource.

If this is your situation, we suggest identifying an existing resource in your organization who can lead the steps in this transition plan. Once your new employee is onboarded, you should have a base of knowledge and documentation to hand off to them.

This isn’t going to be a guide on hiring the right employee. If you’re looking for some details on how to hire the best, here are some tips.

But, you do need to identify a replacement resource. The quicker you can do this the better.

Step 2: Knowledge Transfer

Knowledge transfer is the method of capturing responsibilities, ideas, skills and personal knowledge from one or more individuals and sharing between one or more other individuals within an organization.

“Knowledge” isn’t just what is in a person’s head. It’s also what they do. Including, the activities and responsibilities they perform in order to meet operational objectives.

This step is so vital to maintain business continuity during an employee departure that we wrote an entire article on it: Knowledge Transfer: An Approach for Executing it Effectively.

The knowledge transfer process is as follows:

  1. Develop a knowledge transfer topic plan
  2. Hold knowledge transfer sessions
  3. Document and distribute knowledge

The goal of this knowledge transfer step is to transform individual knowledge into shared organizational knowledge. So, even though you’re losing a resource, you’re not losing the individual knowledge stored in their head.

Move on to the next step to learn how to deliver and distribute shared knowledge.

Step 3: Shared Knowledge Deliverable Creation

As you work through knowledge transfer and executing your business continuity plan, you need to keep in mind the deliverables that are needed for your organization to continue business as usual. A shared knowledge base – filled with the information gained throughout the knowledge transfer process – should be the primary deliverable on your list.

Think of this knowledge base as a one-stop shop for everything related to systems and/or processes owned by your departing employee. Anyone in your organization should be able to access the knowledge base after your departing employee’s final day and carry out one of the tasks they used to perform.

If you would like to learn more about deliverable creation, we talk more about it in the Knowledge Transfer: An Approach for Executing it Effectively article.

Last, but not least, it’s important that you engage the rest of the organization.

Step 4: Operational Team Engagement

Your experienced, knowledgeable departing employee really knew how to give business users that fuzzy feeling of comfort when working through system issues. They knew if an issue arose, it would be resolved quickly.

Now that their favorite technical support is departing, you’ll need to spend some time and effort getting your business organization comfortable with the transition.

Depending on your organization and the phase at which your employee is departing, one approach that we have found works well is the re-kickoff method.

Re-kickoff Method

The situation has changed. And it’s time to level set with your business organization.

The re-kickoff method allows you to re-initiate a project and/or application support. You can treat your employee departure as an opportunity to review the project/system charter, current status, project stakeholders, and communication with your business team.

In addition, use this opportunity to communicate the transition plan and upcoming objectives for the project as a whole. If feasible, show off your newly created knowledge base. This will show that knowledge has not been lost with your departing employee. And it will increase trust in the transition.

You can execute this method through a simple re-kick off meeting with your business organization to review project / system:

  • Current status
  • Stakeholders and roles/responsibilities
  • Communication plan
  • Knowledge Base
  • Upcoming objectives and the transition plan

Replacement Employee Engagement

In addition to re-kickoff the project as a whole, it’s important for your replacement employee to increase communication with your operational business team.

Whether it’s 1-on-1 meetings with the business leads or small team discussions, your replacement employee needs to initiate an open line of communication. Understanding how your business users interact with the technology, what concerns/questions they have about the transition, and how they can report issues will go a long way in building trust.

Case Study: Maintaining Business Continuity During Business Analyst Departure


A business analyst / project manager for a public sector organization’s system of record is departing in two weeks. They have served as the system owner since it was implemented over 7 years ago. They have a breadth of technical and programmatic knowledge.

Complicating Factors

Although they are not fully rolling off of the project for two weeks, their time is limited since they have rolled onto another project. The organization has been allotted 1 hour each day over the next two weeks for knowledge transfer.

In addition, the system that they owned is developed by a vendor, so internal technical knowledge is limited.

Step 1: Replacement Identification and Onboarding

The organization was able to leverage their close relationship with Karma Advisory to quickly onboard a replacement who was already part of their firm.

This individual had experience working on similar systems in a public sector environment. They were able to utilize this experience to quickly onboard, build and execute the employee transition plan, and manage the knowledge transfer process.

Step 2 and 3: Knowledge Transfer and Deliverable Creation

Knowledge transfer sessions were used to capture the responsibilities, system knowledge, and processes of the departing employee.

First, a topic coverage tracker was created and managed all the topics that were to be covered during the knowledge transfer sessions. The topics in the tracker were prioritized and updated as each were covered. In addition, the location of any notes and/or screen recordings were documented in the tracker.

As part of the knowledge transfer sessions – 1-hour sessions for 2 weeks – meeting notes and screen recordings were used to document the details about each of the covered topics. These were stored in an accessible shared folder location.

The meeting notes, recordings and topic tracker were then used to build out a system knowledge base. Microsoft OneNote was utilized to detail recurring operational processes with screenshots, the steps to complete key system tasks, technical architecture, and other general information about the system that the employee owned. The knowledge base was saved to a SharePoint location and made accessible to the rest of the organization.

Step 4: Operational Team Engagement

The organization utilized a re-kickoff approach to engage the business teams that depended on the system. A separate kickoff meeting was held for each of the main business teams to review current project status, key stakeholders, roles and responsibilities, and next steps in the project plan.

To further gain trust with the business teams, the replacement employee held individual meetings with the business leads to capture how they use the system, what questions or concerns they have about the transition, and what they can expect in terms of communication moving forward.

Do You Have a Key Employee Departing?

Losing an employee is never easy. On top of that, maintaining business continuity during their departure is even more challenging.

But, now you have the process to overcome this disruption to your organization. It’s now a matter of executing it to support your business functions. Remember, business as usual means, well, business as usual. No frantic emails, unmet deadlines, or heightened stress levels.

Do you need help maintaining business continuity? Don’t worry, we’ve been there before. And we’d love to help. Reach out to Karma Advisory by emailing hello@karmaadvisory.com.

For a Conversation on Business Continuity, Check Out the Karma Insights Podcast

Knowledge Transfer: An Approach For Executing it Effectively

Knowledge Transfer: An Approach For Executing it Effectively

It’s Monday.

Just when you think everything is going smoothly in your IT group, a key resource notifies you of their departure from your organization.

To make matters more pressing, you only have 2-weeks to extract all of their knowledge and make it accessible.

Maybe this person is a software developer who built a key system from scratch, a database administrator who is the only person who actually understands the data model, or a business analyst who has vasts amount of system and programmatic knowledge stored in their head.

In any case, you need an effective way to transfer knowledge from their brains to your organization. An approach to capture, document, and distribute their knowledge across your team instead of losing it.

Because well documented and accessible shared knowledge is never lost.

Keep reading to learn how to effectively transfer knowledge within your organization, so you can maintain business as usual.

What is Knowledge Transfer?

Knowledge transfer is the method of capturing responsibilities, ideas, skills and personal knowledge from one or more individuals and sharing between one or more other individuals within an organization. Typically, this involves an employee who is leaving the organization or transitioning to a new role.

“Knowledge” isn’t just what is in a person’s head. It’s also what they do. The activities and responsibilities they perform in order to meet operational objectives.

Some of these activities may even go unnoticed by an individual and those around them. Especially if they’ve been doing it long enough. Those user accounts that get deactivated like magic every 6 months?

Maybe that is a task that your soon departing Business Analyst has in their notes saved to their local PC.

How to Effectively Execute a Knowledge Transfer Plan

There are an endless number of ideas and activities that a single employee is a part of throughout their time within the organization. It is impossible to capture every chunk of knowledge, but it is certainly possible to capture the pieces that your organization needs to continue operating as usual.

You’re short on time with your departing resource, so you can’t afford to waste time planning out and executing complicated methodologies. You need a simple plan of action to help your organization transition from personal knowledge to shared knowledge.

Assuming that you have already identified a replacement, here are the steps:

Knowledge Transfer Process

1. Develop a Topic Coverage Plan

The time you have with your departing employee is limited. So, take some time to develop a baseline high level list of all known topic areas you need to cover. This will maximize your time during knowledge transfer sessions, so you can focus on the unknowns and the details.

The areas of most importance will be first on everyone’s list. Involve the individuals who collaborated with the departing employee, so they can add their interaction points. And most importantly, take time to go through with your departing employee during or before your first knowledge transfer session.


  • Topic Tracker

2. Hold Knowledge Transfer Sessions

Now that you have the high level areas to cover, it’s time to dive into the details and potential unknowns. The best way to do this is simply by spending time with your departing resource. If you have a replacement employee identified, it’s time for he or she to become a sponge of knowledge.

There are a few things that can help make knowledge transfer sessions as productive as possible:

Take detailed meeting minutes

Documented knowledge is only going to be as robust as what you’re able to capture during knowledge transfer sessions. Meeting minutes need to be as detailed as possible. Organizing and categorizing these notes can happen outside of meeting time.

Capture knowledge through screen recordings

If possible and applicable, recording knowledge transfer sessions can be a huge benefit. This is especially useful when working through specific multi-step tasks that your departing employee completes. You know what they say: a picture is worth a thousand words, but a video is worth a million.

Utilize your topic tracker to facilitate discussions and capture status

Your topic tracker is going to serve multi purposes as you work through your knowledge transfer sessions. It will drive discussion topics, help capture new topics that come up during meetings, and capture the status of each topic (covered, not covered, etc.). In addition, the location of meeting minutes and screen recordings for each topic should be added for organized referencing.


  • Topic Tracker – Updated with coverage status of topics and where to find the captured details of each topic
  • Knowledge Transfer Meeting Notes
  • Knowledge Transfer Screen Recordings

3. Document and Distribute Knowledge

You have your knowledge documented. Think of the meeting notes, recordings, and tracker as your raw data. Now, you need to get that data into presentable form, so it can truly be transformed into shared knowledge.

As you work through organizing your notes and topics, you should keep the knowledge transfer goal in mind. That goal is to transform personal knowledge into shared knowledge. So, you need to create some form of a knowledge base that can be referenced by your organization. Not only is the creation of this knowledge base a great exercising for educating your replacement employee, it is also a way to keep the captured knowledge safe for the future.

How you want to create the knowledge base is a preference, depends on the situation, and how your organization currently shares information. But, it needs to be highly organized and easily searchable. MS OneNote works well for application knowledge bases. Word documents that point to the appropriate files in a shared folder work well for more technical resources that have many work products that need to be referenced.

At this point, your departing resource may be gone or inaccessible. And that’s okay. Because you maximized your time with them and translated their personal knowledge into shared knowledge. But, if you do have access to them, it would be a great exercise to have them review your knowledge base.


  • Knowledge Base

How to Execute Knowledge Transfer: A Real World Case Study

A key resource and owner of a state based agency’s system of record is departing. Citizens and entities of the state apply for benefits across multiple programs using the system. These benefits are then distributed to those applicants found eligible. Nonetheless, this system is critical to meeting the agency’s objectives and more importantly, serving the public.

With this departure, the organization is at risk of losing extensive technical and programmatic knowledge that was gained while working in a Project Manager / Business Analyst role since system implementation over 7 years ago.

A new employee was quickly hired and rolled onto the project. This individual was new to the organization and had no experience with the system. So, a comprehensive transfer of knowledge was required to maintain business continuity. And due to different circumstances, the organization only had 1 hour per day for two weeks with the departing employee.

Let’s look at the knowledge transfer steps that were executed to ensure minimal knowledge loss and operational downtime.

1. Case Study – Develop a Topic Coverage Plan

Prior to the first knowledge transfer session, the employee’s manager developed a list of key topic areas to cover. This included recurring system maintenance tasks for which step-by-step details were needed, general system and programmatic knowledge transfer, and project management details.

This list of topics was added to an Excel spreadsheet and organized by importance. The items with the highest priority – such as audit coverage and recurring system maintenance tasks required to maintain operations – were to be addressed first. The first knowledge transfer session was then used to go through the list and capture any other items that needed to be covered.


  • Topic Tracker
Knowledge Transfer Topic Tracker Sample

Topic tracker sample.

2. Hold Knowledge Transfer Sessions

Knowledge transfer sessions occurred via 1 hour web meetings for two weeks. They included the replacement employee, program manager, and program director in addition to the departing resource.

These sessions were recorded and detailed meeting notes were taken by the replacement employee. The replacement employee was tasked with facilitating the meetings, taking notes, and organizing as needed.

The topic tracker was updated after each meeting to include the updated status of topic areas and the references of where to find the covered topics in the meeting notes and recordings.


  • Topic Tracker – Updated with coverage status of topics and where to find the captured details of each topic
  • Knowledge Transfer Meeting Notes
  • Knowledge Transfer Screen Recordings

Knowledge Base Development Process

3. Document and Distribute Knowledge

Upon the completion of the 2 weeks of knowledge transfer sessions, the organization was armed with over 27 pages of detailed meeting notes and screen recordings of each session.

Using these notes and newly acquired knowledge, the replacement employee was tasked with building out an MS OneNote knowledge base that was segmented into an operation manual, the release management process for new system builds, and processes for supporting various groups in the organization such as legal and audit.

To put the icing on the transformation to shared knowledge cake, the knowledge base was loaded to a SharePoint folder that the rest of the organization had access to.


  • Knowledge Base

Do You Need Help Sharing Knowledge in Your Organization?

If you’re losing a key resource or in need of better knowledge distribution across your organization, then we can help. At Karma Advisory, we’ve assisted organizations like yours in transforming tribal knowledge into useful organizational knowledge.

We believe that an IT organization’s strength lies in its shared knowledge. And siloed, inaccessible expertise is a risk.

If you’d like to learn more about how we can help document and distribute your knowledge across your organization, then email hello@karmaadvisory.com or use the contact form below.

For a Conversation on Knowledge Transfer, Check Out the Karma Insights Podcast