The conventional wisdom is that the only person who can help with a problem is the person who has experience in the specific product, development tool, or architecture that is being used. While this may be correct for some projects, it’s not necessarily true for all projects.
In this article, we show you how experience can be broken down into five areas: Industry, Department, Technology, Learning, and Product. We also show you that sometimes the best solution for your problem may be someone with the right industry or technology expertise more than expertise with the specific product selected.
Each industry has its own way of doing things. If you’ve worked in multiple industries in the same role, you know that each industry has its own way of doing things. If you work on a project to save invoices in a utility industry, it will be very different than the same kind of project in the retail industry. In the utility industry, all bills usually are created from a central location. They are, generally, statements of activity over the preceding month and they are often created by a staff that is almost solely focused on their creation. They are usually paid within 30 days of being issued.
In the retail industry, invoices are generated at the points of sale, which may be spread across states. They are created and generally paid at the same time while the customer is in front of the cashier. They are generally created by a staff whose first responsibility is not creating invoices—their first responsibility is taking care of the customer.
If you had experience only in the utility industry and you were asked to create an invoice creation program for the retail industry, it would take time to adjust your perceptions so that you could build a program that would work for the retail environment.
Industry experience used to be very important when managers were looking for additional assistance, but over the last 15 years or so it’s been given less emphasis. While some variety is good, it often takes longer to learn the industry specifics than it does to complete the entire project.
Every department behaves differently, with different motivators and different key processes. No one would disagree that a sales department is different than an accounting department. The sales department is driven by the ability to take in sales orders from customers and keep them happy. An accounting department is more focused on keeping transactions flowing and keeping track of everything. While they both have processes that they use to make their work happen, the focus and drivers are substantially different from one to another.
For instance, implementing a technology for a sales department might be most focused on ease of entry to the system. In other words, how does the sales staff enter orders into the system with the least amount of effort? However, an accounting department might be more focused on accuracy and ensuring that the information is correctly accounted for 100% of the time.
With experience in a particular kind of department, you can work in alignment with the departmental objectives. It is quicker and easier to build solutions when you know what the critical success factors are, including the specific critical success factors for the department.
Another part of departmental experience is knowing what the primary processes are that happen within that department so it becomes possible to anticipate problems. For instance, an accounting department probably has a process for accounts payable, a separate process for accounts receivable, and in some cases special processes for cash management and closing books. Knowing about these processes allows you to work in ways that are compatible with all of these different processes that have to operate simultaneously in the department.
The old quote “There is no new thing under the sun” (Ecclesiastes) isn’t entirely true when it comes to technologies. However, it is certainly more true than false. Although there are certainly revolutionary new technologies and techniques, most of the technologies that are implanted are not completely new and unique.
An e-mail system is an e-mail system. An imaging system is an imaging system. A LAN is a LAN, and so on. Even though each product has its own unique features and perspective on the technology, they are all fundamentally the same.
There is value in having experience with multiple products within a technology because it allows you to approach the problem from multiple perspectives and choose the perspective that best fits the need.
This is much like learning the core concepts of programming. Although Visual C++ may be the right solution for some situations, it may not be best for a particular situation. If you know both Visual Basic and Visual C++, you’ll be able to decide accurately which is best. Both are programming “technologies,” but each has its own strengths and weaknesses.
Learning is a natural behavior that most animals, including human beings, exhibit at one level or another. Even though learning is a natural process, it’s also a skill that can be developed. Techniques and approaches to learning are developed over time, particularly in people who are lifelong learners. These people get a thrill out of learning—any kind of learning.
They’re the kind of people who’ve learned how to scuba dive or fly a plane. They crave learning. They are always seeking to better themselves and, as a result, they’ve developed techniques for doing it quickly.
Another way to identify experience with learning is to look for someone who has a diverse set of skills. It generally indicates that they like learning and like finding new things. This is particularly valuable when you have new technologies or products that it may be difficult or impossible to find people with experience with.
Product experience is the kind of experience that most people think of when they think of experience. They think about someone who has experience with Microsoft SQL Server 2000, or Oracle 9i, or some other specific product. As with other kinds of experience, experience with a product makes a better fit. It allows a resource coming in to quickly adapt to an environment because only the environment specific items need to be learned.
However, product experience has the problem that it can be very short lived. Experience with Windows 2000 has less value when Windows XP, which was essentially a version upgrade, is released. In some cases, the differences between product versions are trivial—such as the move from Office 97 to Office 2000—but even in small changes the value of the experience is diminished when a new version comes out.
In this way, product experience is temporal and more difficult to find. It is like finding flowers that are in season. You have only a limited amount of time that the experience is valid, so finding it is more difficult.
Although product experience is preferable, it may not be the be-all-end-all solution that some people make it out to be. It is just one component of experience that may help solve the problem. For instance, why is it that employees or consultants who are just out of college are of lesser value when building an application than a programmer with five years experience, even if the person just out of college knows the product better? The other kinds of experience are an important part of the mix.
Which Experience Is the Best?
One of the questions that typically springs to mind is, that if there are so many types of experience, which is the most important? The answer depends upon the situation that you’re in. In some cases, particularly short, clearly defined projects, it’s most important for someone to have product experience. In other situations where the problem being solved is an industry-specific problem or one with an industry-specific spin on the problem, it may be most appropriate to have a person with strong industry experience and little or no product experience.
The best mix of experience is the one that will need the least amount of time to come up to speed on what it is that you’re doing. Every person you bring in to help will have some sort of a learning curve that they will need to get over. It’s a matter of managing the learning curve so that it has the least impact on the overall time and costs for the project.
One good example of this is when an employee leaves a company and comes back as a consultant. The employee who left has a great deal of specific knowledge and experience with the organization even if they don’t know the product or technology. If they can learn the product or technology quickly enough, it makes sense to bring them back to work on a new product or technology.
When to Look for Product Experience First
As mentioned above, there are times when looking for product experience is important. Those cases are when you have a reasonable expectation of finding the product experience that directly matches the problem. It’s also important that the situation be clearly defined. In other words, it can’t require a great deal of industry, department, or technology background that the candidate with product experience may not have.
Finally, you may want to consider that product knowledge is generally the easiest to get—particularly if the candidate has experience with the technology. The longer the project is, the less likely it is that product experience should be your primary factor.
The longer the project is, the more likely it is that it will not be clearly defined—or that the candidate that you select will be asked to do things outside of the initial scope. The more they expand from a single product focus, the more likely that it is that industry experience or departmental experience will be important. These kinds of experience are generally developed over much longer periods of time than required for product experience.
When to Look for Industry or Technology Experience First
Sometimes, the project that you need help with is something that isn’t clearly defined yet, or something that you know will be a long term initiative more than a quick one-product-focused assistance. In these cases, you may want to see candidates who have experience with either the industry or the technology involved.
The value of consultants is sometimes their different perspectives on the problems that the organization is facing. Whether the perspective is because the consultant has seen the same problem at another organization or has seen how other industries implement a technology, the value is the different perspective being brought to the problem.
Unlike product knowledge that can be developed fairly quickly, both industry and technology knowledge are developed over a significantly longer period of time. Whereas a product might be mastered in six months, an industry may take 10-20 years to develop experience with. Technologies may take less time, but still more than the time of learning a single product.
Broadening Your Horizons
The initial thought for most professionals when confronted with a problem that they don’t have a solution for is to look for a person who can fill the precise need that they’ve run into. The trick is to develop an awareness that it may make sense to take a step back and evaluate how to find the best person for the overall problem, rather than trying to find a solution to the exact problem that you’re seeing now.
Evaluating the global problem as well as the immediate problem allows you to evaluate how clearly you can define the help that you need, and to better understand how much assistance you may need over the entire length of the overall project or initiative.
Good luck on figuring out what experience is most important for your next project.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.