Moving from Process Driven to Concept Driven
How do you move from a process-driven mindset? This can be difficult for the rank and file technologists because so much of their perceived worth is driven by their hands-on technical skills. Remember, however, that my objective with COP is long-term value and the ability to quickly adopt new technologies based on a clear understanding of their role or usefulness.
The sections that follow take you through the methodology that forms the underpinning of COP.
A Concentric View
You will find a common theme throughout this discussion of COP. In all things, I start with the broadest view possible. I am at heart a minimalist. Broad concepts typically answer many of the basic questions, and the minute details are simply tweaks, or details, that are meant to optimize the big-picture view.
Picture a series of concentric circles. COP starts on the periphery, the outermost circle, attempting to capture and see as much information as possible. It then works inward to the greater detail. Each circle is another level of analysis, until you arrive at a detailed understanding of the process or project with which you are involved.
The problem facing many of us as technologists—and truly any highly skilled professional—is a myopic focus on a particular concentric circle or process with which we work. If our starting point is too narrow, we risk losing sight of the impact that our work or project has on the organization as a whole.
Figure 21-1 illustrates the starting points for clearly putting COP to work. The starting points form the concentric circles of analysis:
- Business objective/goal ($)
- Industry analysis: trade publications/mentor
- Organization's role in its industry
- Workflow (money, information, product/service)
- Interaction/dependencies
- Congruencies, incongruencies, omissions
- Project definition
- Solution/implementation
)
Figure 21-1 COP: Concentric Circles of Analysis
A Note About Time
COP typically requires more upfront time in project definition. This was often difficult for my clients to understand. I placed a premium on the analysis at project inception. However, we found that projects ran much more smoothly and more quickly when we performed the COP analysis. In addition, projects had fewer costly mistakes and missing components—changes to be added later.
The size of the overall project dictates how far into each of these areas you should go. Certainly, if you are writing a small script or process to perform a niche function for your client, I wouldn't suggest that you spend four days in analysis. The actual project size determines the amount of detail for each segment of COP.
The COP methodology is something that you can employ as an overall client relationship process, too. Although you might not be performing workflow analysis or large system implementation, you can work at gleaning this understanding as you provide day-to-day support for your client.
Developing Proactive Solutions
A key byproduct of COP is the development of a proactive solution ideology. As you work with a client or your company and have a greater understanding of the industry, business, and operations, you begin to see where technology can best make an impact. You can intelligently suggest good technologies that fit the company's business and strategic plan.
This takes you out of the position of being a straight technologist—one who implements what the company directs you to—to becoming a solution provider—one who works with the company toward its strategic objectives.
The impact on your career is immeasurable. CEOs and management are often jaded in their view of technologists. They believe that technology departments in general and technologists specifically do a poor job of "aligning IT with business objectives"—a phrase similar to many that is creeping into formal job descriptions.
Because COP starts with business objectives as the standard and basis for all understanding, it lends itself to better business and technology alignment.
A Warning/Suggestion
Critical in adopting COP is a desire to have a true understanding of the business. If you don't really care, you will find COP to be tedious, and you will be poor at it. If your idea is to adopt COP to push your particular technology more effectively, you are missing the point.
COP Is Not About Technology!
Although COP is currently framed as a methodology for technology projects, it is just as adequate as a methodology for marketing projects, accounting projects, or manufacturing projects. COP is about clearly defining business in general and then molding your project to that business.
The particular project implementation is the process. COP is so named with reason. It is not Process Over Concept. Keep that in mind at all times!
Start with the Goal of Business
This might sound trite or simplistic, but the first idea to grasp is the goal of business—in particular, the goal of your company, client, or organization.
In his landmark book, The Goal, Eliyahu Goldratt identifies a key problem facing many companies. His book is focused on manufacturing, but the idea holds true across industries. In the book, Goldratt's protagonist is brought in to help turn around a manufacturing company. From the outset, he asks the various managers what their departments' goals are.
They answer that their goals are efficiency, higher production, fewer mistakes, and so on. He points out that if each of these goals is met and the product sells for a loss, they will have met their goal and the company will fail.
He eventually gets the managers to understand the simple concept that their organization exists to make a profit. That is the goal.
Understand Your Objective as an Employee
Your objective is also profitability. Once again, you might want to provide your services for a worthy cause and not for high personal compensation. That's okay and worthy. But if you can't eat or take care of your basic needs, you won't continue at that worthy endeavor.
What About Mission Statements?
Mission statements for companies were the craze ten years ago. Lofty statements covering ideals and ethics were created to give the corporate culture meaning as it went about its day-to-day operations.
The same is true today with individuals, and that's a good thing. Certainly, having a guiding ideal—a moral compass—that forms the underpinning of your professional and personal conduct is good.
However, as Goldratt pointed out, for many companies and individuals, the mission statement became the goal. A goal is not the same as a mission statement. The mission statement is composed of the underlying ideals with which a company works to achieve its goal of profitability. It includes the values that drive meaning into the achievement of profits.
A personal mission statement can and should be a positive guiding factor in your career development. But it is the way in which you achieve your goal, not the goal itself, that is of critical importance.
From Goal to Analysis
After you have correctly identified the goal, it is time to create the strong conceptual understanding of your particular project. COP is a holistic methodology. As such, it requires more than a simple cursory view of your project objectives. Remember: COP is meant to help you better define the project objectives. Therefore, you must start broader than the project.
A project impacts more than the systems or workflow it replaces or optimizes. A project impacts the people in ancillary departments and even outside the company. For that reason, to correctly and effectively define a project, you must see beyond the scope of the project work itself.
This is a huge point of failure or disconnect on project work in general and specifically in the technology and integration business.
Understand the Industry
The first level of understanding is the industry in which you are working. This can be healthcare, manufacturing, legal, professional services, and so on.
When a new company or new project is being defined, find out what trade journals exist for that industry. Pick up a few and read them. In addition, ask the department head, client, or prospective client for any books that might help in understanding the industry or department. Finally, simply ask this person for time to discuss the industry in general.
This serves a few different purposes. First, you will begin to adopt the language of that industry. You will be able to better speak and understand the particular terminology. Although you might never become an expert in that industry, during subsequent meetings or phone conversations, you will adopt the vernacular and win the industry's trust.
Second, you will gain a much deeper understanding of that particular department or business's position and role in the industry. The client no longer must "dumb down" its conversation about industry-specific topics. It will be comfortable in knowing that you have a grasp on the big picture.
Understand the Business: The Organization's Role in Its Industry
After you have done some research and gained knowledge of the industry, you must delve deeper into the client's business as a whole:
- What is the service or product?
- Where does the client stand from a market-share perspective and its role in the industry?
- Is the client an industry vendor—selling within its industry, or producing product or service that leaves the industry for general consumption at completion?
Then you can work to understand, as quickly as possible, the broader objectives of the company within the industry. Is the company looking at growth within its specific segment or market share? Is it planning to spread to other sectors or roles in the industry?
Because you understand the industry first, what you learn at this step will make sense. Without the industry knowledge, the business-specific knowledge is far less meaningful.
Understand the Workflow
Now you must delve into the how (process) of the company. In this step, you are looking at how the company delivers its product or service. You want to understand, from start to finish, how the company creates, markets, delivers, and ultimately pays for the product or service.
Understand the Relationships: Interactions/Dependencies
Although your project might involve a particular department, it is critical that you understand the relationships that are impacted. This includes relationships both inside and outside the company:
- Internal— Relationships within the department, between individuals, and relationships between two or more company departments.
- External— Relationships with vendors, clients, suppliers, contractors, and so on
The objective is to see the impact that even a small project might have on these groups. If you develop a project that makes life easier for a single individual or department but hinders access to key information or makes processes more difficult for a related department, others will view the project broadly as a failure. You don't want to have 3 people pleased for a short time, while alienating 100 others. That's an irresponsible career move.
Workflow Analysis
To understand these workflow and relationship issues, you need to analyze some key items. Each item lends greater understanding to the previously discussed areas of COP—the concentric circles of analysis:
- Follow the flow of money— I mentioned this in passing earlier. However, because our stated objective is profitability, the flow of money provides a good way to analyze how a company works.The flow of money is twofold—it includes money that the company makes and money that the company pays out.
- Follow the flow of data— How do the company's information systems currently track their product or service? How and where does information from all sources get stored, retrieved, and analyzed?If you remember that the storage and retrieval of information is one of the two roles of technology, you will understand the importance of this step of the process.
-
Follow the flow of production— From raw product to finished product, from information to service delivery, whatever the company does to ultimately produce income is where you start.
I'm not claiming that you will understand each person's role or step in the process. But you must understand in general how the company produces its revenue.
This moves from the company perspective to the particular product or service that a department or an individual provides. You will be able to see, for your particular project, the impact on the company as a whole.
- Find the incongruent or problematic pieces— The overall value of the previous analysis is the ability to locate those areas that create a disconnect. If, during the storage of information, all data is stored in a centralized database, except for customer service requests, you might have discovered incongruence.
Project Definition
With an understanding of workflow analysis in place, you are ready to more clearly define your project. COP is largely a creative/analytical process. It is not purely analytical. In fact, broad concepts tend to be big picture/creative items. They involve sharing and developing the "vision" of company leadership. As you delve further into the analysis of the particulars, you are moving to the analytical side of things.
Project definition is also not rote analysis—it is largely creative and innovative. Project management as a process is often solely a process-driven/analytical exercise. COP attempts to meld the creative/innovative process with the analytical steps of project management.
Myth of Limitation
As project development begins to take place, it is critical that you, as a technologist, understand and remove the myth of limitation.
The myth of limitation is most often seen when a company or department's nontechnical staff approaches its IT provider (either internal or external) and asks for a particular technology:
"We need an Access database to track customer service requests."
"We need X product installed on each system."
The requestor might be correct in the stated need. However, you'll often discover that the requester is only partially correct. He will have come to IT defining the technology, not the business process to be solved.
A company might need a database to track customer service requests. But what about other department access to the information? What type of request? What is the objective of this data? How will it be used, and are there other desired customer service functions it should track or be able to respond to?
The myth of limitation is the partial understanding by nontechnical staff of what is available. In many cases, departments have heard of a technology being put in place at a similar operation. An identified benefit might exist; however, more comprehensive solutions might be achieved at just a little more cost.
Removing the myth of limitation involves a what-if mindset.
What If?
In meetings with clients, I often frame my question this way:
"If time, resources, and money were no object, how would you like things to work?"
It might be that clients' requests become too outlandish or expensive to implement. But it is just as likely that when properly defined, technologies are available to meet a good portion of clients' needs with little to no impact on costs.
Whether the broader solution is possible or not cannot even be discussed unless you remove the myth of limitation.
To be able to do this, you need to be able to speak and understand the clients' language. I cover this in more detail in my article "Why Technologists Must Learn to Speak Business." You can download a copy from http://www.cbtoolkit.com.
By speaking in clients' business vernacular, you make them more comfortable to approach you as a peer in business, not the technology pro. Although you want to be the technology pro, you first must understand the clients' business need. Remember: Technology is just a tool used to provide that need.
Congruencies, Incongruencies, and Omissions
As you move further into project definition and your solution, the following steps become the standard for identifying and clarifying the solution. You will use them over and over again for each project step and to analyze project changes.
Congruencies: What Currently Works
Quite simply, what technologies are in place and what workflows currently work well with the individual, department, related departments, and external relationships? Does the technology in place and workflow work in unison?
Incongruencies: What Currently Does Not Work
Is there currently a discrepancy in technology and workflow? Is it technology related (bad product or information), or is it workflow related (how the client goes about its operations)? Is it both? How can the incongruency be addressed or solved? Are tools in place to help with this?
Omissions: What Is Currently Excluded or Not Addressed at All
What does the client not track, automate, or perform as part of its operation? This aspect is a little trickier to identify. It often involves information not being tracked in relation to a current workflow process or automation. The information might be available but not used. Often, these discrepancies are because of a status quo ("We've always done it this way") mentality.