The Industry Promise
Large Federal agencies are challenged every day to achieve their mission under the mantras of “do more with less” and “work smarter, not harder.” The prevailing sentiment is that “technology is a force multiplier” in the ongoing effort to reduce cost, “improve operational efficiencies” and to “enhance the customer experience,” (internal or external) all wrapped with a very neat security “bow.” Unified communications, contact center, collaboration, virtualization, security, “the cloud:” the promise of conquering any and all challenges with complex, next generation solutions is alluring, and there is no shortage of solution providers lining up for their share of the every dwindling IT budget.
The Industry Truth
The reality is that every organization is at a different point in their technology adoption lifecycle. Dependencies are complex and often difficult to identify. Risk Assessments and ROI Calculations quickly fall prey to “scope creep” and unforeseen pitfalls. It does not take long for the promise of new, evolutionary technology to become partial deployments and an endless cycle of upgrades. Everyone has a roadmap, but no one has a crystal ball. Surely, there is a way forward…
The Bumps in the Road
The first step in any solution selection process is to create Business Requirements. Often, the value of properly defined business requirements is undermined by a lack of defined process, competition for budget dollars between IT projects and the inability to reach across political boundaries to create a complete view of what is going on. There are 3 questions that must be asked and answered prior to proceeding with any complex solution: what do I HAVE, what do I NEED, and what do I WANT? How you approach answering those questions will have a direct impact on the success (or failure) of whatever you choose to implement.
The Path to Enlightenment Discovery: (What do I have?)
This has traditionally been where, time after time, large agencies fail in their attempts to implement new technology. Information Technology, by its very nature, implies complexity and interdependencies. A clearly defined discovery process, with clearly defined deliverables, will help to ensure success.
Common miss-steps in the Discovery process
- Not including ALL of the stakeholders in the process (don’t forget the users!)
- Prioritizing technical details over operational details
- Myopia: (staying in your swim lane when you need to build a pool.)
- No clearly defined deliverables from the process: establishing baseline “as built” documentation for systems AND processes will yield dividends well into the future.
A Note on “stakeholder selection:”
Stakeholder selection and involvement can be a tricky business. A critical, recurring mistake, however, is the inability or unwillingness of one group or department to include other departments in the process. Ideally, your organization has some form of “IT stakeholder” organization where almost all of the initiatives are on the table. If not, now is a good time to create one. Competition between departments in an organization, whether it be personal, professional or merely for budget dollars, is often cited as an excuse to limit information flow between stakeholders. Over time, the benefits of collaboration always outweigh the risks, and the most common benefit is often FOUND MONEY. This helps everyone in the room.
There are a number of “tried and true” techniques to facilitate the discovery process. One of the most successful, when properly managed, is a “brain storming session.” The way to kick off any brainstorming session is to ask the following questions:
- What do you like about the system(s) today
- What do you dislike about the system(s) today
- What do you WISH the system could do?
A True brain storming session means that any and all answers are recorded, regardless of how irrelevant or trivial in nature. A simple example of this:
“Every time my phone rings, I wish it would brew me a cup of coffee…”
It may be interesting to note that the technology exists to enable this today, however; that is not really the point. That comment specifically raises the topic: “what happens when the phone rings.” It serves multiple purposes:
- Have I captured what happens when the phones ring now? (dial plan, ring groups, forwarding, distinctive ring, etc.) in my discovery process?
- Do I need to replicate this functionality exactly, or is there a different, more cost effective or creative way to solve that problem?
Regardless of whether you are in the market for a Unified Communications system or a new security appliance, this type of discussion can help you to create a more complete set of requirements, which in turn will lead to a more complete design.
Operational Design: (What do I need?)
Once you have established a clear picture of what your IT ecosystem looks like and you have identified the direct dependencies beyond your control, you can set to the task of creating Business Requirements. Business requirements beget Operational Requirements, and Operational Requirements beget Technical Requirements. Note: this is not the SOLUTION DESIGN stage…this is the SYSTEM DESIGN stage. Until you know what you need, you will not know what you want. The most common mistake in the design of any large, complex solution is the lack of clearly defined business and operational requirements.
Other common missteps in the system requirements design process:
- Demanding (or expecting)100% duplication of existing features and functionality:
Technology can be an enabler, but so many organizations insist on replicating what they have, they fail to see what the possibilities are.
- Attempting to replace everything at once
- Creating a dependency on a single technology or vendor
- Not including the stakeholders from the discovery process in the system design process
Without properly defined requirements, most complex projects are doomed. The cost to remediate any newly discovered requirement is directly proportional to how far along a project is when it is discovered.
Solution Evaluation: (What do I want?)
While all organizations have some form of new system evaluation process, it is rarely complete or well documented. Requests for Information, a common tool in the Federal Government, are often developed in a silo and rarely incorporate sufficient feedback or requirements from the discovery and design process. Even worse: sometimes agencies, in their zeal for remediation, send out a solicitation for pricing or a solution without having seriously established their requirements. This virtually guarantees a system that neither meets your requirements nor is feasible to deploy in your environment. RFI’s can be a valuable tool, but this process is fraught with pitfalls.
Common mis-steps in the RFI process:
- Writing the solicitation to a limited or incomplete set of requirements
- Allowing an OEM to draft technical requirements (solution agnosticism)
- Not reaching out to your peers in the industry
- Forgetting to include or deliberately obviating operational requirements in the RFI.
Writing an RFI to a set of Technical Requirements that has been derived from clearly defined Business and Operational requirements will ensure you are asking the right questions.
Due Diligence: necessary, exhausting and dangerous. The phrase “paralysis by analysis” is more than just a catch-phrase. Once you have solicited solution responses from the industry, HOW you evaluate your options is the most critical component. Those lists of business, operational and technical requirements are now the baseline of your evaluation process.
Without a defined list of weighted criteria, the evaluation of any solution set is at risk of being inaccurate or, even irrelevant. Having clearly defined what you MUST have versus what you would LIKE to have in the discovery and design process will ensure your success in this phase.
As part of the evaluation process, it is important to perform, for each solution, a Cost Benefit Analysis and a Risk Assessment. There are a plethora of tools available to enable these tasks, and many of them are free. How you evaluate risk will establish your tolerance for budget and project plan activities.
Consistency is the hallmark of the application of any process: once you choose a methodology or framework, it is imperative that you do not deviate from the process. Shortcuts rarely yield beneficial results: discovery, design and evaluation of any solution are required steps to ensuring a successful technology implementation. Scope, while not irrelevant, becomes merely a gating factor for schedule and cost, rather than the dominant characteristic of the project.
You Don’t Have to Do It Alone
To learn more about how to begin your journey to the cloud, check out our UCaaS page.