By George Woods, Senior Director of Program Management Operations
Architecting an enterprise-level IT solution is no small task. But the key to a successful implementation doesn’t start with the solution. It starts with the blueprint — a critical first step that brings the business into conversation with the technology to chart a strategic path forward.
Why You Need a Blueprint
Like a blueprint for a building, a schematic for a piece of machinery or a map for a road trip, an IT blueprint provides necessary direction for organizations looking to overhaul or enhance their existing IT environments. Ideally, it helps define where you are today and identifies where you hope to arrive in the future.
The blueprint is also the first place where IT and business processes meet. In many organizations, technology and business processes are separate conversations. But when it’s done properly, the blueprinting process brings them together to addresses the solution in light of the organization’s technology and business needs.
Too often, organizations bypass blueprinting to expedite or reduce costs associated with solutions implementations. Rather than investing time and resources in upfront planning, these organizations simply assemble technology requirements, then quickly move to build and implement the solution.
Although eliminating the blueprint can initially speed up the process, it causes delays and added costs later in the project. Without a well-defined path that has been informed by IT and business perspectives, it is difficult — if not impossible — to uncover efficiencies, identify gaps, or forecast issues that can arise in the later stages of the project.
The Blueprinting Process
Successful blueprinting requires participation from players across the organization including subject matter experts (SMEs), the business leadership team, and system/IT experts. Just as importantly, it also requires a fresh set of eyes from outside the organization — qualified experts who are not invested in current processes and can bring new ideas and industry best practices to the conversation.
After the appropriate players have been identified, the blueprinting process typically involves three key elements or groupings of information:
- As-Is Analysis— The first step of the blueprinting process is designed to provide clarity about how the business operates today and current supporting systems functions. At this stage of the process, SMEs and IT experts play an important role in as-is process mapping and the validation of assumptions about the existing state of technology and business processes.
- To-Be Determination— In conversation with the business leadership team, external experts and system/IT experts articulate the strategic goals and direction of the project. The input or sign-off of executives and high-level leadership may be required at this point because you have to make decisions about future state, desired business and technology outcomes, and organizational change.
- In-Depth Planning— In the last stage of the blueprinting process, external experts guide stakeholders through a process of identifying the gaps, actions and transformations that must be addressed to arrive at the to-be state. This includes organizational and process changes as well as specific IT changes. The actions identified during this stage are informed by industry best practices and the outcomes of similar projects in other organizations.
The end product of an effective blueprinting process is a document that provides a roadmap for building and implementing the solution. But the blueprinting process is never truly finished — blueprints are living documents that should be updated and revalidated as you move through the project and further lifecycle of the solution.
Tips for a Successful Blueprint
At Managed Maintenance, we help organizations navigate the blueprinting process for enterprise-level contract, billing, and quoting solutions. Our work as a strategic advisor has uncovered several best practices for developing blueprints.
- Secure buy-in from key players. Effective blueprinting demands the participation of multiple business and IT stakeholders. If IT is pushing for the solution and business leaders are lukewarm about the idea (or vice versa), it can create challenges when it comes to validating the current state and identifying a to-be state that works for both the business and IT.
- Don’t rush the as-is analysis stage. One of the biggest mistakes organizations make is to skip or rush as-is analysis. Resist the temptation to start with a clean slate. By thoroughly documenting existing processes, discussing current pain points, and understanding why things are done a certain way, you can uncover details that will improve the process and deliver better results in the long run.
- Get an outside perspective. External experts force key players to move beyond a “that’s the way we’ve always done it” mindset. Often, the presence of a strategic partner creates opportunities to consider solutions and process changes that would not have arisen if you had relied solely on the perspectives of internal stakeholders.
Ultimately, a carefully constructed blueprint can be an insurance policy against a failed IT deployment. Although the blueprint document offers a useful guide for architecture and implementation, the most valuable part of the blueprinting process may be that it requires the organization to take a closer look at the obstacles and opportunities the technology presents not only to IT, but the entire business.