Implementing an enterprise software application is a scary, daunting task which all too often fails to achieve the adoption level required to ensure its success. In fact, some reports have shown that upwards of 70% of IT project implementations are not successful, with 17% of those projects going so badly that they threaten the very existence of the company.
And yet, without investing in technology, companies stand no chance to remain competitive. Herein lies our Catch 22 - technology implementation is absolutely necessary, but should be approached in such a way to mitigate the risk of failure.
Having implemented hundreds of enterprise software projects for our customers, Cella’s Technology Practice Group has developed best practices which guide our own approach to implementing software on behalf of our customers to be as successful as possible. These principles can be adopted no matter what type of technology is being implemented and should be considered no matter if you’re implementing a solution yourself, working directly with the providing technology vendor, or a 3rd party implementation partner, such as Cella.
Need to speak with a Cella Consultant?
Tool Selection
The first step in building towards a successful outcome is to conduct an objective tool selection effort. This is critical to ensure a platform meets the identified functional requirements of the business as a starting point and prevents a tool from being selected based on biased, subjective interest.
Discovery
When conducting a tool selection effort, start with an inclusive approach to discovery, making sure you interview both leaders to communicate the business requirements and the end users to communicate practical, functional needs.
Agile User Stories during discovery is an effective framework to use when conducting interview sessions specifically because they establish goals by answering the ‘who’, ‘what’, and ‘why’ of those involved. The formula is:
As a [who - role], I need to [what - action], so that I can [why - goal]
For example, As a ‘Creative Director’, I need to ‘provide feedback’ so that I can ‘deliver quality content’
Scorecard
The feedback from these various interviews can be used to build a scorecard which outlines the functional requirements in support of business goals. Divide the functional requirements into primary categories which account for the major use cases of the platform (for example in the case of project management, ‘intake’ or ‘document handling’ or ‘resource management’) along with business considerations (such as security requirements).
That being said, functional requirements are not enough. It’s important to weigh each requirement so that the overall importance of a solution’s ability to deliver against each requirement can be understood relative to the importance of the need to the organization. Get as many stakeholders to contribute a ranking as to what each feels is the importance of each requirement, then create an average weighted score which represents the importance of the requirement to the organization as a whole.
With scorecard in hand, a shortlist of vendors can be quickly identified based on relative ability to deliver against the requirements. 3-4 vendors is a good number to move forward with to provide a range of solutions for consideration.
Demos
Schedule demos with these vendors and ask them to demo their solution against an identified use case which is relevant to your organization. As each vendor performs their demo, the team should score their performance against the scorecard with as many stakeholders participating to deliver an average scoring review.
The final recommended solution is based on the objective performance score, but should also take into account additional financial considerations such as recurring licensing costs and any one-time implementation or onboarding fees, the vendor’s approach to change management, and the alignment of the vendor with the company’s overall culture, which can be a less quantifiable metric, but an important one nonetheless.
Core Team
Following the objective selection and procurement of the tool, it’s important to put together a project plan for the implementation whether this is managed internally by you or by the vendor.
As a first step, identify a core team to own the project which represents a cross section of the various functional groups who will be using the tool. The sweet spot of participants is 6-8 individuals as we have found too many cooks in the kitchen results in indecisiveness and contributes to potential delays. The individuals involved must be well informed to represent the needs of their groups while also authorized to make decisions which will be accepted on behalf of the groups they represent.
Getting to ‘A Ha!’
When designing the structure of the implementation project, we have found that the sooner you can get the tool into the hands of the end user, the better as it enables constructive feedback and input from the people who will be using the platform day-in and day-out. New software often represents a change in the status quo and can be quite unsettling for users who are accustomed to a specific way of working. On the road to adoption, all users go through a process of eventually realizing the benefit of a new system and understanding its basic functionality. We call this the ‘A Ha’ moment as it signals the point at which the lightbulb goes off for users and they begin to own their part in contributing to the overall success of the project. The faster you can get users to the ‘A ha’ moment, the greater your project’s chances of success. Understanding this will have significant impact on the process used to manage the overall project.
Agile vs. Waterfall
The tradtional waterfall methodology of managing a project involves approaching tasks in a linear step-by-step fashion through which the next step cannot begin until the previous one is complete. In this way, all discovery must complete before moving on to design, which itself must complete before you build, train, validate, etc…
This is incredibly problematic for a variety of reasons.
To say discovery must complete before design means that all functional requirements must be identified upfront and early which is unrealistic. It is rare that a team truly knows every functional detail which will be required in the tool upon launch. At this point, the team has only vague understanding of the features because they only have limited exposure and have not yet gotten to the ‘a ha’ moment.
Even if the implementation is guided by an experienced partner (or the vendor directly), discovering full functional requirements upfront on behalf of end users means that this phase of the project will extend the timeline significantly.
Furthermore, because the users have not been exposed to the tool, constructive feedback on design recommendations is impossible. Only after the ‘a ha’ moment is reached do users know how to interpret a design recommendation. If a change has to be made at this point, the consequences are significant as the impact of pivoting results in a huge amount of wasted effort incurred up to this point.
Instead, an agile methodology to implementation takes the approach of demonstrating value over time through iterative ‘sprints’. Full system functionality is deprioritized and a minimum viable product (MVP) is identified as a first step. The design of the MVP reduces overall discovery and can be built quickly to demonstrate the basic working process of the tool to end users. This allows quicker exposure, faster time to ‘a ha’, and more immediate constructive feedback. If a change is required at this point, the amount of effort incurred to date is far less which results in reduced waste and faster course correction.
There are multiple ways to approach the MVP. One way is to identify an individual workstream out of many in use by the organization and deliver full functionality in support of that single workstream. Another approach is to deliver a solution which applies to multiple workstreams, but is limited in total functionality.
Either way, the tool will have to evolve over time. No enterprise application worth its weight should be approached with a ‘set it and forget it’ mentality. This should not be considered a detriment, but rather the ideal starting point. These are dynamic systems which are intended to scale for multiple use cases. As the user base becomes more familiar with the tool, their understanding of how to leverage it will expand and may evolve past the initial design of how it was to be approached in the first place. At this point, the team and tool can evolve in parallel - as processes mature, the tool will expand to support more complex needs.
This is the beauty of agility when applied to implementation. The iterative and continuous feedback provided by end users is logged and prioritized for development, then released in a cadence against which the same end users are ready to provide appropriate feedback, looping over and over.
From an onboarding perspective, the launch of the MVP should not signal the completion of the partner’s role in the implementation project. The owner of the implementation, should at a minimum participate in the first round of customization of the platform past the MVP. This way, end users can be guided towards realizing what is capable from a growth potential past the funcitionality defined in the MVP.
Collaboration
As the build progresses, it’s important to involve the core project team in decisions and tasks related to the configuration of the platform as much as possible. An interative tool which allows the team to communicate and visualize project status in realtime, such as an online kanban board which allows for task assignments and even @mentions, is a great method to include the core team and incentivize ownership over time. Ultimately, there must come a time in which the core team moves into full ownership of the tool. Early participation not only keeps project dynamics healthy, but it trains the team on how to assume ownership moving forward.
Patience
As a final note, it’s important to acknowledge that implementation of enterprise systems is hard, but that shouldn’t be a deterrent (see the reference to my previous note regarding the necessity of implementing tech for basic business survival).
The road to success in the journey of onboarding technology follows a roller coaster of emotions ranging from excitement through frustration, despair through enlightenment. As you embark on your journey, it helps to be aware of these trends so that you can anticipate the temporary nature of seeimngly daunting obstacles and recognize growing pains as an indicator that success, if you push through, is right around the corner.
Adapted from Gartner’s Hype Cycle of Emerging Technologies, the graph below illustrates the emotional trends which all users go through on the journey to tech implementation.
Following discovery, expectations skyrocket and users begin to dream of the nirvana-like experience the technology has been promised to provide. But the honeymoon is short lived as, following discovery, expectations plummet when the real work begins and users realize the amount of lift which will actually be required to activate change. At this point, it’s very easy to revert back to the old way of doing things which, if not addressed, leads to abandonment. Only by persevering through the ‘trough of dillusionment’ and embracing change, does the technology succeed and become adopted. It’s important to remember that this frustration is temporary and is simply the nature of evolving at a rapid rate. Some will resist change and constrict. Others will embrace change and expand.
The journey of enterprise technology implementation should not be taken without a map and without conducting research on how best to prepare for the road ahead. Some teams have the discipline to take this effort on themselves, but working with an experienced partner, such as Cella, can lighten the load and significantly influence success. The members of Cella’s technology practice group are experts in delivering sherpa services for our clients across all major martech & creative operations platforms types. Let’s take the journey together.
Fortune 500 companies are proving to be very keen to bring in companywide consulting services to reimagine their business through these recent changes, but where does that leave the unique requirements of the Marketing and Creative departments? Already a largely misunderstood service offering within their organizations and much dwarfed in size ratio compared to their company's primary offerings teams, and they are now experiencing re-organization recommendations from external advisors with little or no expertise in this unique field.
If this is not enough, Marketing as a discipline is also going through a remarkable transformation with the demands to serving more individualized content in addition to developing more engaging customer and brand-centric messaging, leaving both the Marketing and Creative departments scrambling to make sense of suggestions and requests for change that often don't relate to the delicate balance of skill sets, volume and project types required and produced in our world.
However, you are not alone, and there is support out there for you that can supplement the generic business transformation engagement and simultaneously propel the Creative and Marketing service offerings into a future state in one go.
Planning now for how your team may require an operational strategic refresh will have you prepared to position and represent your department in the face of any restructuring that may be happening in your organization.
Knowing how your department's organizational structure could enable a hybrid working model while increasing delivery capacity and moving towards a growth marketing mindset may become a key discussion point and provide you with a seat at the table when decisions are being made.
With the sharp increase in planned IT spend over the next five years, having a technology strategy map to demonstrate critical technologies that will allow marketers to plan their campaigns and engagements that will automatically provide visibility to creative operations to plan their resources accordingly while creative talent can easily access assets through a genuinely integrated Marcom echo system, will place your needs in the hands of the IT planners, ahead of the game.
Specialty departments like Marketing and Creative need and deserve the attention and support of subject matter experts in this area. With over 30 years of experience, specifically in Marketing, Creative and Digital operations, Cella is here to provide you and your team with the positioning, and business justification the financial controllers and C-Suite need to hear and understand your unique needs. Let us provide you with the voice you need now.
For information about how Cella can support your Marketing and Creative department needs, please email [email protected]. To learn more about our services, visit www.cellainc.com/services/consulting.
