How to Build a Better Technology Roadmap (Video, Podcast, Transcript)
View this video directly on YouTube (and subscribe to our channel!)
Listen to the Podcast
Like podcasts? Find our full archive here or anywhere you listen to podcasts. Or ask your smart speaker.
How to Build a Better Technology Roadmap
All nonprofit organizations stand to benefit from an improved technology environment. But does your organization’s technology roadmap provide you with the directions you need to succeed with those new and improved technologies? Do you know how to build a better technology roadmap in 2021?
You may have gaps in leadership, operations, business process, and data management capacity that have prevented your organization from effectively selecting and implementing technologies to serve your entire organization and its mission.
Without addressing these gaps, your nonprofit is at a higher risk of technology system implementation failure.
Learn how to address these gaps. Technology implementation can require significant change management efforts, for all staff. Don’t let your technology fail by not addressing systemic changes necessary for success!
In this webinar, Build Consulting expert Peter Mirus explains how to build a technology roadmap that will guide your organization to a successful future.
Peter draws on years of experience consulting with nonprofits on technology projects to give you practical steps to implement quickly.
Learn how your organization can create a technology roadmap that is right for you.
As with all our webinars, this presentation is appropriate for an audience of varied IT experience. And Build is scrupulously vendor-agnostic, so you can be sure this webinar will be an opportunity to learn from your colleagues without a sales pitch of any kind.
Peter Mirus: Hello, everyone and welcome to the Build Consulting Webinar for February 2021, titled How to Build a Better Technology Road Map in 2021. Today, I’ll be introducing some key concepts to inform your text strategy and road map, primarily focusing on areas that often get overlooked, but if it attended to properly will dramatically increase your chances of success in seeing a return on your technology investment. I’m definitely going to leave a lot of the time at the end for any questions that you might have, and you’ll also have access at the end of the presentation to my personal contact info, for any follow ups that you’d like to send my way. I’m happy to have an email or a brief chat.
Just a couple of quick housekeeping notes before we started with today’s presentation. Feel free to ask the questions using the available Q&A feature in Zoom, I’d appreciate that. Avoid multi-tasking, you may just miss the best part of the presentation, but if you do recordings will be available after the fact and will be shared via email.
Meet the Presenter
My name is Peter Mirus, I’m a founding partner at Build Consulting. I have 20 years of experience severing non-profit organizations, ranging in size from small and local, to enterprise and global organizations, and across a wide variety of industry, categories, and mission orientations. Over the past seven years, I have worked exclusively with non-profit organizations, working with about 100 clients total. And I have three primary years of expertise – marketing, constituent relationship management and information strategy.
And little bit about Build Consulting. We’re invested in the non-profit community. We work exclusively with non-profits and have served over a 1000. We work strategically to help our clients make information technology and information systems decisions that support their mission. And we are collaborative on our approach. We empower our clients to make informed decisions on their own behalf. And these are just some examples of how we lead in the social good sector through providing services, but all of our services are designed to help clients transform themselves to better serve constituents of all types, including funders, donors, program beneficiaries, staff, volunteers, and the general public.
Fundamentals of a Technology Road Map
So, how about we just dive into a couple of fundamental things that should be in every technology roadmap. And I think the first thing is to make sure that the vision for the future of technology at your organization is aligned with your organizational strategy and vision.
What you see on the screen here is an example of a vision of a future slide that we put in a roadmap for a client. And you can see it’s very business centric. We really want to give them technology solutions as it says here, that’ll help staff treat member and funder relationships as organizational assets, not things that are siloed into individual parts of the organization.
And the goal is that we want to drive new and expanding relationships. And the idea is that, within those relationships we’ll work on engagement and will have service to constituent groups that’s so strong that it elevates the entire the brand of the organization, leads to greater opportunities for mission’s fulfilment. And then some specifics about the characteristics of what that vision includes, in this case we’re using our information strategy framework for Build Consulting, which I’ll talk to you about in a minute, to organizing it into five areas focused on leadership, development of operational capacities or resources, better business processes, data models and a smaller, cleaner for this organizations example, set of modern technologies solutions that really support those business process necessary to serving constituents at a higher level.
So, you really want to make sure that your organizational strategy and your technology strategy are aligned with each other and they have a common vision. The next thing that you want to make sure to include is the case for change. And that case for change should oriented towards what your organization ideally is going to solve as problems and then, what challenges or opportunities are going to be able to be addressed, as well. So, basically, what is the reason whether it’s the pain or the opportunity that’s going to make it, a good idea for the organization to take this path, to go down this roadmap.
And for this particular example that I’m showing on the screen here, also from a client deliverable, we highlighted that technology adoption and effectiveness is low, compared to their organizational peers. There is lot of pain and confusion regarding how business processes should be executed within the provided technology solutions, some problems would process standardization, high level of complexity resulting from the number of solutions in use. I think this organization had about 40 to 50 staff members and have probably about 26 individual systems. So, that’s a lot of systems for an organization of that size. And it resulted in a lot of complexity, different things being done in different parts of the organization using different tools in different ways.
So, that resulted in a lot of inefficiency and also the opportunity – the significant opportunities to better fulfill the mission. We believe that the client could significantly increase the quality of service it offers to constituents by trying to purse that path. And then, there is what we all think about when we think about a roadmap. What are the different paths or tracks that were going down? What kind of projects that we need to pursue? This example on the screen here is from a client that was primarily focused on improving their ability to assess report and analyze on the financial performance of the organization across all of their programs.
So, this roadmap was more specifically focused, on the other roadmaps with maybe involved the entire tech feature for an organization. We think it’s important when we are putting on roadmaps to identify quick wins. I think this part and parcel of all or most roadmaps that Build to puts together for our clients. What are those things that can be achieved in the short term that will help sustain organization participation and help to motivate people as we move towards some more of those longer-term objectives?
And then, often time is there is some data governance or greater area of governance or accountability that needs to be established. It might be a data governance committee or a better approach from executive teams towards interacting with technology projects. We’ll talk about that a little bit more in the future.
And then, in this case, they have priorities that were very closely aligned to the overall goal of getting a better and more streamlined financial picture of their performance. That revolved around standardizing grant management and budgeting functions to make sure that they really have the processes in place to produce the data that they wanted to see, as well as funding allocation procedures and then work on improvements Intacct, which was in their current ERP system, and then finally implement a global financial and planning tools.
So, I just want to empathize that you would probably want to have somewhere between five to ten tracks. If you have too many more than that or paths that you want to pursue in your strategy – whether it’s a one-year strategy or three-years strategy or five-years strategy – people start get a little bit overwhelmed with too much information. So, you really want to focus on those key organizational priority and risks and then create sort of tracks that aligned to that.
And this is a visual of how you can identify specific projects that we would take place within each of those tracks over a period of time. I’m not going to go into detail on what’s on the screen here, but you want to make sure that you’d break them down, so that each project seems well defined and the approachable, and that they are in logical sequence. So, if you just take a look down at the track number two there in red, we want to make sure that leadership alignment and change planning for the feature financial data analysis is in place before you get into the process of sort of trying to redefine functions or processes, or really before you even start to implement a financial planning and analysis solution.
So, it’s important that the project be well defined and that they be sequenced, and that everybody understands what the definition is of the projects and how they’re going to take place in order. Part of that is providing a good overview for whatever that our initiative is that’s being perused, but it’s also specifically defining the different projects in terms of key activities, expected outcomes, expected cost drivers, staff involvement or involvement level, and assumptions are notes.
And so, when you are outlining your projects tracks and projects to create your roadmap, these are the kinds of details that you want to see at the high level. Every project that you desire to undertake that’s in keeping with your vision, that’s in keeping with your idea of change and why the change should be undertaken, should fit into a framework like this. So again, you should clearly identify the projects that you’re going to pursue, you should define those projects specially and prioritize, and then sequence some overtime.
So, this is just to give you an idea of how we think about what a roadmap should include. But there are a lot of things that go on behind the scenes or under the surface of the roadmap that are very important and really help create a foundational bedrock for the successive any strategy or implementation plan. And that’s what’s going to be the primarily focused of what I talk about today.
Build’s Information Strategy Framework
In Build Consulting, we say that tomorrow is best for non-profits where we use technology to transform themselves and the world, but the problem is that more than 50 percent of non-profit technology projects fail. And the reason for that is often, because the technology moves forward, but the organization does not.
We often show this formula to our clients OO + NT = EOO and it stands for Old Organization plus New Technology equals Expansive Old Organization. And we share this to highlight that transformation is critical to success in technology initiatives. There is no such thing as a technology change project that isn’t also, to some degree, an organizational change project.
And that’s why when we think about creating technology strategies for organizations, we think about what’s on screen here, which I mention before. You’ll see that technology is all the way to the right and that’s deliberate. So, first you have leadership and governance, then operations, process, data, and technology.
So, when good leadership is engaged in setting the turn for any technology initiative, it typically goes more smoothly. Even the seemingly smaller initiative benefits when leadership participates. And so, when you’re creating technology roadmaps, you really want to plan the for executive sponsorship and executive participation. When we think about operations, we often think in terms of human resources capacity and especially, internal capacity as it comes to project management and communications and thinking about the ability to deliver technology projects and communicate about them to the organization.
And then in the process area, you want to make sure that you have the capacity internally and you plan for the design of effective processes. And that means more than just coming up with the best way to do something. It means developing sufficient documentation of the processes and above all setting the framework in place to execute the process consistently in the new systems or the enhanced systems. It’s one thing to a degree, to a standard process while you were in the conference room, and that’s another for team members to actually consistently put into practice at their desks.
And then, in order to really make good use of the data that you have in your technology solutions, it must be consistently collected, it must be well organized, properly maintained and used. So, organizations must do all of these things to have an effective information management environment.
And then, technology can be viewed as the thing that naturally comes along once you’ve gotten everything up stream of that correct. It can often be viewed more as the simple answer to adjust problems with leadership operations processes and data, but for the most part technology is supportive of how organizations behave. New technology will again, for the most part, not make up for what is lacking in the other areas.
So, the last two keys, as I said, particularly the technology part are highly deepened on the first three. If you don’t have good leadership, operations and processes, success in the data and the technology management will be hampered. So, when you think about technology roadmaps, make sure you think about it holistically, what the organization needs to have in place foundationally in order for any of those initiatives to be successful. And then, make sure you plan for each of those things when you’re actually putting the details of your roadmaps together. And now I’m going to talk in a little bit more detail about what that means practically.
Keys to success
So, I’m going to talk briefly about nine different keys to success in planning technology, projects, or roadmaps. And there are two regarding leadership and then six related to operational capacity. And then, I’m going to include with an extremely important key to success that encompasses the processes data and technology pieces and after that we should have a lot of time for questions, if you have any?
So first, I want to talk a little bit about executive sponsors. Executive sponsors should be attached to any significant technology project inside of an organization, particularly for large, broadly impactful initiatives, such as selecting and implementing an organization wide CRM. Executive sponsors should be visible with their participation and have regular communication. They should assist with the prioritization of resources towards the effort and provide guidance and support and ensure accountability.
So, I mentioned a large-scale CRM project and that’s one thing that Build often helps its clients with. And for a CRM platform like Salesforce or a broadly used CRM system, when you’re completely replacing that in your organization, that’s a significant change effort. It really should often times be one of the top two to three strategic priorities for the organization during the duration of that projects being ongoing. So if it’s that important, it should also have consistent and prioritized executive engagement. There is a lot of good information on our site and we put a newsletter out recently about how leaders and organizations, both technology leaders and others, maybe at the C-level or at the director or manager level, can really get engaged, regardless of their level of experience with technology projects to help ensure of their success.
And then, you want to make sure also at the leadership level that you identified the business benefits and performance measures. And this should be done as a collective effort including all the necessaries stakeholders. You basically want to say what purposeful actions are we going to take during these technology projects that are on our roadmap, to ensure that the benefits that we realize, that vision for the future is actually going to be achieved and then sustained once the project ends.
And you also want to develop clear structures and models for performance measurements because otherwise, how do you know when you when you’ve been successful? An example of a business benefits would be to achieve a ten percent increase in sustaining members for a fundraising organization or sustaining givers.
Now, technology can help to support this particularly if it predicts which donors will become sustainers. It helps automate the campaign outreach process, but technology alone won’t address the issues. So, there are purposeful actions that need to be taken during the implementation to make sure that this benefit is realized and that might include effective training of staff on how to use the features and documenting the new business processes to make sure that they can be sustainably performed overtime if there is turnover in stuff, for example.
So, what I’m going to show on screen here are just some examples of ideas for performance measurement when you’re putting a new system out there. So you can think of, in this case, we had a Salesforce based product that we branded Engage. If we think about it as a product, it’s basically a set of integrated tools supporting business processes. How well does the product support business user’s ability to execute these processes? And then the very essential measure, is the product successful? Does it do what it supposed to do?
And then also the product, the Salesforce platform as a service. In this case, this Salesforce based product was a community in which mentoring services were delivered. And we had a lot of complexity to it. So, we had a set of training resources, support resources, human resources and then knowledgebase, et cetera, that were supporting the product. And so those were being experienced as a service that was part of this tool.
We wanted to ask, how well does the service support the effective use of the product? For example, if you’re rolling at a new solution you might say, “How well did the rollout go? What was your experience of the service that we delivered? How do you experience the service that we provide through training and knowledge recourses? How do you feel the service of support helped our support? Et cetera.”
And then ultimately, what you want to measure is the tool or the system, as a business accelerator – what sometimes called the business accelerator. What were you able to do better or differently and what kind outcomes did that result in? How did the product and the service lead to positive or accelerated business outcomes? So even if you’re just doing it at a simple level, you really want to think about any technology tool that you roll out to a small or large group of people, in terms of how well you know when has been successful, that’s the bottom line. How will we all be able to know that this has been a success and we’ll continue to be a success overtime? So, that should be planned for in your roadmap efforts.
I want to talk little bit about project planning and direction, because this is very careful, I mean this is very important. A lot of technology projects that fail do so because they lack experienced and consistent projects leadership. So, you should choose someone to lead the projects that are in your roadmap that has already successfully performed a similar project, in a similar situation and in an organization and environment or maybe even someone that has a failed project and learned sufficiently from that, to know what it takes to be successful in a new initiative. And then empowerment is critical – you have to give the person that’s leading the project and planning the ability to hold stakeholders accountable of their participation and their engagement.
Plan for Time Management
You also need to plan for time management. One of the primary challenges of successful time management in non-profit organization is that employee time is often not budgeted or tract for other projects or their day-to-day tasks, resulting in the sort of approach from the organization, that all staff time is considered infinitely flexible. And so as a consequence of this, staffs are often given new responsibilities associated with tech projects, without taking anything off of their plates that would give them that time of available to commit to the effort.
So, this results in many projects under performing or failing outright, as well as morale problems and increased staff turnover. The time budgeting approach that it has to get done, therefore it will get done, does not often lead to technology project success. So, you want to make sure you plan for that internal level of effort, not just if you are using an implementation partner for say implementing Salesforce, what their time is going to cost, but also what your internal time is going to be and hopefully, also some idea of what that costs. So, people understand the total investment that’s going into executing the project in this roadmap.
So, this is just an example of how you can start thinking about what a project leader is doing and what success looks like for that role. All team members that are involved in that effort have a single point of truth for the development of that tool or system, as well as any change management associated with it. Executives and managers are given an accurate view of the project’s status and can get questions answered at the more detailed level. And for that individual or leader to ensure that goals and deadlines are being set for milestones and that the tasks are realistic, given a scope of activities already planned for the given time frames.
We sometimes talk about when we’re thinking about technology roadmaps and timelines, what are the competing initiatives that are going on in the organization at that time? So for example, if your organization hosts a national event or a conference every May, then it’s pretty likely that a large number of people inside of the organization are basically going to be MIA in regard to technology project participation, maybe from March through June, let’s just say.
So that is a critical consideration; it is a competing priority. It doesn’t mean that it’s an adversarial competition, but it’s just reality that you have to think about. So, you probably shouldn’t plan to roll out a new system that probably impacts a lot of people and may have any fiscal year – maybe shot for an October – a calendar year, maybe shot for an October time frame for that implementation.
Succeeding as a Project Leader
And then taking it from the leader all the way down the line in terms of planning, staffing and time commitments. You really want to spell out all of the different roles that it’s going to take to make each of the project successful. So, for your project roadmap or may be across the projects, do you need a trainer? Do you need somebody to manage or coordinate support? Who is that person going to be? Whatever are their career responsibilities? What does success look like for that role? And what is the average weekly level of effort going to be projected throughout, in this case for the particular client example, the 2020 and 2021 fiscal years. LOE here stands for Level of Effort.
And they did this for multiple different roles here, approaching a major Salesforce implementation or a Salesforce Communities implantation to over ten thousand people. So, there were a lot of roles that needed to be involved and a lot of people that needed to be engaged to make that critical part of their roadmap successful.
But, even for the smaller projects, you want to clearly define who needs to be involved and what in ways? For projects that are sort of are in the assessment stage, where you are trying to determine what your requirements are for future systems to be selected, you might define this in terms of who are going to be the key stakeholders and/or subject matter experts that are going to contributing input, reviewing the requirements, validating and prioritizing them, participating in all those meetings and documentation review, et cetera.
Change Management Considerations
Now a lot of organizations run up against the problem of not budgeting well for change management, as a function inside the execution of the technology roadmaps. As I said before technology change always requires some sort of organizational change or behavioral change and the path of change management helps define the change that is coming, assess its impact on the various roles in the organization and helps prepare for those roles.
So, this is what we call our Build Consulting Change Management Framework. And it basically gives you the three main things that you think about on your implementing any new system. What is the change going to be? So, you need to define the change. What kind of impact is it going to have on the people that are using the system or otherwise effected by it? How are we going to help to prepare them for that impact?
And so, again, this is a pretty simple frame and it’s just something that you can use as a mental checklist. So, you’re going to – let’s just say – you’re going to implement a new marketing automation platform for emailing, newsletters and maybe doing some social media monitoring, et cetera. Who is going to be affected by that? You’ll start with, what are the changes going to be? What’s the difference between the old tools and the new tools? What are the processes that are going to change? What data are we collecting and analyzing through the tool? Is that going to be different?
So, at first you want to write all those things down and be very specific about it and then share and gain agreement across the team that you’re working on the project with, that these are the changes. Don’t move until you get to that level of agreement. Then you can proceed to identify the impacts and sort of qualify or quantify what that impact is going to be and then you want to prepare for impacts. For us, that means you want to activate or engage leadership and align them to the initiative. We talked about the importance of executive sponsors earlier; you want to communicate about the change, and then you want to provide training and support for the change.
And this is a complementary tool that we provide in the learning section of our website, [it’s part of the Change Management Template], it’s called the Change Impact Analysis. It basically gives you a tool for which to use that – that change management framework. So, you first want to identify the process areas, processes and descriptions that are going to change. What are the roles within the organization that it impacts, with some high level description of the impact? Then maybe a prioritization rating or set of ratings to help you decide where we’re going to focus our change management resources when we’re rolling out of the system. Which processes or business rules or features will require the most level of support, either because they are very important features or because they are used by a lot of people within or outside of the organization?
What are the risks?
Another thing that I like to talk about that’s very important to roadmap development is the idea of risk assessment. They are particularly necessary for a large or complex technology project that you are planning, and a good risk management assessment thinks about all of the potential challenges or risks for the project, including the origination point or source for each risk, the probability of it occurring, the potential impact on the different aspects of the project. And it also introduces a mitigation or a response plan for each risk. Sometimes I’ve heard this actually described as premortem and that you think about all of the ways that a project could die and then you’re trying to figure out how you would have saved the body at each different point if you are going to succeed. That’s a really gruesome way to look at it, but I have heard, and you may have heard it talked about as a premortem, as well, but the better name for it is a risk assessment.
It basically says, how can we turn these potential obstacles in our project into successes? One example of a typical risks that we see is the lack of stakeholder availability that participate based on conflicting priorities or events. In this somewhat hearkens back to competing priorities thing that I mentioned a few minutes ago. And depending on the degree of the lack of availability that could have a high impact on project cost schedule and performance. A good example of how to mitigate the risk, would be to take steps to make sure that team members are freed from responsibilities, as I said before, that conflicts with the progress on the project.
This is just a quick example of a deliverable that we provided to client, just this idea that projects were launched without sufficient impact analysis to make sure that those risks of that impact were mitigated, and this is just a bird’s-eye view of a risk register. Basically, you could do this in a spreadsheet or in a document, but this is from a tool called Teamwork Projects. It really helps everybody behind the same page as, what if the vendor can’t meet the agreed upon dates in this SOW? What our contingency plan going to be for that? What if we ran into resource constraints in different areas of our teams, and so on and so forth? It gives you a way to sort of make sure that these things don’t happen by planning for working go wrong in advance.
And I’m will just say as a side note that, some organizations do tend to be unrealistically optimistic when they think about their chances of achieving a certain level of change. And one of the things that Build helps to bring to our clients in terms clarity, is when they are thinking about their technology roadmap, not just what do they want to do and from a technology standpoint or whether it’s affordable, but also the organization has the capacity to make the change necessary to use that technology effectively. And so that’s a key risk that we look for to try to mitigate upfront, primarily through those change management efforts.
Collaborative, Iterative Approach
I’m just going through a few more things here and then we’ll go to questions and answers. So, studies have shown that organizations that taken open and collaborative approach, which is focused on incremental design and implementation processes, show greater potential of success. This is most commonly referred to as an agile process; there are other terms that are given to it. And it’s a style of collaboration in projects that helps to keep all of the key stakeholders engaged through the many critical decision and review approval processes throughout a technology project, from the start of requirements discovery all the way through first implementation phases.
And as I said before when thinking about chunking out projects, it also helps break down project complexities into bite sized chunks. So, one warning is appropriate here. It is important that when a vendor is selected to help implement a new system for your organization, and that vendor uses an agile approach, that they have the ability to be flexible when working with an organization that has never or never successfully been through a true agile process. Because when you introduce a pure agile approach to an organization that unused to working in that way, it could be a major culture clash that sometimes results in projects getting bogged down or collapsing entirely.
So for agile projects, for example, it’s very important that stakeholders are frequently available to participate in design reviews user testing, sometimes on a weekly basis. But this also means to committing the necessary time on a regular basis to make business decisions with an accelerated timeframe compared to what the organization is used to. So, applying principles for agile in a way that will work truly for each organization is very important.
So, if you have a vendor that’s pinching an agile approach to you, make sure you understand what they really mean by that and how they can work with your organization’s custom approach that your organization is accustomed to, to merge something or create a solution that works for you in terms of project process. We all understand that collaborative, iterative, agile project styles are preferred for success. We want to make sure that not introduced to your organization in such a way, that’s it’s too much change at once and it doesn’t result in good outcome.
So again, this was a key finding from a client that we are working with a couple years ago. We found that staff were engaged in the process and invested in success and that was the good news that we delivered to them as a finding. But there was a challenge that there was a lack of true collaboration approach on cross-departmental initiatives. So, we need to get everybody working together collaboratively, in an iterative fashion, to try to address this problem. So that the work then didn’t continue taking places in silos and then people will pop up and butt heads periodically and then drop back down. When that’s the approach in the organization, when it’s not collaborative, when people are iteratively taking the time to work through the decisions necessary to make a good solution – when you don’t have that collaborative approach – you introduce the risk, as we noticed in the risk assessment, to the projects.
So in supportive tools, I just really want to think about, do you have the tools in place to guide your organization through the projects that’s you are going to be executing, as part of your roadmap? Where can people go to get the information that they need to participate properly, get a sense of where the projects at, whatever the need might be? And studies have shown that successful projects most frequently create a digital project collaboration environment that manages and socializes critical information related to the projects. So, I’m essentially talking about a project/knowledge management tool here.
We prefer a Teamwork Projects to tools like Basecamp, Asana, Microsoft Project, et cetera, but the key is to have a functional space, that’s universally adopted by all of the key project participants. And in which people can be on a same page in regard to milestone, tasks, agendas and notes, files, risks, and key conversations – anything that’s required for the project to be successful. And the best way to make sure a tool like this remains in active use with up-to-date information, is to use the information in the system as a live point of reference within team meetings to drive performance reporting the stakeholders.
So, you want to make sure that it’s not only one person that end up using the tool, like the Project Manager, and nobody else ever sticks their head in there. You want to make sure that it is something that’s used on a regularly ongoing basis by the entire people or at least all of the key stakeholders.
This is just a visual of a dashboard from Teamwork Projects the helps to give you an idea of where your task statuses are and this a more complicated Gantt Chart view of a project timeline. Again, you just want to make sure that you have supportive tools available to help create these sorts of organized collaborated spaces for tracking projects all the way through to fulfillment.
Professional Skills Development
Professionals skills development also very important. A lot of organizations don’t budget for or plan for professional skills development, as part of their technology roadmap. Technology project both large and small, but particularly large in complex projects, often require team members to step into roles for which they are not fully equipped. And also, just as you change technology, people’s roles change and how their roles are defined and what processes they need to follow, and what data needs to collect. So, it’s important to give special emphasis to planning, communication, teamwork, time management and change and adaptation skills from a professional development standpoint. But also, it’s important to make sure that people are trained and given the abilities to succeed with the features and the processes in the new system.
So, some new roles that might be created in the course of technology roadmap for systems implementation or replacements or enhancements of systems, we might more clearly defined a system administrative role that you’ve had before. You might have somebody need to step into a data manager type role. You might need somebody to be a trainer. You might need somebody to take on the responsibility of being the change manager of a project or projects or even a projects or technical project manager.
So, those are specific roles that might be assigned on per project or across project basis for things that are in your roadmap, but there are also those existing roles that I mentioned. So, if you are changing from Salesforce to Salesforce for development staff rather than the Raiser’s Edge, they need to have professional development to be successful in that tool, Salesforce. Same thing if you go Intacct for accounting staff rather than Dynamics Great Plains or GP and there are couple other examples on the screen hereto: Microsoft Team other than Slack, CaseWorthy rather than Sumac. You could make some correlations based on your own organization in what you are thinking about for future tools.
How is that going to change roles and responsibilities inside your organization? It’s not just going to be thing assumably where you can forklift the technology solution in and just plunk it down and see what happens. And so, make sure that there is support given for people that are going to move into new roles during those projects and then over the lifespan of the systems, what new processes, what new features are people going to have to absorb and learn how to use consistently.
Finally, I just want to spend a couple of minutes on the idea of requirements definition from both the business requirements and sort of data and technical requirements perspective, so addressing all three of those areas at once.
So, business and technical requirements need to be carefully documented and prioritized prior to engaging in a new system implementation, the replacement of an existing system, or any significant enhancement to system that’s already in place. Poor business requirements definition and technical requirement definition are one of the key reasons why technology projects fail to succeed. If the organization has a poor understanding of its current business processes and data or processes are performed inconsistently, or data quality has been poorly managed, thorough business requirements can be very difficult to develop. And poor business requirements, as I said, are a problem because they lead to projects running over budget and over schedule, and also are a leading cause in the wrong system being selected and implemented. You know, there was a better solution out there for your organizations, if it had a clearer perspective of its real business priorities and business requirements going into the selection project.
One of the reasons why we, at Build Consulting, prefer to get involved with client projects during the early assessment and the roadmap phase, is because when we first get involved in the implementation phase – when a product is already been selected and an implementation is just about to start or it’s underway – it often becomes apparent that the org will need to backup and redo some requirements definition in a more deeper and through the manner, before they can have a successful implementation. They are not really prepared to meet the vendor, when the vendor needs them to make a well informed and durable decision about a process, what they’re going to do. And when a vendor is engaged and an implementation is already moving, it can be very difficult and costly for an organization to push the pause button.
So, this is just what Build has learned from its own experience, where its best for it to enter into an engagement with the client. But it just speaks to the fact, that this kind of requirements development is not often well done by organizations or even by a software vendors. One of the things that Build does, is it tends to take a very sort of constituent journey focused approach to business requirements data and technology definition.
And people that are from marketing, our development teams or additional engagement teams or brand, have some brand experience are usually often familiar with this idea of audience identification or audience journey mapping, or basically how you would engage with the constituent across the journey that they walk with your organization. That all is part of the fundamental basis that forms Build’s works. So, I just put a sample constituent journey mapping on here for a client and volunteer journey, where there’s two roles that are basically walking a journey together, all the way from when a client is being identified by the organization, prospected, marketed to, identified, registered – they go through an intake process, et cetera, et cetera.
And then, once we start to get into the finer details of those journeys, we’re really looking at business process mapping and analysis. What’s specifically goes on with each one of these phases in the journey at a detailed level? What assets or data needs to be engaged or collected at each point? And then down to the data level, what are the data objects that you need to identify that are going to plan to the system or systems, at least in an obstruct level? So, I got example on screen here of something that’s used, called crow’s foot notation, to help identify the data relationships between major pieces of data inside of a system.
In this case, it was a loan management program for an affordable housing organization that had a loaned fund. So, they wanted to know, how the organization record needs to be related to the contact record, how that needed to be related to the projects record, how the project was related to loan and so on and so forth. And one of the reasons why it’s good to do this is because, it gives you an idea of – it gives everyone a good sense what the major data pieces are in, how they need to be connected, even if they are stored in different systems. So, may you have some of this in CRM system, some of it in an ERP system, an accounting system, some of it in the program management system, but everybody regardless is aware of the data and has an idea of how it connects. And that can help inform your technology decisions as you develop your roadmap.
So, you’ve got these business process mapping and an analysis and associated business requirements, your data relationships, sometimes to be necessary to do a data inventory and this is an example of that. So, what’s the initial collection point for the piece of data? What data object is it going into? Is there a defined form field and type? What are the values? So, this is more at the field level and process point where the data is being collected. And again, this is not system specific, this is pre-system selection in this case for this client. So, we only want to make sure that you’re thinking about once the business data and technical level of detail that we need in order to successfully approach our technology transformation efforts. What do we really need to know and how do we articulate that, to others that are internally and to others that are going to be partnering with us in these efforts?
So, our technology solutions partner like a Salesforce implementer or Blackbaud or what have you in the accounting systems space or any system type that you can think of. And again, there is an example on the screen here, again this was a technology map preparatory to developing a set of technical requirements, such as user experience, security, data storage, et cetera, that would span all of the different pieces of technology in their environment. So, you can see that they have got, Salesforce and Salesforce Communities and that integrating with host of other things, BookingBug, that’s now called Journey, Drupal, FormAssembly, Constant Contact, MySQL, as a data warehouse and so on and so forth.
So, again how are you thinking about gathering and organizing and reflecting the information that you’ll need, in order to be successful in your technology roadmaps? Really planning for the level of effort and time that it’s going to take to go through that and also what the organization has the capacity to self-perform those tasks internally, or whether you’ll need some sort of a vendor, such as Built Consulting or another party, to help you out with that. I’m going to skip pass some of these other examples here.
So, I just wanted to put the Build Information Strategy Framework back on screen here, just so that we can have it in front of us. And say that, for many organizations their obstacle to having a successful technology roadmap is not just identifying the pieces of technology that they want to replace or even what they are going to replace them with or how they are going to enhance them or what features are desired. The challenge is, that sort of undercut these projects are largely cultural and they are about those leadership and governance pieces, operational capacity, business process and data modeling and then the technology.
Yes, there are technology problems to be addressed, but as one study reported 49% of executive said the problem was related to the people organization, when there were technology problems, while 32% blamed processes and only 19% put the finger on the technology as being the problem. And I think it’s important to recognize that, while technology roadmaps are about technology, they are also about so much else. All of these other things need to be considered carefully in order for your organization to be truly success with technology at high level. And to some extent all of them need to be reflected in your technology roadmap.
So, that’s the totality of the presentation content for today. If you’d like to continue the conversation with me, you can reach out to me via email or by connecting with me through LinkedIn and you can also fill out the contact form or find our phone number on the Build Consulting website.
So, thank you for taking the time to join the presentation today. And now, I’ll see if there are any questions that you’d like to add here. So, somebody has submitted the question. A good bit of your recommendations are based on change management for existing orgs with existing tech. How would you adapt your advice for a new or fledgling organization with limited to no legacy technology and a leadership or stakeholder group that is just being defined?
Well, I think that’s a great an opportunity to get things right from the start, okay. And also, even though it’s a new organization and a new set of stakeholders, et cetera, it’s also true that everybody is going to bring to the table their own experiences from wherever they were prior. And those might be systems that they’ve used and preferred, or system is that they don’t – they have used a not preferred and different kinds of experiences that they had and formed their view. And those reviews will all need to be surfaced.
And so just because it’s a new organization or a newish, doesn’t mean that there isn’t going to be change, because all those people came from a different environment. Now, it does help to create at some sense of initiative and comradery that everybody is on the same boat. So, for example, I had a client, not too long ago, that was in this category and they had one person that was at high level in this new organization that said, we had Salesforce at our last organization. I hated it and its never Salesforce, as far as I’m concerned.
And then there is another person that said, I had Salesforce at our organization, we used it for this purpose and we really loved it. So, there’s going to be some things like that, that need to be worked through and there’s change management involved in that. So, you can still think about change management, you just need to set your baseline differently, not in terms of what we’ve already used at this specific organization before, but still have our past experiences and form what we need to do in the future. Thanks for that question, Lory, really appreciated.
Somebody asks – will we receive the copy of the presentation? I don’t usually make the slides available but, like I said, it will be available in video, on YouTube and on our website and in an mp3 format for audio listening after. We will make that available in the next couple of days and will send out an email to everybody that registered for the webinar. Thanks, Christina.
Any other questions from the audience for today? Great! Well, I hope that you’ll had some benefit from this presentation, and again I want to thank you for joining. If you have any questions, again feel free to follow up, I’ll just put my information and backup on the screen here.
And there are two resources that are freely available on the Build Consulting website that you might want to look at if you have questions in regard to this. One is our blog where we write a lot about all of the different subjects that we’ve covered in today’s conversation. And also the learning section of our website is where our recorded webinars from the past are available on this and related topics, as well as a variety of other tools and templates and diagnostic quizzes, that you can take to help either with your professional development in general or to help inform your roadmap, what goes into it or to help align leadership or stakeholders around what it takes to really put a good comprehensive roadmap together, and make sure that it leads your organization to better mission outcomes.
So, thanks again and I hope you’ll have a great rest of the day.