We tend to treat new technology like the Holy Grail, a beacon of light, and the answer to all that is slow, inefficient, and old. And it can be—if it’s implemented with a truckload of planning and foresight.
But, well, we all know how that goes.
During my years in government, where it sometimes felt like we were playing a game of technological catch-up impossible to win, I learned what can happen when this foresight is taken for granted. It looks a little less like the Holy Grail and a lot more like cost overruns, delays, and convoluted solutions to otherwise simple problems.
As I learned, one of the major keys to a successful technology project is the harmonious relationship between the business team and the technology team. In my experience, the business team was often driving the change (we need a more complex system to track federal grant spending, for example), but we couldn’t accomplish a smidgeon of progress without the developers and IT project managers capable of making it happen. Projects often ended up a far cry from harmonious, a result of essentially speaking different languages and maintaining vastly different expectations (a change that seemed minor to me, for example, often turned out to be major for the developers).
But business and technology can—and must—be friends. The good news? Achieving harmony really isn’t so complicated. Like any collaboration, it has to do with the frequency and quality of communication, a mutually agreed-upon set of goals, and a plan for handling the near inevitable shifting of those goals. Here are a few basic guidelines to manage the business-technology divide.
1. Aim to Nail the Requirements the First Time
Think of business requirements as a blueprint. You wouldn’t draw a sketchy set of blueprints for a house, deliver them to the contractor, and wish him luck. You wouldn’t come back three weeks into construction and ask him to add a third floor and a fourth bathroom, and maybe a bay window in the living room. And you certainly wouldn’t draw your blueprints without the input of an architect and an engineer.
A technology project is not so different. It needs to be designed with precision, and once the developing begins, it’s not always easy to accommodate changes without affecting the entire foundation. This is why it’s crucial to be as comprehensive as possible from the beginning and get the input and expertise you need as you think through what the solution will require. Interview end users to understand the challenges they face and exactly how they’ll need to use the new technology. Don’t make assumptions, and don’t leave any parts of the planning for later.
2. But Recognize That You’ll Miss a Few
That said, I found it nearly impossible to envision every single feature we needed during the abstract planning stages. Inevitably, once the system was in development, we’d realize that we forgot to ask for an advanced search function or a “save and continue” button. When we approached the developers to kindly ask them to accommodate these new requests, we were often met with frustration. Perhaps the new change would require them to undo work they’d already done and re-architect parts of the solution. Perhaps we envisioned it taking two hours when in fact it would take a day.
You may not be able to prevent these later-in-the-game revelations, so the best thing you can do is build in a buffer to accommodate them. Add an extra week to your initial timeline and an extra 5-10% to your budget. Many organizations, recognizing how often expectations change, have adopted an agile approach to development, rolling out technology in phases to allow for periodic reevaluation. Whatever your approach, don’t make the mistake of thinking you’ve thought of everything from the get-go. It almost never happens.
3. Know Scope Creep When You See It
As the project moves forward and new needs come to light, it’s important to distinguish between the ones you truly need and the ones you merely want. Asking your developers to accommodate every bell and whistle the mind can dream up typically leads to never-ending projects and overly complex end results. Each new request, before it is made, should be prioritized.
When you’re considering a feature, ask yourself some basic questions: Will the system work without it? How much time will it take to implement, and how much benefit will ultimately be delivered to the end user? If we wait until a future release to address it, will anything be lost? It’s an exercise of prioritization, and everything can be assigned a status of high, medium, or low. If it’s low, put it in a figurative parking lot—I’ve heard of companies having “dream development request” documents that anyone can add ideas to and the engineers can browse at their leisure. It can always be revisited as part of a batch of enhancements to be made once the project is off the ground and running successfully.
4. Develop a Common Language
Any new system has a set of business goals at its core. It will allow you to capture more data, streamline an existing process, or offer new services to your customers. It’s critical that the business team and the technology team sit down before any work has begun and communicate these goals. The business goals must not become lost in a sea of tech-talk, and they must remain firmly in mind during each phase of work.
Developing a common language means not just collective goal-setting, but tracking progress in a way that works for everyone. Business and technology may use different tools to measure their work, but there needs to be at least one view into progress that is shared. This could be as simple as a project plan or a spreadsheet with agreed-upon fields, like dates and goals and percent complete, so everyone has access to the status of each task to be completed. The goal is to avoid a situation in which the business team thinks they’re halfway there and the tech team says they’re just a quarter—everyone should have the same understanding of what’s been done and what’s left to do.
You may speak in business plans and PowerPoints, and they may speak in code, but unless you communicate clearly from the get-go, you’ll never make it out of Babel. A successful technology project is about a meeting of the minds—not just at the beginning, but at every step along the way. Acknowledge your assumptions and try not to make too many. The smaller the divide between business and technology, the easier it will be to cross your bridges together.