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.