Concept Over Process: A Formal Project Methodology – Part 2 of 3

AKA: How to build better technology solutions for your organization.

Part 1 | Part 2 | Part 3


In my last article I discussed the origins, impact, and initial premise for Concept Over Process. Today, I want to cover what to expect as you learn more about COP, the objectives of COP, and we’ll delve into the process-driven mindset and the danger’s it presents.

I’ll include excerpts from the book and provide some additional commentary on those sections.

When working with IT leadership and their staff, this is one of the critical elements of my coaching/mentoring.


What to Expect

COP is largely conceptual in nature. It is the intellectual precursor to a variety of task-oriented processes. Certainly for the technologist, it is a critical step in helping to define tangible solutions.

You can expect (as you adopt a COP mindset and approach) to think differently about your projects. You will find that you become largely agnostic about which technology or process is critical and more focused and interested in the overall business objectives and project impact.

What Not to Expect

COP is not project management. Although COP is a component that is often missing from the project management cycle, it does not involve measurement and tracking per se. It is an ancillary skill and tool to ensure that a project is more closely aligned with actual business objectives.

Highly organized and technical individuals often provide project management. However, innovation and solutions are often abstract concepts that require a more creative, almost artistic mindset. Both ideals are critical in creating true solutions:

  • Highly analytical, process-driven detail
  • Creative/innovative thought

These two ideals are often viewed as two competing forces in the project. The creative individual might be part of the project team and provide tangential input. Or the creative input comes from management in the form of vision and a big-picture perspective.

COP provides the basis for highly technical project managers and technologists to have a greater understanding and ability to provide the creative direction and input. The primary objective of COP is to ensure that projects of all types are more closely aligned to the business and its objectives.


COP and Project Definition

Often clients want to know if I can help them bring the project in closer to budget and close to the original time frame. They can be dismayed when I often push back on that idea, instead suggesting that we need to first ensure that we have the correct project.

At this point, I may revisit the analogy I ended Part #1 with. Again, if the train is hurtling towards a broken track (a poorly defined project), bringing the project in at all may be disastrous.

In some cases, there can be push-back, either because some stakeholder is emotionally vested in the current project as defined or because the organization simply does not want to go through the necessary pain of better project definition. Even when clear challenges have been identified, there is a mindset that we’ve already spent X time and money, we need to see this through.

This example of the sunk cost bias can be problematic to overcome. Rather than placing value on the “right” project, value is placed on the time and money spent on the current project - whether right or wrong. I’ve seen this during software implementations where the new software simply does not and will never adequately deliver the desired or necessary features.

The result is years is dissatisfaction, less than optimal operations, and, in fact, costs and time spent building ancillary systems around the original software’s deficits.

Let’s look at another excerpt. The Objectives of Concept Over Process


COP Objectives

The objectives and results of COP are as follows:

  • More solid project development (pre-project planning)
  • A stronger grasp of a particular business model in as short a time as possible
  • More accurate and meaningful project analysis during a project life cycle
  • Greater focus on a project’s final impact versus mid-project tasks and milestones
  • Greater innovation in thought and technical implementation
  • Proper relegation of technology as a tool used to achieve carefully defined business objectives
  • Greater breadth of knowledge and learning capacity as a result of reducing technology and tasks to their most common elements


It isn’t that any of these items, in isolation is earth-shattering. One of my goals of codifying COP was to establish a broad set of objectives that, when adopted as a whole, produce project that have a far-greater chance of achieving true and comprehensive business success.

More than that, it is my contention that when adopted as an IT departmental strategy, that Concept Over Process fosters a mindset in the IT staff that helps them listen to and hear the needs of the business units they serve. The individual and the department become better technologists and much sought-after business to IT alignment is a natural byproduct.

It combats something I refer to as the Process-Driven Mindset.

Let’s look at another book excerpt.


What is a Process-Driven Mindset?

Technology professionals put an incredible amount of time and energy into understanding the how-to of technology. They understand methods. They perfect the process-driven tasks that make their technology implementations optimal.

However, technologists are far less interested and often do not understand the why of technology—what the technology is for. By that, I don’t mean the tasks that a given technology performs. Once again, that is the process.

What technologists overlook is a comprehensive understanding of the business challenge—the business model, how it makes money, what products or services it produces, the interrelationship among vendors, departments, clients, and so on. These were the items that were of utmost importance to me and to my boss.

Technology, when understood in this context, is simply a tool to achieve some optimization of an already existing or developing business model. The technology is not the business; in fact, technology is the wrong area of focus for developing good technical solutions.

Before you read any further, I need to make a disclaimer: I am not implying that technical skills are unimportant. In fact, the contrary is true. However, I am convinced that understanding the underlying reasons (business reasons) for technology will lead to far greater technical skill.

A simple example of this is the initial exercise that nearly every programmer goes through when exposed to a new language. Programming books universally give a short tutorial that when completed presents a message box to the screen that says “Hello World!”

Although this exercise exposes the programmer to the language and development interface, it does little to actually develop the programmer’s skills in the language. Expertise comes through the application of these skills in solving some business challenge.

However, COP goes beyond a cursory understanding of the business challenge in isolation. To fully understand COP’s benefit and impact, you need to have a more complete understanding of business in general, the industry in which you are working, the specific entity for which you work, and the various relationships leading to your solutions.

If you are a technology professional, an understanding of how you approach technology, an understanding of the role of technology, and adopting strategies that further technology’s role in your organization make you much more valuable. Increased personal value ultimately equates to increased responsibility and pay.

The ideas that are discussed in the sections that follow are meant to foster this understanding. They are meant to provide you with tangible ways to change the manner in which you think about business, your company, your role as a technologist, and your understanding of what technology is and its impact on commerce.


I am not subject to much in the way of hate mail but the closest I get with some technologists is driven by this section. It should be noted that I protest from within. I’m not an HR theorist about my approach to Information Technology and the projects I work on. To this day, I implement actual technology. I develop solutions, etc.

And I am passionate about helping IT professional provide better, more comprehensive solutions.

If you find that the above section bothers you, stop and consider why? Is there a chance you hyper-focus on technology skills and the process to put them in place while overlooking the business? Do you find yourself in an adversarial position with business management? With users?

Several years ago I was speaking to a group of IT professionals. The topic, “The Value-added Technologist” addresses proactive career strategies and touches on Concept Over Process.

At the end of my presentation one of the attendees raised his hand and said, “What if the problem is with management?” He went on to explain that he had worked for several different organizations and in each one management was clueless about technology and did not value what he did. There was a significant attitude behind his statements - and not a good one.

Consider that for a moment.

I cannot speak to his individual situation. I could be that every company he works for just happens to have very poor management.

But I am reminded of something I was told years about about personal responsibility.

“If you run into an a**hole in the morning, you may have run into an a**hole. If you run into a**holes all day, you may be the a**hole.”

I hope that Concept Over Process pushes greater responsibility on the IT professional. I hope it forces you to consider how you think about and approach users, management, and the business.

Not because there isn’t responsibility with business management in creating greater understanding between business leadership and IT but because, I’m writing to you. At whatever level you are at. You can be the catalyst for better communication and understanding. This, in turn, makes you a better business solutions specialist; a better technologist.


In the next section, I’ll be discussing The Role of Technology and how to move from a Process-Driven to a Concept-Driven Mindset. I’ll address some of the specific tools and strategies I use and teach to help create better project understanding and superior technical implementations.

Once again, if you are impatient and want Chapter 22: Concept Over Process, from Building Your IT Career, contact me.

Posted in Consulting and tagged , , .

Leave a Reply

Your email address will not be published.