A downside to having so many solutions available as applications expand and systems intertwine is that it takes a tremendous amount of time to sort through them. As a manager, it’s your responsibility to be on top of cutting-edge technologies in order to make informed recommendations to senior management and intelligent directives to your reports. You can’t afford to avoid it and you can’t do it poorly. You have to preface your program plans with research, and the research must be thorough.
It’s even tougher because the IT universe is now so vast that it is nearly impossible to tackle the task alone. Even the experts on your team are undoubtedly becoming more narrowly specialized, and this doesn’t help you much when every enterprise problem or network expansion has a dozen different solutions, not just by vendor, but by design philosophy. Increasingly, research is something you must delegate. And the results require rigorous scrutiny. Here are some strategies to use to meet the challenge.
Let the users drive the research. Business fitness, by way of heavy user definition of what works, is the driving force of enterprise design solutions today. This criterion is at the core of your design effort, so why shouldn’t it drive your initial research, as well?
As an example, suppose you are looking for a low-cost, maintainable series of portal connections between your company’s satellite offices. Before delegating the research to your team members, you must give them a list of what to learn. And a user-driven list wouldn’t contain the questions, “What is WSDL, how does it work, and what does it cost?” It would contain user-focused questions, such as "Can WSDL meet the connectivity and maintenance requirements of our target user’s application, would the users find it convenient, how does it work, and what does it cost?"
Assign research by form, not content. I learned this strategy by accident, and it was a pleasant surprise. Through miscommunication in a group meeting, three different team members on a project I headed each thought they had been assigned to research each major software component of a communications and file transfer system we were implementing. I had intended that each of them take one of those components and look into it.
Instead, the Web surfer jumped on the Internet and gathered all the available information from various Web sites. The user group guru went the user group route, asking a full spread of questions in the relevant forums. And the staff member with the best phone skills called up product reps at the major software vendors and gave them the third degree.
I was the most prepared project manager in the history of IT by the time they were through. Since all team members had done their homework in the mode best suited to them, they got the best results. Since they weren’t confined to a single component, they all had a better understanding of the system we were planning to construct. And I had valuable perspective to help me find my way: vendor perspective, general reputation of the products, and user point-of-view.
The lesson here is simple: Don’t parse out research by topic. Instead, assign research to your team by their preferred method of learning, and give them as much of your list as they have time for. Become aware of who does what well, and run with that. They will come back to the table with buckets of useful knowledge, and their own awareness will have the big-picture feel you’re shooting for.
Do a second round before beginning design. There are always pleasant surprises when you sift through the offerings of the IT vendor community. You will learn about possibilities you hadn’t considered and uncover limitations you hadn’t anticipated. Armed with this knowledge, let your team do a second pass to answer a more detailed list of questions, time allowing. Then you’ll be fully prepared to think about design.
Know the results beforehand. A consequence of taking this approach in preparatory research is that your team members, having been exposed to a larger perspective, will sit down at the staff meeting armed with more complete ideas than they would with a mere "components" orientation. This is a mixed blessing; it’s great that they will have bigger and better ideas to contribute, but it will also be more time-consuming to wade through them.
The fix is simple: Be certain that every team member who’s doing legwork reports to you in full beforehand, typically by e-mail. Be sure to solicit not only the raw information that’s been gathered, but their thoughts as well. This way, you enter that first design discussion with some idea of how to sift through the brainstorming that will ensue. You can guide the discussion productively and avoid unproductive sidetracks, with enough forethought to exercise tact and appreciation.
Leave a trail of breadcrumbs. Build up a research network while you’re at it. You will certainly go down this road again and again as your company evolves and grows through partnerships with others. Your systems will become increasingly integrated, both internally and externally, and the options available to you will only grow. For this reason, it’s a good idea to instruct your team to keep notes about their sources, where they found the most useful information, and with names, URLs, phone numbers, and so on. They should keep these for their own use and should submit copies to you as well. After each project, you’ll have a complete map of where all the treasure was found, and, over time, you’ll accumulate a map room second to none, permitting you to become fast and accurate in the gathering of preproject information.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.