implementation Tag

Understanding the type of DAM that is right for your team can be a challenge. Over the past few years, I have taken on a new role as a consultant. With my creative, marketing/communications, and project management experience, I have a fresh perspective when aiding clients in finding the right tools for their marketing and creative stacks.

Each client I have worked with endures similar challenges when evaluating their tools in their stack. Enterprises face difficulties with having too many tools and creating tools that are too proprietary – limiting growth and integration. They also struggle with user adoption. Picking a new tool for your marketing solution stack is not an easy feat. It is easy to get caught up in the details such as features of the tool while trying to balance buy-in from stakeholders (IT, security, VPs, and end-users), and balancing a budget. So how do you know where to start when you are evaluating Digital Asset Management tools?

 

THE 4 P’S

I have found that the 4 P’s are crucial to not only selecting a tool, but configuring it properly, and ensuring user adoption for long term success.

Understand the PROBLEM you are trying to solve, the PRODUCT you are selecting to solve that problem, the PROCESS for which the organization works, and the PEOPLE that are using the new tool.

Problem

Tools should never be sold – they should always solve. From my experiences in both marketing and creative industries, I have understood the struggles first-hand that users encounter when trying to complete work. The first step to tool selection is establishing the problem you are trying to solve. Are you bogged down by spending time constantly trying to distribute files? Are you struggling to keep the most current files at your fingertips? Do you have too many places where files are stored? By clearly establishing the problem, it will remain a strong focus on selecting a tool that will be adopted long-term.

Product

Selecting a product is not easy. There is a lot to take into consideration when choosing the right product for your team. Keep in mind the identified problems to resolve, without setting technical limitations. While the DAM you select should have all the right features and functions, also consider what other tools you already have in your stack. What integrations are available for the DAM you are selecting? What other groups or teams may want to leverage the DAM in the future?

Considerations of cost are equally as important. Time is money, and the DAM you select should help reduce the overhead hours your team is spending searching, delivering, and modifying assets. Will other teams benefit from the addition of a DAM? Teams should be selecting a tool that can grow with the organization, and that can meet their needs. The bottom line is that the DAM you choose should work for you and your team, not the other way around.

Process

Often the problem comes, not only with a need for a tool but the need for understanding of where in the process each tool should sit. After recently attending a DAM conference with a room full of tools, I could see how attendees were overwhelmed. The challenge with “pitching a solution” is that you need to understand the organization and process first. Organizational assessments are vital in selecting the right DAM. It is essential to first understanding workflows and internal organizational structure to provide an educated recommendation that will meet your organization’s needs. Consider scalability. Selecting a solution that works not only for today but also for growth tomorrow. Naturally, organizations shift and change over time, so the tool implementation must be completed with a full understanding of the potential growth of organization and integration.

People

Understanding the organization from high-level executives, IT, and end-users is key to a successful roll-out. Top-down leadership and messaging is key when rolling out a new tool and will help drive user adoption. The most successful clients I have worked with understand that getting key stakeholders involved from the start will help drive success. However, the other side of the coin is involving end-users at all levels. Involving these users will help create champions among the team to ensure the new tool is well adopted. Get your teams involved upfront in part of the tool selection process, develop clear communication, and have a roll-out plan in place.

 

We would love to learn about where you are in your DAM journey and discover ways we can ensure your continued success. Contact our team of DAM experts today – email us at info@leappoint.com

While many companies are moving toward DevOps processes and tools that fit that framework, few are actually implementing the workflow with the fidelity needed to make teams more productive, according to a Thursday report from 2nd Watch.

Implementing DevOps means fundamentally changing your software engineering process. As with any change of process, success depends on how well the people making the change embrace the principles of the new approach. If people reject, subvert, or undermine the DevOps philosophy, it will fail. Here are six of the most common reasons for DevOps failure, along with tips to increase your chance of success.

1. Creating a traditional “DevOps Department”

78% of the 1,000 IT professionals surveyed said that their organizations continue to have separate teams for managing infrastructure/operations and development—meaning that DevOps is still not fully underway. DevOps involves a collaboration between development, operations, and quality assurance teams. Creating a traditional DevOps department misses the point of making a transition to a DevOps mindset, and is likely to simply add more red tape to existing processes.

This is the opposite of what DevOps should accomplish. Yes, a DevOps implementation requires leadership, but that’s not the same thing as traditional, department-based management. Your DevOps strategy should be implemented as a framework in which your development and operations staff can begin to interoperate, not as a new department that’s tasked with overseeing these disparate groups and somehow forcing them to work together. Focus on getting teams to improve their communication with people working in other departments. In this way, it is possible to assign tasks to the right teams so that every task is completed at the correct point in the overall project workflow.

2. Failing to properly consider staff workloads and other resources

If your developers are already overworked, this might not be the best time to start a dramatic overhaul of their working processes. Before you spring a DevOps implementation on your team, take the time to quantify their workloads and measure performance metrics, so you can see whether individuals are coping with the demands your organization places on them. If you come across an unmanageable boost in workload, you can either re-prioritize the workload or hire new resources to address the staff shortage before you can start your DevOps implementation.

3. Setting unrealistic goals

Never underestimate how big a culture shock DevOps can be in an organization that currently uses a silo structure. You cannot expect everyone to immediately adapt to the change and deliver excellent performance from day one. Be realistic about how long a DevOps implementation is likely to take and set short-term and long-term goals accordingly. And remember: The larger your enterprise is, the longer this transformation is going to take.

4. Creating “hybrid” DevOps while keeping old structures

Some organizations try to reduce the culture shock of DevOps implementation by keeping the business’s old structures intact. However, giving into pushback from developers in this way can undermine the implementation. Rather than keeping the old culture intact, one solution is to build a true hybrid structure that keeps IT operations and development teams in their traditional silos but implements an agile methodology.

5. Misunderstanding the role of business owners

The role of a business owner is to make top-level strategic decisions about the way in which the business is run. It is not to micromanage everything that goes on in the company. While a business owner can decide that the company would benefit from implementing DevOps, they cannot always control how individuals and teams put the principles of DevOps into practice. Rather than trying to impose a new way of doing things, business owners should be willing to listen to the concerns of developers and IT operations employees and find solutions that help them to work more effectively within a DevOps framework.

6. Not embracing a culture where failure is tolerated

Transitioning to DevOps is, first, a cultural shift, and then a process and organizational shift. If you’re considering DevOps simply because “it’s the future”, rather than out of a desire to fundamentally rebuild and improve your business processes, success is highly unlikely.

A key part of the DevOps methodology is failure. Developers should not be afraid to admit to mistakes, particularly when talking about failures could be a vital learning experience for the whole team. When implementing DevOps, be sure to nurture a culture where failure is tolerated.