All Episodes
Previous Next
Dec. 22, 2006 - Freedomain Radio - Stefan Molyneux
47:52
568 Project Management (actually recorded Dec 21 12pm)

Flares of insight from a decade in the trenches...

| Copy link to current segment

Time Text
Good day, everybody. Hope you're doing well.
It's Steph. It's 1 o'clock on December 21st.
I think it is 2006.
And I'm going for my lunchtime walk, which I haven't had time to do sort of lately.
Let me just make sure that we have our windshield on the Zen Vision M. So, a long-time listener and a fine human being has sent me a request for a podcast, which I'm more than happy to oblige, as I stroll through this beautiful winter day in Canada here, my stomach literally growling with hunger.
I swear to God, I've got to be like a 3,500-calorie-a-day kind of guy.
That's even 4,000.
I just eat and eat and eat.
And I know it's because I exercise quite hard and this and that, but still, sometimes I wonder why I'm not a Goliath mesomorph.
It's a mystery to me.
So, he said, I've only done one or two business casts, and that's true.
I mean, this stuff is a little bit specific to a lot of people, but he said he enjoyed the interview podcast and so on.
He said, I don't know if this area of interest can be revived, but let's apply the old chest paddles.
To see what happens. Clear?
I would love to hear your take on the art and science of project management.
You've made a passing reference to having PM experience in the past.
If this surprisingly complicated topic has been the focus of your mental laser beam, let's hear it.
Some bullets for discussion. How personality, people skills, and use of psychological concepts...
Can increase effectiveness?
How to deal with the nebulous stage of project initiation?
Fear of the unknown? How do I make this field work for me?
Ethical dilemmas? Under-reporting or over-reporting progress or earnings for the sake of political pressure?
Unthinkable. Is there an encapsulant to project management?
Incentives versus punishment?
Voluntary organization? Versus or else?
And he's got another one on the psychology of failure, which...
I certainly would have some things to say, having failed at an enormous number of things in my life, and viewing failure as the norm, I would say that it's a very important thing in life to get the hang of.
And to enjoy.
Because if you only enjoy your life when you're succeeding, then you will enjoy your life very little at all.
Most things don't work, as I've talked about before.
And enjoying failure is a pretty key ingredient to enjoying your life.
But here's some thoughts I've had.
I guess I'll do a brief resume thing first, so you know where I'm coming from.
I... Was the chief technical officer at a company which is still in existence, though has changed hands three times, I think.
The last was a management buyout from a number of people that I'd hired who'd stuck with the company after I left.
This is a company I co-founded with my brother.
And we built customized software for managing health and safety and environmental issues for a variety of clients.
The original company name was Caribou Software.
For those who have...
Any random curiosity and or time on their hands?
It's now called E3M, I think it is, Solutions.
And you can find them on the web.
And during my time there, and I really did a sort of standing start when it came to learning about business issues, I basically came out of an arts degree with some computer experience in terms of coding, and just from sort of my own hobby situation, and then We started this company and I ended up building some pretty cool software.
I won't get into the feature sets because that would bore you to tears, but we had some pretty advanced stuff and we sold this software to about, I would say, 60 to 70 Fortune 500 companies over the course of six years or so.
And so I was responsible for coding the core architecture, the querying, report generation, presentation, and all the customized funky stuff, as well as the web interface and this and that.
So I did all the core coding for the features that were common to all systems, and then we code customized systems for particular clients.
That's how you gain traction when you are a small company.
And then, of course, you need to work your tail off to...
Start avoiding code customization so that you can actually grow rather than just make an exhausting living.
And so I ran as the chief technical officer.
The code customization kind of worked into my department.
And we had a team of about 20 or so programmers and project managers and so on.
And so in this sort of six or seven year period, I went through the pretty grueling phase of delivering Code customized solutions to very large and demanding clients.
And I did this about ten times a year.
It was certainly escalating a little bit more.
And some of these projects ranged up to seven, eight, nine hundred thousand dollars.
So some fairly large projects that I was responsible for.
And it was a near universal disaster for the first couple of years.
Which is not to say that it wasn't effective.
It was. It's one of the things.
It's a disaster in terms of project management.
My brother was doing the specifications, and he was a disaster at that.
And I didn't have enough knowledge to...
or maturity or wisdom or these sorts of things to be able to know what was required or what was demanded.
So, as far as project management schools go, I would say that mine was a school of hard knocks.
And that...
It is a real challenge to learn that way.
It really is. You know, there's a great video about software people building the plane while the plane is flying along, and that really was what it was like.
So, all of the mistakes that you could conceivably make in the realm of project management I have made those and more, and so I am now a little bit better at this kind of stuff.
So I have some experience and some credibility, mostly from making enormous numbers of mistakes in terms of being able to talk about project management.
So the first thing that I would say about project management is that there is no right answer.
I mean, this is a continuum of costs and benefits, many of which would be pretty specific to particular areas.
So, for example, the question of specifications is key to project management.
You cannot manage what you cannot measure.
This is a very fundamental thing.
You cannot manage a project if you do not have accountability and objective measurements for progress.
You cannot manage any kind of project if you do not have clear and detailed specifications that are signed off on both sides.
That having been said, there's no such thing as perfect specifications.
Perfect specifications would be enormously unproductive from a business standpoint.
If you have a project that is, I don't know, let's say it's going a year in length, perfect specifications could take eight or nine months to develop.
Perfect specifications also require quite a leap of conceptual imagination on the part of the people that you are building your software to, right?
So, and I'm going to just mostly talk about the software world.
I'm sure these are applicable to other areas, but this is the major one that I have seen.
But if you build perfect specifications, it takes forever to get those across.
I hope this background noise isn't too bad.
It'll get better. It takes forever to get it across, and there is no such thing as a perfect specification.
A perfect specification takes so long and is so time-consuming and expensive that you end up being economically, I think, enormously unproductive.
It's like a perfect diet.
A perfect diet would take you so long to achieve and would require such an obsessive amount of detail relative to the different food choices that you would end up Spending all of your time trying to eat and trying to prepare food and trying to figure out what's best to eat and taking your blood sugar levels and this and that, that you wouldn't actually end up living.
So, perfection is the enemy.
The perfect is the enemy of the good.
To look for heaven is to live in hell.
So, if you sort of get, or at least if you will accept, that there's no such thing as a perfect specification, then the art and science of project management really comes to the forefront.
To what degree can Can specifications be left to wither?
To what degree can we allow for non-specified situations?
To what degree can we allow for grey areas in the realm of project management?
And, of course, if there was such a thing as a perfect specification and a perfect project plan, you wouldn't actually need project managers, you would just need project planners.
The unknown in project management is a prodigious and scary and deep and enormous factor.
There's an enormous number of variables in project management that are constantly changing and constantly updating.
It's not like you roll a boulder off a cliff and watch it go.
It's more like you're in a barrel inside, rolling around.
So, there is some degree of good enough specification that you need to work out if you're a project manager.
That will give you an acceptable level of risk.
Eliminating risk completely is just adding to other negatives, right?
It just adds to the cost.
It adds to the back and forth.
And you won't succeed in business in a software provision role if you require that everyone dot every I and cross every T and do not allow any deviations to respect without massive charge.
You simply won't survive because nobody wants to do business like that.
So... That is a pretty important factor to understand.
There is good enough specifications and there are always problems that come along with good enough specifications because where the shortfall occurs is where the management requirements and the management imagination, creativity, discipline, communication and all those goodies come into play.
So, Given that we know we're going to have imperfect specs and that the imperfection of those specs is going to require management, the question is how good do they need to be and how are you going to handle the inevitable deviations in a way that balances your needs to make money with the customer's needs to alter opinion.
You know, I mean, people hate that around customers, but mostly we hate it because we're not assertive enough about charging them for changes.
So, that...
Reality of imperfect specs, constant changes, is important to understand and the value really that project managers bring to bear on this.
And it's why project management exists as a discipline, because there are these changes that are pretty constant.
Let me just do a quick pause here.
All right, so I do apologize to...
You'll have to hear me munch a little bit.
I just wanted to get this out of the way.
I'm not sure how generally interesting this will be to people, but if you're in this realm and want to get a little bit of value out of the scars on my professional career's body, this may be of useful, maybe of helpful.
Oh, what a beautiful day.
It really is. So...
Another sort of central...
And this is true, I think, for relationships as a whole, but particularly true of business relationships.
Another key aspect is setting the rules and boundaries up ahead of time.
I mean, there are definitely contracts for all this kind of stuff, and there's nothing wrong with those contracts.
But... Much more importantly, it's really on a personal level where relationship issues get solved, where problems get solved.
And this is the sort of social side of project management that I think is quite underrated.
One of the reasons why so many technology projects fail is because people don't have good negotiation skills.
And people will always go to the latest Java or.NET course, but not necessarily learning about Negotiations, which is a huge and key part of not just business, but life really as a whole.
So, I just was sort of mulling this over while ordering my lunch and trying to figure out what are the questions that ended up being useful for me in my project management career.
Or criteria, I guess you could say.
So, when you sit down with somebody to negotiate, And the first thing that you need to do is negotiate internally with your manager.
And you have to ask some basic questions about what it means to be a project manager in his or her organization.
So, for instance, I would sit down now and say, Okay, so I'm going to be your project manager for this company.
What is my scope of decision-making capacity?
Do I have the right to reject customer changes?
Do I have the right to resist scope creep without running around checking with everyone?
Because one of the worst things in life, of course, is to have responsibility without authority.
And that's a really nightmarish situation.
and also known as the caring for aged and abusive parents paradigm.
But if you have responsibility without authority, then your life is going to be just endlessly unpleasant.
Because what's going to happen is, imagine sending your kid out saying, go get us some food.
A kid's like 8 years old and say, go get us some milk and bread and cookies.
The kid says, well, I need some money.
And you say, no, I'm not going to give you any money, but I am going to not let you back into this house until you come back with milk and cookies and bread.
Well, clearly that would be a horrible position to put a child into, requiring theft or begging or, I don't know, going around offering his Nimble hands in the realm of child labour in return for food and the goodies that you want.
But how many of us in our professional careers accept exactly the same thing?
Where you do not have authority, do not take responsibility.
That's a lose-lose all the way around.
And of course it's a lose-lose for the company as a whole and for your clients in particular.
So if somebody says to me, you are allowed to reject client changes, I go, great.
I'll certainly keep you informed of what's going on, but that's my decision to make, right?
That's why you're paying me the big bucks.
And if they say, no, you don't have the right to reject client changes or scope changes, of course you say, well, what's the process?
Who has that right? Who has that authority?
And then, if the client request changes, you simply follow that procedure.
Maybe there's a meeting once every week, and the client says, I want to change something, can I do this?
And you say, well, I don't know.
I don't have that authority.
And you tell the clients that are up front.
We'll talk about your communication to the clients in a second, but...
Now, of course, life is rarely that uncomplicated, because lots of people are rather crazy.
So... It seems quite likely that what is going to happen is that your boss is going to say, yes, you have the right to reject scope changes.
But then, as clients are wont to do, not because they're an ain't evil, but because they've been trained well by other bad project management structures, is the client will request a scope change, will deny that it's a scope change, will phone your boss, Threatened to badmouth you in the industry, pull the project, maybe even sue, who knows?
I mean, this is actually extreme, but maybe.
And then your boss, that's going to come down on you, because he has people he has to answer to, and none of this is evil, it's just the nature of life.
And then you're going to say, okay, well then I don't have the right to reject scope changes, right?
This is using the argument for morality in business, right?
Either you have the right to reject scope changes or accept them, or you don't.
Now, if somebody says that you do, but then changes it, then, you know, you can say, obviously I can't evaluate this on a case-by-case basis.
That's going to drive everyone mental.
So now you're saying that I don't have the right to accept at least some scope changes.
So what's the criteria? Is the criteria, depending on how the client reacts...
Wow, I guess there are narwhals in the sewers.
So you can't, and you can't put a criteria forward for managing anything based on the argument from effect, right?
In other words, you can't say, well, you have the right to reject scope changes unless the client really complains because that's not scientific.
So, and you can't manage that, right?
Because that's not a known, you can't manage what you can't measure and you can't measure ahead of time whether or not a client is going to end up getting really upset over scope change rejections.
there's a fluidity to it but constantly asking for the rules is a very important thing in business so getting all of that stuff to find internally is very important Now, what happens is that everyone weasels and changes their mind.
And I'm sort of exaggerating, but...
It does seem to be depressingly common, right?
People will tell you to do stuff and then chastise you for doing it.
People will say that you have the authority and then will override you.
People are inconstant, right?
Just because. I don't think they are by nature, but that's the way they've been brought up.
Now, given that there's an absolute that this is going to happen, And you can't fight every fight.
It's too stressful. You might as well leave the company if you're fighting absolutely everything.
So you've got to pick your battles, right?
And I don't have any objective way of telling you what to do in these situations.
I'm just saying, you know, pick your battles and your gut will tell you which battles are worth fighting and which are not.
Sorry, I can't be more scientific than that.
Maybe there's some principle I haven't thought of.
And err on the side of not fighting the battle, right?
When you saddle up for battle in a business community, as in any community, you better have your ducks in a row.
And you better be emotionally together on it.
There can't really be any doubt in your mind or in your posture, because then you'll lose, right?
So, getting commitments to yourself as a project manager about the scope of your authorities is very important.
And do it in a public meeting, so that there are witnesses.
I mean, I hate to say it, but it's important.
And then when the ground starts shifting under your feet, and the primary danger for project management is not the clients, but it's your superiors, right?
It's not even your employees.
The primary danger to project management, what screws up project management the most, is your superiors.
Or, you know, I don't know, if not superiors, the salespeople who make promises to clients and so on.
So, I would say that...
You've got to get things squared away with your superiors, first and foremost.
Now, when it comes time to getting a project going in terms of clients, you're going to have your formal documents and everybody has to make sure that they review it.
But my suggestion, my strong suggestion, is to...
You get on a chatty basis in terms of the rules with your customers, right?
With those who you're completing the project for.
So that after everyone goes through the 20-page legalese and goes blind and vaguely figures things out and then forgets about it almost immediately because it's so boring, I think it's well worth having a conversation to summarize things so that you both know, right, just say, you know, let's put the contract aside for just a second, and you can sit down and say, let's just work with the general principles on a conversational level so that we all, we both understand sort of what's going on, right?
So, and say things up front, right, so that they're not sharks.
Say, yes, now they're going to be scope changes.
There are going to be scope changes.
We do not have a perfect spec.
No such thing exists. The projects are a moving target.
And that's good. That's why you got paid.
So, say to clients that there are, in fact, going to be scope changes.
And we need to sort of figure out, at a conversational level, we've got the contract, but we don't want to have to go to the contract if at all avoidable.
There are going to be scope changes, and here's how I work with scope changes, right?
I absolutely want to give you Scope changes that I can give you.
I absolutely want to. You're my customer.
I want to make you as happy as humanly possible.
However, there are times when I'm going to have to make you unhappy in order to make you happy, sort of like a dentist or something, right?
Where I'm going to have to say no to a scope change, or at least no without renegotiation, because in my sort of professional judgment, it's going to cause great risk to the project as a whole.
And you need to establish these things verbally, right?
Business takes place at a relationship level, not at a contractual level.
I mean effective business, positive business, win-win business.
And so, I will make a commitment to get you as many resources as possible to make any transitions as painless as possible when the scope changes, which will arise, inevitably do arise.
In return, and I don't know whether you want to say this up front, it really depends on your relationship with the person, I would sort of ask the following.
I've said, it's been my experience, and I'm not going to say this has occurred with you, but if a client doesn't get what he or she wants, sometimes they'll go over my head, sometimes they'll try and pretend that it's not a scope change.
I'm not saying that's your, right, but that's not going to work for us very well.
It depends on your relationship, it depends on your own experience, and it depends on the risk of that occurring.
But you don't want to manage these things after the fact, right?
You don't want to say to somebody, why the hell did you go over my head?
After they've gone over your head and appealed to the CEO to get you to change your mind about scope creep.
You want to have that up front, right?
So the people say...
And you can say, look, if we've talked it over three or four times, and we can't resolve it, let's both go to my CEO. Right?
I mean, I want us to do a good job, but I also have to protect...
The integrity of what we're delivering.
My job is to service you and to make money.
I mean, my job fundamentally is to make money, as is yours, right?
It's everyone's job. And I do that by servicing you, but if servicing you means losing money or losing control of the project, then I can't do that.
So we'll try and work it out, but I don't want to find out that you've gone over my head without telling me.
I don't want to find out that you're unhappy with me as a project manager.
Because the CEO comes storming into my office and says, what the hell are you doing to our poor as a client?
Because everybody knows who's in this game, knows what happens, right?
The client calls up the CEO, or whoever, pitches and complains, and then the CEO is going to make a commitment to get the client what he wants.
The CEO has no context, no perspective.
A good CEO will, of course, say, well, let's have this three-way conversation.
I can't make any decisions about your project.
I trust my project manager.
If he says no, I stand behind him, right?
But most people use authority to betray others because that's what happened with our parents, right?
So, that's a sad but true fact of human nature at the moment, right?
At the moment. So you can get those kinds of things worked out up front.
Don't take them for granted. Don't assume them.
Get people to look you into the eye and to agree with whatever it is that you're putting forward.
You want to manage relationships proactively, not reactively.
You don't want to call someone and say, why the hell did you go for my head?
I mean, you want to do that if they really do shaft you after agreeing not to.
But the interpersonal expectations should be set ahead of time, I think.
It's sort of what we were talking about with relation to dating recently.
You know, you can ask on a first date, do you consult a Ouija board on who you should marry?
Well, it might be important to figure out the decision-making process on a variety of things before continuing the data, so you don't find out later.
So, then of course the project is underway.
Okay.
If you experience and you're doing well, then you will say to the customer, I expect that within two weeks we're going to have a conversation about scope creeper.
Everybody knows that it's ten times more efficient to catch a design problem during the spec development process than it is during implementation.
But many people who aren't intimate with software, and that's of course most clients that we're selling to, are not very aware of the look and feel of software until they see it in front of them.
I'm a big fan of building from the interface down.
And not PowerPoint, where there's so many rad tools out there, rapid application development tools out there, though.
I managed, sure, not a big project, about a $150,000 project when I was at my last company.
And we came in under budget and early because we built the interface first and we got everybody's feedback on how the software was going to flow and what it was going to do.
We built the sample output.
So then when we wired it up under the hood, and showed it to them, there was no particular shock at how it looked.
And that seemed to work very nicely, and there's lots of knowledge out there about this kind of stuff.
But, start with what the user sees, and then start to wire it up underneath.
You can do this in PowerPoint or whatever, but in general I think it's better too.
Just do some sort of hack job in whatever rad development environment you can.
Heck, I just use VB6. Access, whatever.
Just buttons and clicks. And then sign-offs are important.
And sign-offs concentrate in people's minds wonderfully, right?
Because now they're saying it's okay and we can continue.
So in this one, I would ask the client to approve the interface.
Nothing is going to change from here on in.
Lockdown or whatever phrase you want to use.
And then, you sort of get nods around the room, or if it's a conference call, you just ask if there are any other changes.
You say, oh, I'll send you these screenshots.
You can spend a day, but at the end of the day tomorrow, if I haven't heard back from everyone, then I'm going to assume that we're locked down and can continue.
It's almost, I think, worthwhile to communicate why you're making those decisions, right?
If you say, I need to know tomorrow so that we can continue, the client understands that you're trying to move things along and get their project finished and have their best interests at heart and so on.
And then, you know, when the day has passed...
Then you send an email to everyone saying, the interface is now locked down, there will be no further changes without ECNs or engineering change notices or whatever.
And this way you're just building the case step by step as to why scope changes should not be allowed.
Because if you go in with the knowledge that scope changes are going to occur, then you need to do a progressive lockdown of various bits, right?
If you're trying to fasten down a sheet in a high wind, you do one side, fasten down.
You don't sort of run around driving sticks in here and there randomly a little bit at a time.
You fasten one end, then you fasten another.
It's like putting those sheets on your mattress, the elastic ones that take off your fingernails.
You do one side and then, right?
So you want to establish your milestones pretty significantly.
All right. Thank you for your patience and hopefully the munching sounds aren't too nasty.
I'm going to just toss this and we'll continue as I walk back.
So you want to make sure that you're showing this kind of progress and you're also going to be aware that as a project manager you can ask all the questions that you want and you go through normally a four-stage process.
I'm doing a scope size, right?
Ballpark figure off the top of your head or somebody's head, your CTO's head or something.
Which is, you know, five-minute conversation.
And then a slightly more refined conversation that occurs with a couple of hours of research.
With no real spec yet, but just in general.
And then a more detailed one that takes a week or so, where you're getting specific and detailed estimates from programmers and so on.
And then the final project plan.
So whatever it is that you're going through to make sure you don't end up doing a final project plan before presenting the cost range to the client.
Or just magnitude costs or whatever.
That's not a very good idea.
Let's get to the median here.
I won't solve the problems of the world if I get creamed by a car.
Jay walking past the cars.
Look at that.
that, what a rebel.
And Capistan lives where I tread foot.
So, once you have got your individual perspectives nailed down, the question, of course, occurs when you find out from a programmer, or occurs when you find out from a programmer, or someone in your team, that what was imagined to have cost a week of labor or two be five FTEs,
full-time equivalency in terms of days, then you find out it's going to be two weeks.
And that's inevitable, right? Some third-party control you use doesn't work with Windows Vista or some new thing that's occurring.
There's some incompatibility layer.
I remember designing an application which used a tree control from Microsoft which was completely incompatible with VB6 as an install base.
The com controls just messed each other up.
So either we forced it and VB6 broke or VB6 forced it and we broke and had to switch tree controls.
That's not a predictable thing. Again, these kinds of variations, a lot of project managers look at these kinds of variations as problems that are irritants.
And, of course, there's no doubt that they can be irritating, but they're not problems in terms of project management.
They're sort of why project management exists in the first place, because there are these unknowns.
Again, if it was just like rolling a rock downhill, you'd just get it going and watch it go.
Scope changes and production problems and an unknown number of issues that can crop up in software in terms of compatibility, though Java and.NET have helped that a lot.
DLL hell can still occur.
Browser issues, you know, oh, it doesn't work on Safari under certain conditions.
You can't predict this kind of stuff.
And to look at this as deviations from some sort of centralized project management approach, or deviations from a good project, a good project includes all of these things.
In other words, a profitable project includes, the most profitable projects are the ones that break new ground.
But they're the most risky ones, right?
And they require the greatest skill in terms of project management.
Now, of course, you can't ask for clients to pay for ActiveX control issues that are conflicting.
Sorry to date my technology knowledge, but I'm in marketing now.
You can't, you know, some sort of Citrix deployment scenario that doesn't work under X, Y, and Z conditions, some issue where remote printing or some sort of issue with a printer driver, you can't ask clients to pay for all of those.
Those have to be included based on your best judgment.
In the padding aspect of the software project or the project itself, if you don't plan for the unknown, then I think that you're sort of fundamentally misunderstanding project management.
Project management, like all forms of management, is planning for the unknown, which is the great paradox of management.
If it's known, it probably doesn't need to be managed, right?
I mean, When you know how to drive a car, you don't need an instructor there, right?
Once you know something, you don't need to be managed.
So, management is all about the unknown.
Project management is all about the unknown and all about the things, but the good project management is based on the knowledge that these unknown things will occur, having some idea about the proportionality of those unknown things, how many they're going to occur, what type they're going to occur, and how much they're going to cost.
This is the last thing I'll talk about here, and I could go on and on, as I often do, but I should get back to work.
But the last thing I'll sort of talk about here is something that is an insoluble in terms of project management.
Maybe it occurs in other industries as well.
I know for sure, of course, that it occurs in the realm of software.
But the insoluble aspect goes something like this.
So... You and I are both competing for the same software job, whatever it is, X. And I put very strict controls in about scope changes and cost, right? Because one of the other things that you don't know is...
I mean, this is a very challenging Gantt chart aspect of problems in project management is...
Waiting for feedback is one of the great problems in software and in other areas.
So you say, is this dataset correct or is this the way you want it?
And then people take three weeks to get back to you.
Well, what are you going to do with the people dedicated to that resource during those three weeks?
What are you going to do with them?
You can't just have them sit on their thumbs to reassign them to another project.
It's often not particularly helpful.
Because they'd have to get up to speed on that project, and by the time they're up to speed on that project, you will get the information back from the client.
Of course, the other thing that can occur, and you don't know that it's going to be three weeks, right?
You say, I need this back in two days.
Two days turns into three, to four, to five.
Having people, you know, well, I'll get them to do some QA, some additional documentation, but it's like a train, right?
If you push the caboose forward, then the front of the train has to go forward too, right?
Right? So, this sort of feedback issue from clients, there have to be assumptions that, again, you verbally talk about with clients.
Here, you have two days to review this.
Look them in the eye. You have two days to review this at this part of the project plan.
Is this enough for you? If not, no problem.
We'll stretch it out. It's going to cost you a little more.
And then if they don't get back to you, In the time period required, then, you know, you have to tell them, well, this is now causing this delays, I have to reassign these guys.
If it's one day we can live with it, you know, you want to be flexible and, you know, don't be a total hard-ass because people, you know, somebody has to rely on somebody else who suddenly gets sick or their kid gets sick or whatever, right?
So the last thing that I'll sort of talk about is the insoluble part, but...
It is, I think, really at the core of how it is that you spend your professional career, how it is that you spend time in your career, and the kinds of people that you surround yourself with.
Not without exception, but not completely without exception.
The people who bought the software that I wrote, this would be in sort of the mid-90s, were mostly insane.
One guy bought the software for a company I'll leave unnamed, and he ended up showing up to work in full combat fatigues and using his telephone like it was a walkie-talkie.
It had some sort of weird flashback thing that occurred.
And there were other people who had problems with mental health, let's say, and they bought my software.
And some people were just visionaries, right?
And I think some people were very smart and made a good decision about it and so on.
But, you know, there were some lunatics in there.
So, if you and I are both bidding for a software contract, and I put in a 10% padding, and I have detailed conversations about exactly what's expected, that there's going to be scope creep, and...
Here's how we're going to deal with it, and I can only give you a range, even in terms of final cost, if everything goes well, but of course, even with the margin of error that I've included, there are these risks and these risks, and I'm sort of upfront to you about what I can do and what I can't do, reality and fantasy.
So that's my approach, right?
And my bid is like half a million bucks.
But then you come in, With a bunch of junior programmers that you're paying one half what I'm paying.
And no particularly well experienced project managers.
Maybe as a team lead, maybe it's somebody who's good with a spreadsheet.
And you come in and you say, well I can do it for like 300k.
Well, an experienced purchaser...
Of goods or services or an experienced person who's bought from vendors.
We'll look at this disparity in price and go, huh, either this guy is a total genius or he doesn't know and it's just underbidding to get the business for, you know, whatever reason, count for the number of them. Now, if this guy is a total genius, he can do it for $300,000 versus this other guy who's got more experienced programmers, more experienced project managers.
So it's going to be $500,000 and it's giving me a detailed list of all the risks involved and so on.
Either the $300,000 guy is a sheer genius or not.
Now, of course, if the $300,000 guy is using Inexperienced labor in project management and is not putting forward all the caveats and all the problems and all the fine print that is fully expected to occur, then it's not that hard to figure out,
you know, if a Dell computer is going to cost you fifteen hundred bucks, but the exact same computer from the guy in the basement down the street is like five hundred bucks, You've got to wonder where the savings are.
And if he offers the same support and this and that, you've just got to wonder, right?
I mean, you can go out and buy it, but you'll pay for it somehow, right?
All things are pretty much equal in the market eventually.
So, the problem, of course, is that Lots of people will choose the 300k.
A little bit fewer now than in the 90s, but lots of people will choose the 300k.
Now, I did make good on the 300k stuff, but I just worked like a mad demon and traveled like crazy during the startup phase, so my 70-hour weeks were how I was able to make good.
Because, of course, clients shouldn't pay for my education either, right?
So, the problem is that Somebody's going to look at, the CEO, whatever, is going to look at and say, well, they've got real problems with your price.
Now, if they call you, I mean, everybody wants you for $300,000, right?
That's sort of the basic thing, right?
And a lot of CEOs aren't as well-versed in opportunity costs as they should be.
Because they'll say, oh, $300,000, well, that's better than nothing.
Well, no, it's not. Because nothing gives you the opportunity for $500,000 still, but $300,000 will lock you up for three months or six months or whatever.
And you won't get the chance to make that other money.
So, the CEO will say, you should reduce your price and may do it that way.
Or the CEO, if he's a good CEO, will say, no, I trust this guy.
If that's what he says it costs, that's what he says it costs, right?
I mean... You kind of don't want to be, you don't want to have clients drive wedges between you and business, between you and your boss, you and co-workers and your employees, but it happens sort of with depressing frequency.
Now, the problem with, again, all things being equal in economics, the problem with the 300k, the clients who choose the 300k people, if they choose you rather than me, is that those clients are going to be hell to work with.
Because they're not experienced, and they're entitled, and they're greedy, and they're cheap.
And they don't want to pay for quality, but they expect quality.
Because you're not saying, I'm 300k because I'm less quality.
You're not saying, well, I'm the Honda, and he's the BMW, so you can't expect the BMW for the price of the Honda.
He's saying, I'm the BMW, and I'm half the price.
Three-fifths the price in this case.
Now, clients that believe that you get a BMW for the price of a Honda are not very experienced purchasers, let's say, and they're not expecting lower quality.
They're expecting you to deliver higher quality for the same amount of price, which is economically mostly impossible.
There's a reason why you pay a lot more for an experienced programmer.
Because they know how to build software that's scalable, that works across different environments, where customization is kept to, minimum configuration files, this and that.
So, that's the real problem with customers that choose cheaper vendors.
They're going to be held to work with, and you're going to get stuck if you're in a culture where this is acceptable business practice to underbid and get the business however.
You're going to spend the rest of your career working with Ignorant customers.
Ignorant, entitled, greedy, cheap customers.
That's not fun.
That's not fun. And, of course, if this is the case where every time a customer goes over your head to your boss, your boss leans on you to make changes, again, that's the same.
You're going to get locked into this world.
Where you're working with these cheap-ass, betraying, non-supporting, non-trusting kind of customers and employees...
employers, sorry. And I would say that you kind of want to run away from that as quickly and as efficiently as possible.
That's not going to change in people, right?
So that approach to project management is very important.
You need to read to people in your organization as well and recognize that if you have a habit of a promising...
Underbidding and so on, that you're going to waste your life running around like a chicken with your head cut off after the crazinesses of entitled and irrational and inexperienced people.
Oops, sorry about that. Revolving door.
Well, thank you so much for listening.
▲
Export Selection