Tag Archives: complexity

Uncertainty in the Project

“Let’s look at some of the specific decisions that you have to make today that will have impact later in the project?” I said.

Taylor sat back. “Okay. Let’s just look at the buy out,” he started. “In the buy out, I have to purchase some large pieces of equipment that will be installed. I have to work with our project managers and also with our purchasing guy. Here are some of my decisions that I have to make today, but it may be months before we find out if it was the right decision.

“Will the price of this equipment (to be installed) go up or go down. If I make a commitment now and the price goes up, I am a hero. If I wait to make the purchase and the price goes up, I am a goat.

“Will the vendor that supplies the equipment still be in business a year from now. I may have to put down some deposit money. But even if we lose the deposit money, the real risk is trying to scramble at the last minute to find an alternate supplier. The costs may have changed and some of this stuff has lead times. If the project gets delayed because we don’t have the equipment on-site to be installed, we may be liable for a delay claim.”

Taylor stopped.

Time Compression?

“We have an ISO process audit coming up in two months and we have to get all the documentation updated before it starts. So, that makes it a two month Time Span goal,” Olivia described. “I am not sure I understand. This is a very complex project. The documentation is very detailed and technical. It will require someone at my level to supervise, to make sure it is correct. If we fail this audit, it puts several contracts in jeopardy. But a two month Time Span looks like Stratum I work.”

“There are two kinds of complexity. One type is created by the amount of technical detail. The other type of complexity is created by uncertainty,” I replied.

“Okay, I understand that if something has a lot of technical detail, it will take a long time just to parse through it. That might make a project’s Time Span longer. But I cannot get over the fact that this project has to be complete in two months, but the level of work is definitely higher than Stratum I.”

“Don’t be fooled. Because you only have two months, a great deal of uncertainty is gone. While you may think this is a tough project (detailed complexity), the limited Time Span forces this to be a simpler project.

“In two months,” I continued, “you don’t have time to start your documentation over from scratch. You don’t have time for massive overhaul, no in-depth analysis. You only have time to perform a quick review, observe a limited number of examples and make some relatively minor changes. Here’s the rub.

“The real Time Span of this project started the moment you finished version one of your current documentation. The true Time Span of the project is closer to one year than two months. Unfortunately, no manager took this assignment. No work was done. Procrastination killed its true purpose, and likely, the quality of the end product.”

Measuring Complexity

Lester had just returned, “That’s it boss, all done, what’s next?”

And with those innocent words, Lester has just defined the time-span for that specific task. Why is the time-span of a task so critical to the definition of that task? It is an attribute often overlooked. Time, hey, it takes what it takes.

For simple tasks, that take less than a day, or even 2-3 days, the importance of time-span is not so critical, but extend the time-span of a task (or a role) out to a week, out to a month, out to three months, and the dynamics become interesting.

What differences are there between a task that takes 3 days to complete and a task that takes 3 months to complete? In one word, predictability. Most of the elements required to complete a 3 day task are known, very specific, very concrete. Some of the elements required to complete a 3 month task may be unknown or may change prior to the completion of the task. This predictability (or unpredictability) is what makes one task more complex than another. “Yeah, so what’s the big deal about that?”

The “big deal” is that time-span, as an indicator for complexity, can become a discrete unit of measure for the complexity of any task. How complex is a task? If you can describe the time-span of the task, you have just described the complexity of the task. The importance of this measurement is that time-span can be described very specifically. I may not know how to specifically measure the “complexity” of a task or project, but using time-span, I can nail it to the wall: This project has a three-month time span with a deadline of February 15.

Questions:

  • If I can measure the complexity of a project using time-span, can I select a Project Manager using time-span?
  • If I can determine the maximum time-span of a person, can I determine suitability for a role in our company?
  • Can I test a person on the basis of time-span , as they grow and mature, to determine capability for more responsibility?

Hint: the answer is yes.

Complexity of Similar Projects

“Jason is our best project manager,” Elisa described. “But, I gave him just a little bit more responsibility and he is failing. Not only that, it’s impacting the rest of our project management team.”

“How so?” I asked.

“When Jason started here, he did so well on his first project that I gave him another project at the same time, two projects. And, he did that so well, I gave him a third project.”

“And?”

“After a year and a half, I asked him to look over the shoulder of another junior project manager, who was struggling with two projects.”

“So, that’s three projects plus two projects,” I confirmed.

“By then, he already had two more projects himself, so that would be five projects plus two projects,” Elisa replied.

“I see where this is going. He is failing. How many projects does he have on his plate, now?”

“Well, we have five project managers on the team. Everyone is handling two to three projects. I just asked Jason to look over everyone’s shoulder and make sure all the projects are running smoothly.”

“I have ten fingers and ten toes, how many total projects?”

Elisa stopped to compute the number. “Okay, let’s use all your fingers and toes, let’s say twenty projects.”

“Twenty projects is different from his original five projects,” I started. “Let’s talk about the complexity of twenty projects, Jason’s natural capability, and where the mismatch may be. Looking at your project management software, how many variables on a single project? Are the projects all the same, with the same variables? How are the variables grouped into phases, related to time? Can some variables be accomplished simultaneously, while other variables depend on each other and have to be done is a specific sequence? Now, multiply all that by twenty. Handling five projects is one level of work. Handling twenty projects is a different level of work.”

Cognitive Power

“Here’s a question for you,” Sam smiled. “We talk about potential, that is something we want in every candidate. You have also asked me to be specific in my language. You chided me about using analogies like – potential for growth, higher level thinking, more bandwidth, mental horsepower. Just exactly what are we talking about? And, why is this so important?”

My turn to smile. “Let me introduce a term – cognitive power. Cognitive power relates to the maximum number of variables a person can simultaneously deal with, in a given period of time. A manual task generally has a limited number of variables. Moving a pallet of ceramic tile in a warehouse requires a forklift, knowing which pallet, where is it located, where does it go, what’s in the way? There are a limited number of variables. And, those variables are physical and fixed.”

Sam nodded, so I continued. “Constructing a building is more complex. There are site considerations, zoning, platting, ingress, physical constraints, functional use, building codes, material availability, coordination of trades, availability of labor, influence of unions, finance logistics, even the weather. And some of the complexity arrives, not from the variables we know about, but, based on the timespan of the project (objective, goal), there will be variables we do not know about. The longer the project, the more uncertain the variables. Yet, to be effective, all the variables must be accounted for, including the ones we do not know about.”

“And so, a more complicated project will require more cognitive power,” Sam chimed in.

“We might try to count the number of variables to understand the complexity in a project, but the longer the project, the more some of those variable are unknowable. A better metric of complexity is to simply calculate the timespan of the project. We have to account for that uncertainty, ambiguity, in the decisions we have to make today.”

The Story of Our Intentions

“Once you understand this elegant simplicity, that timespan is nothing more complicated than the time measure of our intentions, the story of our intentions, the target completion time of our goals and objectives,” Pablo started, “you can begin to see that timespan is going to touch every aspect of a manager’s life.”

“Starting with?” I asked.

“You would agree with me that some problems are simple and most people can solve them?”

I nodded.

“You would also agree that as problems become more complex, some people struggle?”

I nodded again.

“And, while some struggle, others see the solution clearly. And, as those problems become more complex, more struggle. And, yet, there are still those who see solutions clearly.”

“I am still with you,” I confirmed.

“If we measure those problems in timespan, we get a clear demarcation of the problem’s complexity and those individuals who struggle and those who see clearly. For thousands of years, we have intuitively created organizations where we observe multiple levels of problem solving by different levels of people, but without a metric to measure that complexity. Timespan becomes the metric by which we can measure the complexity of problems and more accurately select people to clearly solve those problems.”

All Problems Are Not Created Equal

This is a series on Teal and Levels of Work. Here is the backstory for the series in case you are interested in the context. The purpose for the series is to explore the tenets of Teal through the lens of Levels of Work.
——
Humor me. To see Levels of Work (Requisite Organization), as a hierarchy based on problem solving complexity (rather than power), opens up a different texture of organizational structure. Let me quickly sport a reference chart below to demonstrate the discontinuous complexity underpinning Levels of Work. I assume you agree, some problems are more complex than others, all problems are not created equal.

Level-I (S-I) – Declarative problem solving. This is the world of opinion, without the necessity of supporting evidence. The world is the way it is, simply because it is declared to be so. Problem solving methodology at this level of work is trial and error. Trial and error is a valid problem solving method, it just has a high error rate in the face of increasing complexity. If S-I was a computer, its computer code would be the Boolean operator “or-or.” S-I is a disjunctive (disconnected) way of seeing the world.

Level-II (S-II) – Cumulative problem solving. If S-I struggles to connect the dots, S-II succeeds in making those connections. Cumulative means connection by successive addition. Problem solving occurs by connecting the pattern in a problem with a documented solution. Best-practices is an S-II problem solving method. If S-II was a computer, its computer code would be the Boolean operator “and-and.” S-II is a conjunctive (connected) way of seeing the world.

Level-III (S-III) – Serial problem solving. This is where Elliott observed the first instance of cause and effect. Problem solving occurs through a process of root cause analysis. If S-III was a computer, its computer code would be the Boolean operator “if-then,” cause and effect. This problem solving method is required in the construction of a system (sequence of steps in a process yielding consistent and predictable results, a critical path).

Level-IV (S-IV) – Parallel problem solving acknowledges the existence of multiple simultaneous systems that co-exist in proximity. In the same proximity, each critical path may not intersect, but each system’s capacity has an impact on neighboring systems. Problem solving multi-system impact requires systems analysis, specifically – capacity, constraints, delay and throughput. If S-IV was a computer, its computer code would be the Boolean operator “if-and-only-if, then.” This level of work manages problems with multiple simultaneous variables and increasing ambiguity of outcomes.

So, what does this problem-complexity have to do with Laloux and Teal?

You have to read carefully (Reinventing Organizations), but Laloux identifies these specific levels of problem solving quite clearly – Another cognitive breakthrough is the ability to reason in paradox, transcending the simple either-or with more complex both-and thinking.

As he describes the organizational period of magenta, he makes the following observation –
Cause and effect are poorly understood, and so the universe is full of spirits and magic.

Cause and effect finally comes of age in Laloux’s description – At the Conformist-Amber stage, reality is perceived through Newtonian eyes. Cause and effect are understood, people can grasp linear time (past, present, future) and project into the future. Laloux’s observation is quite consistent with the timespan schema in Levels of Work, that a measure of problem solving is based on a person’s capability to operate in the ambiguity of the future.

So, Laloux clearly observes problem solving through the first three Levels of Work, without realizing how close he came to solving the puzzle of hierarchy. These nested relationships** replace the power hierarchy with an accountability hierarchy. Indeed, Elliott described this organizational form with the acronym MAH (Management Accountability Hierarchy).

I think the issue of accountability will be next on our agenda.

I welcome comments. If it is your first time posting here, your comment will go into a temporary queue. Once approved, future comments will be posted in real time. If you are receiving this blog by email, you will have to click through to the site to see posted comments.

**Nested relationships was brilliantly described in this article by Richard Bartlett

How to Measure the Complexity in a Role

“And how big is Ron’s job right now?” I asked.

“Wait a minute, wait a minute,” Eduardo protested. “I am just trying to get my arms around measuring the size of the job by using Time Span.”

“I understand,” I replied. “So, think about it now. Measuring the size of the job using Time Span will become clear.”

“Okay,” Eduardo started. “Ron’s role now is to manage two supervisors with a total staff of twelve people. That’s two supervisors and ten workers.”

“So, what are the tasks and what is the Time Span of the longest task?” I prodded.

“Well, Ron has to teach his supervisors to use the same process he used when he was a supervisor. But he had all that in his head, so now he has to either write it down, or draw a picture, flow chart it out, or something. He has to create the system for his team.” Eduardo stopped. “This is really a different job. I think one of his supervisors isn’t doing that great and needs to be replaced. Ron is going to have to figure out what skills would be valuable to interview for and then he has to go out and recruit.

“He also has some equipment that needs to be replaced with more sophisticated machines, get a bit more automated, but he is going to have to make his case. And he has to budget for it. And he has to get that budget approved. Our budget process alone is done on an annual basis.

“Without thinking much more about it, I think the Time Span required for Ron’s job, now, is about twelve months.”

“So, based on Time Span,” I said, “the size of Ron’s current job is twelve months?” Eduardo was nodding. Time Span as a unit of measure was beginning to sink in.

Outbound Air – Levels of Work in Organizational Structure now available on Amazon.

Outbound Air

Can He Do the Work?

“The profile on this candidate is outstanding,” Rory explained. “It will take a special person to fill this role, and by golly, I think we have found the right person.”

“The profile is outstanding compared to what?” I asked.

Rory looked askance. “What do you mean?”

“It’s nice that he has a personality, but can this candidate do the work?” I pressed.

“Well, the profile says he is suited for this kind of work. Besides, everyone on the hiring team has interviewed him and they really like him,” Rory defended.

“It’s nice that he is a likeable person, but can this candidate do the work?”

“His resume attracted our attention. It says that he has experience in our field and he answered all of our technical questions. He really speaks our language.”

I let Rory squirm for a minute. He had already made his decision, and was waiting to see if I would support it. Without asking any hard questions. “Rory, this role is for a VP of Operations. It’s nice that he understands the technology, but can this candidate do the work of an Ops VP?”

“I don’t know where you are going with this?” Rory shook his head. “I was hoping you would get on board with this guy.”

“It doesn’t matter whether I get on board. Can he do the work? It’s a big role, integrating your sales, your sales forecast with production. You have six month lead time raw materials, tooling that changes, building to stock, assembling to order, staging, logistics. This guy will be coordinating teams of people in meetings, resolving communication paths, working on bottlenecks, manicuring system constraints. It’s nice that he understands the technical mechanics of your product, but can he do the work of an Ops VP?”

Full Speed Off the Cliff

From the Ask Tom mailbag –

Question:
I just joined the HR team here, working on a project to identify the complexity of mental processing of our team members. I just wanted to know, is there any effective tool/test available to identify the 4 types of mental processes. Can you please suggest other techniques apart from interviews to identify the 4 processes. I would be required to use this for recruiting and to assess the (CMP) of current employees.

Response:
STOP! You are headed in the wrong direction off a cliff.

I know you think you want to get inside the heads of your employees and have some support for a number (1-4) that you think will be helpful in selecting talent. DON’T PLAY AMATEUR PSYCHOLOGIST! You didn’t take courses in psychology, you don’t have a degree, much less an advanced degree in psychology, you are not certified by your state to practice psychoanalysis. Don’t play amateur psychologist.

Play to your strengths as a manager.

The four states of mental processing (Declarative, Cumulative, Serial, Parallel) can easily be used to determine the Level of Work. That focus will put you on solid ground. What’s the Level of Work? Look at your Role Description. In each Key Result Area (KRA), what’s the Level of Work? What are the decisions to be made in the role? What are the problems to be solved in the role? What are the accountabilities in each KRA? Write those elements into your Role Description.

With the Role Description in hand, create a bank of written interview questions, ten questions for each KRA that will reveal the candidates real experience making those decisions and solving those problems. I know this looks like work, it is. This is managerial work. Don’t play amateur psychologist, play to your strengths, as a manager. It’s all about the work. It’s all about the Levels of Work.