I like what Brian Greene says about process and how aptly it applies to Competitive Intelligence. I want to continue pulling the thread about how systems thinking parallels performing competitive intelligence functions. There is a standard systems engineering process that we call the Systems Engineering “Vee”. It is called a “Vee” because a “V” is often used as the shape of process actions that take you from concept to results. To me I find the overall structure the same as the competitive intelligence cycle, different shapes but the same basic components. Let me show you the similarities by briefing describing each. The Systems Engineering “Vee” focuses on defining customer needs and required functionality first, then documenting requirements. Next an engineer would proceed with a design synthesis and system validation while considering the complete problem. The classic Competitive Intelligence cycle consists of seven basic steps:
- planning and direction
- collection and research
- processing and storage
- analysis and production
- dissemination and delivery
Today I just want to address the very beginning of the “Vee” there are still a lot of comparisons down the road, but I want to keep this simple (yet another CI and Systems Engineering shared principle: Keep it Simple). Whenever you start a new CI project or a systems engineering project the first steps are the same, you have to understand the needs or the gap. In CI we do this by interviewing the marketing lead and an outcome is often what we call Key Intelligence Topics (KITs). The KITs you develop help you determine the scope of the effort and then you can develop a collection plan. In systems engineering you interview your customers or project managers to determine the needs of the project and you develop a high level diagram of all the elements that will determine your scope and plan. One tool I used to capture requirements was a modeling language called Unified Modeling Language (UML). UML provides a graphic notation that captures all the elements of the requirements, it looks remarkably similar to a flow chart, but was very useful to capture the essence of what I was trying to engineer. Whether you are developing KITs or a UML model the intent is the same, define the requirement with the end in mind, which brings us to one of the systems engineering principles that I think apply just as well to Competitive Intelligence:
Start with Your Eye on the Finish Line
- You should reach consensus at the very beginning of the project on what will constitute success at the end. This means that the stakeholders should start with an agreement of what the project should accomplish and the metrics that will be used to measure the success of the project. This initial focus on the finish line must be sustained by project management as project development progresses and competing interests and project complexities begin to dominate the day-to-day work.
The next principle of systems engineering is equally important in Competitive Intelligence and that involves your end customer. One of the things we work hard at in CI work is to manage expectations. Too often those unfamiliar with what we do think you can generate good intelligence overnight. Many have the idea that the internet is like Hitchhikers Guide to the Galaxy, that has an answer to every question you could possibly ask in just seconds (from the Douglass Adams book same name). Part of the first step is to set up the right expectations when talking about the requirements KITs or Engineering goals. We don’t all have unlimited resources so we need to scope out the effort. It reminded me of a project I was working and this customer became so enamored with UML he told me that we could use this “UML” thing to define the Starship Enterprise. I mentioned to him we could do the designs but unfortunately we were still 300 years away from the technology behind it. The second principle is:
Stakeholder Involvement is Key
- Successful projects involve the customer, users, operators, and other stakeholders in the project development. Systems engineering is a systematic process that includes reviews and decision points intended to provide visibility into the process and encourage stakeholder involvement. The systems engineering process includes stakeholders through all stages of the project, from initial needs definition through system verification and acceptance. The stakeholders who are involved in any particular step will vary, providing managers, operators, and technical personnel with an opportunity to contribute to the steps in the process where their input is needed.
I like keeping my capture manager involved not only from the aspect that I can gleen a lot of intelligence from the capture team, but also to keep us all in sync on were we are with the KITs and focus on the end results. In both systems engineering projects and competitive intelligence endeavors keeping your customer in the loop on what you are doing at all times is one of the most important things you can do. I consider my KITs a sort of contract with the capture lead. When I plan out the size and scope of the effort up front it is much harder to find additional resources later if there is a major increase in expectations from the capture lead. Good Competitive Analysts are always overtasked and just try to get more time–that will never happen.
Next time I am thinking of working through more stages of the “Vee” and making comparisons on what we do in Competitive Intelligence. I have been a bit behind on moving this blog along, I never knew how much time it takes to do one, so I am taking it in smaller chunks. Yes that is another principle for another day.