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

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

Part 1 | Part 2 | Part 3

RECAP & INTRODUCTION

In part 1 I covered origins and impact. In part 2, I wrote about objectives, what to expect, and described the dangers of process-driven thinking.

In part 3, we’re going to explain how to move into more concept-driven thinking. Of course, in doing so, we will again emphasize that we are not abandoning process or technical excellence. In fact, it is my contention and experience that superior conceptual understanding leads to superior technical implementation.

Repeat: This is a both/and situation, not either/or.

Big ideas we’re going to cover

  • The Role of technology
  • Moving from process-driven to concept-driven thinking
  • Contextual Understanding
  • Workflow Analysis
  • The Myth of Limitations

I realize in writing part 3 that I could have easily had this be a 5 or 6 part series. There is a lot of material and we will only touch on key concepts. Many others will remain largely un-addressed. As I’ve stated in prior articles and will again at the end, if you are interested in a copy of Chapter 22, Concept Over Process, of Building Your IT Career, contact me and I’ll send it to you.

The Role of Technology

I start with this when coaching on Concept Over Process. Understanding this does not provide a tool or methodology for analysis. Instead, it provides an attitude of understanding the end goal of technology.

I get push back from some IT professionals - particularly those who work primarily in infrastructure. This is because, I maintain that infrastructure, is critical but does not add valuable. Infrastructure is the track upon which are previous analogy (train/solution) runs.

You need it. The better/smoother it is, the more we can focus on optimizing the solutions that run on it. But the track itself does not provide a solution for the business.

In my hope to stave off hate mail, I work on infrastructure projects. They are critical. I am not, in any way, dismissing the skill or the critical nature of those skills and projects. But there is a difference between something that is critical and business value-add.

We’ll talk about this more but let’s look at some of the material from the book regarding The Role of Technology.

# BOOK EXCERPT #

The Role of Technology

Understanding why technology exists is a good starting point. After you understand that, I will move into the actual steps of the COP process.

I reduce useful technology into two simple roles, although additional subroles or subsets might exist for each role. In conversations with a number of business owners, managers, and technology professionals, however, the following roles have proven to be effective in categorizing why we use technology.

Role 1: Storage and Retrieval of Information

It’s about information. Often, the focus of technology is incorrectly placed on the technology. But the fact is that information is the commodity of value. This is the first role that technology plays.

Technology provides the storage and retrieval of information, specifically, for analysis and decision support.

Role 2: The Automation of Delivery of Product or Service

The second role that technology plays is one that you can use to greatly enhance your value and propel your career. Automating the delivery of product or service is one of the most important facets of technology.

This can, of course, take the form of automation in the traditional assembly-line type of automation. Robotics is the type of automation that is readily visible in business situations. However, what I term micro-automation is also of extreme value within a company. In addition, micro-automation is available to technologists early in their careers.

Micro-automation is the automation that takes place in the office. It can assume the form of document assembly, reporting, automated information distribution, or any other manual tasks that take place within a company.

In many cases, this type of automation receives a low priority. Company business systems, network upgrades, and big-money integration projects tend to gain the bulk of the attention. However, this type of automation can be put in place quickly, does not require the big project lead times, and has tremendous visibility for personal career growth.

Approaching technology projects with a solid understanding of these roles can help bolster your career. They produce positive exposure for your career and real value within a company.

Keeping your company’s business model in clear view as you perform your work is what COP is about. It makes you more aware of the impact that technology has and should have in the organization. Your solutions become much more proactive and more closely aligned with the business as a whole.

....

# END BOOK EXCERPT #

The above section of the book continues to explain the impact understanding the role of technology has on learning new technology, career growth, and moving into the position of trusted adviser. In fact, if your goal as an IT Professional is to move into management, this conceptual overview provides a starting point for the types of big-picture overview and leadership thinking will need to adopt.

From Process-Driven to Concept-Driven

One of the challenges IT professionals face when working to become more concept-driven is a fear of obsolescence. The perceived (and actual) value of many IT roles is in the technical aptitude at a given moment and on a given project. Those hands-on skills are what got the IT professional his job and why he is paid. Moving away from that - even conceptually - given the demands of staying current, feels almost like taking a step-back.

One of my goals with codifying the thought-process is to help create a streamlined path to concept-driven thinking. My hope is that the forward-thinking IT professional can remain technically adept and current, while simultaneously improving their business analysis skills. Again, I want a both/and, not an either/or.

In this next book excerpt, I discuss a concentric view of IT related projects as they relate to the business as a whole. It provides a map to guide bigger picture thinking.

 

# BOOK EXCERPT #

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

concept over process circles of deeper 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.

# END BOOK EXCERPT #

In the book and in future writings, I go more deeply into each of the concentric circles. And, as stated, the size of the project and the across-the-company impact of the project will dictate how deeply into each of these areas you may go.

I also warn the technologist that Concept Over Process works best, and perhaps only, if you care. Meaning, if you are apathetic about understanding a business as a whole or if you have an adversarial relationship or perspective of the business or business leadership, you are likely wasting your time.

I've always been naturally curious - beyond technology - discussing with my clients or business leadership how they got started. It isn't small talk, it helps give me insight into what is important to them and helps me catch a shared vision for where they want to take the organization.

While I could discuss in detail working through the section on congruency, incongruency, and omission, I'm going to finish with a discussion of The Myth of Limitations.

It is my belief that astute IT professionals, those who wish to be true business solution specialist, need to understand, learn to recognize, and then combat The Myth of Limitations.

# BOOK EXCERPT #

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 I.T. 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 I.T. 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 www.ITCareerToolkit.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.

# END BOOK EXCERPT #

Conclusions & Next Steps

I've touched the surface on Concept Over Process and some of the underlying principles and strategies for understanding and adopting both the mindset and methodology.

I want to make that caveat/disclaimer. I do not claim, in any way, to have invented or introduced something novel or revolutionary. IT professionals, business analyst, consultants, etc. have been providing excellent business analysis to their organizations for years.

My goal with COP is simply to codify and organize business analysis in general and some of the methods I put into play specifically. My hope is that through this organization and codifying these ideas, others can adopt them more quickly and with less trial and error.

What others have said

A few years ago a young programmer/IT pro, named Jason,  worked for me. As with anyone on my team, we discussed Concept Over Process frequently and employed the strategies on our projects. He went on to a new opportunity with a VERY large mortgage company. A few months after he started with them, his manager called me up. I'll paraphrase, but this is the tone and content of his comment to me.

"I had to reach out. Jason has immediately become one of our best developers. But more than that, his view of the big picture and ability to proactively identify solutions before the business units ask for them is excellent. He has told me about something you taught him called, 'Concept Over Process.' If that is the secret, it is something I want all of my team to adopt."

This type of feedback is not isolated to one or two incidents and in the past few months I've had several IT professionals write me to express gratitude for helping propel their career forward. In each case, they mention the value-add and solution-focused mindset I teach in my book, blog, and elsewhere.

Can Concept Over Process help you as an IT professional, business analyst, business leader? I think it can. I know it helps me and the teams I work with, create better, more business-aligned, and proactive solutions.

I'd love your feedback. Also, if you have ideas to add to the discussion, please share.

Finally, I've emailed several copies of Chapter 22, Concept Over Process, to readers the past week or so. If you are interested in getting a copy, contact me.

Posted in Consulting and tagged , .

Leave a Reply

Your email address will not be published. Required fields are marked *