Ep.104 Systems Theory: Why Projects Don’t Deliver

By Published On: February 11, 2021Categories: Blog, Podcasts, The CTO Studio

Are you a technology professional looking to connect with like minded people?

We have a thriving community of CTOs discussing these episodes and more.

Click HERE to set up a call and learn more about becoming a member.

About The Speaker:

Casey Kleindienst is an expert at Supply Chain Management and current serves as a Management Professor @ Cal State Fullerton

Episode Resources:

Check Casey out on LinkedIn: https://www.linkedin.com/in/ckleindie…

Episode Transcription:

Nickolai: [00:00:05] Welcome back to the studio, I am your host, Nikolai Walker. Today I am joined in studio by Casey Kleindienst. I had to practice that name more than I’d like to admit. But anyway, I want to start off by asking this gentleman, why do projects not deliver when they are slated to?

Casey: [00:00:24] If you’re saying factually that you have performance metrics and they didn’t meet the performance metric like the system didn’t work, well, something happened really early in the process. So the further you can go upstream to all the activities that were involved in that process being shaped, the closer you’re going to come to the root cause. And even before planning has to first come the vision before planning.

Etienne: [00:00:53] So I might be dealing with the symptoms of a failing project because we’re not delivering, there’s disagreement on outcome and all that. You’re saying one way to approach that is to go upstream to kind of look at how, to try and get as close as possible to when certain decisions were made that cause like I’m looking at the symptoms, but what happened maybe six months ago where things kind of got off of the rails?

Casey: [00:01:24] Yeah, you have to go as far upstream as possible because you can find intermediate causes and you can apply effects, but you’re applying it in the wrong place. You’ve got to go as upstream as far as possible to find the instigator. And then, if you fix that, then that relieves all of the other work arounds that are coming behind it.

Etienne: [00:01:56] That sounds so true.

Etienne: [00:02:01] It’s because it’s making me realize that the person or the thing that you think.. it might point the finger to the least obvious issue, for instance.

Etienne: [00:02:19] CEO wants their CTO to execute on Plan A.  Plan A is faltering.  CEO makes an adjustment or turns up the pressure on something, the plan moves forward, falters even more. So you “can” the CTO.

Etienne: [00:02:41] But if you did some analysis and you go further upstream and you kind of see…oh, hang on, there was a personality clash between the CEO and CTO that caused a whole series of decisions or corrections to be made.  The CEO is now as culpable to the failure of the project as the CTO who got fired.

Nickolai: [00:03:04] So in layman’s terms or terms my dad used to use, this sounds like a case of if you can’t fix the problem, fix the blame.

Casey: [00:03:11] It takes a mature person to do that because incompetent managers just assign to blame where they discovered the symptom. And I’m saying anybody could do that. I don’t need a manager to do that. And anybody can just find something and blame the person that broke it. Well, but that takes a really skilled manager to go see the causes that led up to that breaking, you know, where you find the problem is the end. It’s like the last step. You got to start heading upstream in all cases. That’s the hard work. That is the hard work. And sometimes it points to the manager.

Etienne: [00:04:06] Or sometimes it points to a flawed view of what the project is supposed to accomplish, because the world I’m talking about is when a CEO founder wants magic to happen. Let’s upgrade the system from version one to version seven. So baked in flawed desire request, it’s a broken request, but CTO comes in and is employed by the CEO and feels like they can do it.  Then they run off and they start doing it and months turn into years and a backlog of 20 tickets turns into a backlog of 500 tickets.

Etienne: [00:05:01] The root cause analysis is probably going to stop, like you said.  We have to fire the CTO because they’re not doing it. The job isn’t getting done. Meanwhile, that request to go from version one to version seven was the real flaw. But there wasn’t any sort of correction or accountability or and that’s a bit of a hyperbole, obviously, but in many small decisions being made around many small projects, this is most likely what is happening.

Casey: [00:05:39] So it’s it’s a post-mortem. If you know the events already taken place, you can’t undo it. But you have an opportunity now to understand first steps and perhaps the second time you deploy that you’re going to take more care. I mean, that’s that’s the learning opportunities. you’re improving the process, whether it’s a planning process or a vision process or whatever the process is, a selection process. You know, expectations also sometimes it’s the responsibility well not sometimes, always is the responsibility of the one with knowledge, to. Don’t oversell anything.

Nickolai: [00:06:33] So what then does it all boil down to Casey?

Casey: [00:06:37] It Boils down to saying, you know, this is a reasonable expectation and why would I start if, nobody starts anything, if they know the end result is a failure? The lowest person in the organization thinks the same way as the highest person. Well, the highest, you know, at the highest level. The truth is, you know, is a rare commodity and desperation causes, you know, want desire. And they just want someone to say, yeah, we can do it even though it doesn’t stand a chance.

Etienne: [00:07:17] Well, and I find that to be the challenge with many CTOs in their in their possession, which is, We have to do X.  And I mean I know this isn’t all CTO’s, I’m just talking about the conundrum of the simplicity of a request that has this massive technical implement implication that maybe is unknown even to the CTO at the get go.  And then as that discovery process takes place, there is this incredibly difficult step that has to happen, which is the pushback or the feedback or the missed expectation that has to make its way back up to the CEO, which can be contentious.

Casey: [00:08:10] What’s worse? Is it worse to stay on the same track or, you know, bite the bullet. I think there’s a responsibility that experts have. Your knowledge value workers, right.

Nickolai: [00:08:24] So is it then a lack of available experts in the field you’re hiring from or is it not placing trust in the experts you hired? I mean, you hired the person for a reason, right?

Casey: [00:08:34] Listen, if I hire, I hire people that are smarter and smarter than me because they have skill sets I don’t have. Well, I have an expectation that they also are going to warn me when my idea is no good, when it’s not going to work. And then we have something that we can deal with. I don’t want someone that doesn’t use their, Doesn’t use their good, solid judgment about going forward because it’s all about resource capability, because we find a obstacle or a stumbling block doesn’t mean we abandon the project. It just says resources that we have are inadequate. And we can either scale down the expectation or we can go invest in more resources. You see, I’ve never seen a capable manager not want the truth, you know, because you can deal with the consequence, my fear as a manager is I don’t want someone you know that knows or has a suspicion that the end result won’t work itself out and goes off and does it anyway. you know, it’s like I can, embrace everybody. No one is,  I better. Stop there.

Nickolai: [00:10:01] Yes. Maybe we should stop there to avoid some sweeping over-generalizations. Good point, sir. Thank you.

Etienne: [00:10:13] Well, I like the truth statement. I like the fact that we should go back to our stakeholders and say there is truth and we have to do the due diligence around that in order to deliver on the project goals.

Casey: [00:10:34] that’s, you know, that is a daily occurrence to anybody that gets a paycheck

Casey: [00:10:40] that very issue And oftentimes what I used to do is I would take someone I would just use 40 hours a week, I just say that’s the capacity, the capability. I would give somebody 80 hours worth of work to do in a week.

Casey: [00:11:03] And then there really was 80 hours worth of work. Only I didn’t know what the most important 40 was. So I just overload a person’s, you know, calendar and then wait for that person to come and say, this just can’t be done. I’d said you’re absolutely right. This can’t be done. You pick the 40 that we need to get done and we’ll put the other 40 hours on the back burner.

Etienne: [00:11:31] You see this that to me, I could not more fundamentally disagree with that style.

Casey: [00:11:43] I’m not saying it’s a wise practice. it reminds me of old school manufacturing where they would bring, you’d have workstations and manufacturing people working, making things. And the the manager would bring all of the material out of the warehouse and stick it in front of somebody’s workstation. And it was piles of stuff. And I said, why are you bringing all the material and overloading the workstations? He says they’ll work faster if they see that there’s more to do

Etienne: [00:12:21] I am thinking about. I’m thinking about some scenarios where I have gone to development teams and I have knowingly asked them to do more than I know they can do.

Etienne: [00:12:35] I’m trying to figure out why I did that.

Etienne: [00:12:38] Is it because I’m afraid that if I set the goal too low, that they will work slower?

Casey: [00:12:45] No, it probably couldn’t prioritize what they really needed to do. And so you gave them the whole enchilada and they had to now pick what the most important things were.that was my motivation, is that I didn’t know enough about the job that I was managing to make the decisions on where the priorities were because. You know, unlike manufacturing that has, you know, you can apply standards to how long it takes to do something, you know, we work in an area where you can’t apply those kinds of standards. You don’t know how long it’s going to take to do something. You have some estimations, but you’re always never surprised when things take longer than you thought they would.

Etienne: [00:13:35] And yet we continue to want to know when things will be done by.

Casey: [00:13:39] So is that internal pressure because you’ve promised a due date or a deadline?

Etienne: [00:13:46] Well, I I think that we live and this is a little bit of, you know, this is a bit of a self-indulgent, I suppose, sort of thinking through this thing.  Our listeners might know the answers to all of this, but, I think we have this fuzzy world of creativity, the task at hand, the problems we want to solve, these are all non discreet things, you know, you have to take thoughts and turn it into code and turn it into a testable thing and then you have this very discreet thing called time, and you are just constantly mashing and wrestling and pushing, pushing, pushing all of these things into a when will it be done?

Etienne: [00:14:42] How long can I wait? And then you add dollars to the time buckets, which is a socially acceptable and socially required way to pay people.

Casey: [00:14:54] Yeah, unless you go back to a job shop, you pay people for the work they do that they outlaw that about 100 years ago. You know, that’s ah, originally that’s how Labor was compensated by the job. And but if you hire someone, well, it’s acceptable. You hire a contractor and they quote you what the job will cost and then it’s up to them to get it done in the amount of time, you know, that they estimated if they overrun the time its on them.

Etienne: [00:15:26] Which is the fixed cost estimation, which everyone says, don’t ever do that, why do why do managers want to know how long it’s going to take to do something?

Casey: [00:15:37] Well, because they have other events that are going to follow once that task is done.

Nickolai: [00:15:42] So, Casey, what is the best way then that I can reassure my manager that we as the team are working hard and we have the company’s best interest at heart?

Casey: [00:15:52] That happens, that trust relationship happens in the first 100 days.

Casey: [00:15:59] And that’s where the real reputation is honed. It’s amazing that it’s only one hundred days, but in 100 days, you’re given free reign to show yourself. And the rule is basically I accept any behavior in 100 days because you’re not responsible for anything that you didn’t cause anything to make it your problem and in that there’s this is meshing that takes place between the individual and the organization. And it’s and once that’s established then more responsibility or you’ll be looked at as being part of the organization now. And you can’t just say, well, you know, I wasn’t here then. You are you’re you’re part of it. But how are you, how you manage those 100 days is going to probably stay with the individual through probably most of the career within the organization. And so we judge each other on on our history, our track record.

Etienne: [00:17:17] But I do think it’s interesting to say in your first 100 days, there is no, you don’t have any baggage. You’re not responsible for what was done before your time. There’s not enough time has gone by for you to have to give account for.

Etienne: [00:17:35] I mean, as the days progress, you know, you’re starting to make promises that you have to keep and now you’re being judged on as long as you progress into the hundred days and past that. Well, now there’s some decisions that you’ve made which the organization has afforded you in blind trust because of your reputation. But now the chickens come home to roost after those 100 days because now you’ve implemented things that you can be judged by.

Nickolai: [00:18:08] All right, folks, well, that signals the end of the show. I want to thank my guest, Casey Kleindienst, who is the director of Supply Chain Management. He’s currently a professor at Cal State Fullerton. We love, love, love having him here on the CTO studio. Do expect to hear another interview with him next week. I encourage you to check out his LinkedIn page. And as always, please check out 7CTOs.com. As always, we will see you next time.

Click Here for Itunes

Please rate and review our podcast!

Click Here for Itunes