In spite of the future being -- well -- the future, and utterly unknowable, we still have to have the following kinds of discussions.
Me: "It's probably going to take a team of six."
Customer: "We don't really have the budget for that. You're going to have to provide a lot of justification for a team that big."
What's wrong with this picture? Let's enumerate.
- Customer is paying me for my opinion based on my experience. If they want to provide me with the answers, I have a way to save them a lot of money. Write their own project plan with their own answers and leave me out of it.
- I've already provided all the justification there is. I'm predicting the future here. Software projects are not simple Rate-Time-Distance fourth-grade math problems. They involve an unknown number of unknowns. I can't provide a "lot" of justification because there isn't any indisputable basis for the prediction.
- I don't know the people. The customer -- typically -- hasn't hired them yet. Since I don't know them, I don't know how "productive" they'll be. They could hire a dozen n00bz who can't find their asses blindfolded even using both hands. Or. They could hire two singular geniuses who can knock the thing out in a weekend. Or. They could hire a half-dozen arrogant SOB's who refuse to follow my recommendations.
- They're going to do whatever they want no matter what I say. Seriously. I could say "six". They could argue that I should rewrite the plan to say "four" without changing the effort and duration. Why ask me to change the plan? A customer can only do what they know to be the right thing.
Let's return to that last point. A customer project manager can only do what they absolutely know is the right thing. I can suggest all kinds of things. If they're too new, too different, too disturbing, they're going to get ignored.
Indeed, since people have such a huge Confirmation Bias, it's very, very hard to introduce anything new. A customer doesn't bring in consultants without having already sold the idea that a software development project is in the offing. They justify spending a few thousand on consulting by establishing some overall, ball-park, big-picture budget and showing that the consulting fees are just a small fraction of the overall.
As consultants, we have to guess this overall, ball-park, big-picture budget accurately, or the project will be shut down. If we guess too high, then the budget is out of control, or the scope isn't well-enough defined, or some other smell will stop all progress. If we guess too low, then we have to lard on additional work to get back to the original concept.
Architectures, components and techniques all have to meet expectations. A customer that isn't familiar with test drive development, for example, will have an endless supply of objections. "It's unproven." "We don't have the budget for all that testing." "We're more comfortable with our existing process."
The final trump card is the passive aggressive "I'll have to see the detailed justification." It means "Don't you dare." But it sounds just like passive acceptance.
Since project managers can only do what they know is right, they'll find lots of ways of subverting the new and unfamiliar.
If they don't like the architecture, the first glitch or delay or problem will immediately lead to a change in direction to yank out the new and replace it with the familiar.
If they don't like a component, they'll find numerous great reasons to rework that part of the project to remove the offending component.
If they don't like a technique (e.g., Code Walk Throughs) they'll subvert it. Either not schedule them. Or cancel them because there are "more important things to do." Or interrupt them to pull people out of them.
Overcoming the Confirmation Bias
I find the process of overcoming the confirmation bias to be tedious. Some people like the one-on-one "influencing" role. It takes patience and time to overcome the confirmation bias so that the customer is open to new ideas. I just don't have the patience. It's too much work to listen patiently to all the objections and slowly work through all the alternatives.
I've worked with folks who really relish this kind of thing. Endless one-on-one meetings. Lots of pre-meetings and post-meetings and reviews of drafts. I suppose it's rewarding. Sigh.
"Doing the Right Thing"
ReplyDeleteIs this a religious activity? Must we summon a priest, rabbi or some such thing? Must we convert someone to our "religion" so that they do the "right thing".
Perhaps the initial mindset is all wrong? Perhaps we should be "making business decisions" instead?
Recently, one group at the client wanted to do x because it was the "right things to do". Another group wanted to do y because it was the "right thing to do? From perspective a, x was the right thing to do. From perspective b, y was the right thing to do. I was caught in the middle and got annoyed. I finally said, it is a business decision that must be centered around time to market.
Perhaps the budget trumps all? Okay, let be honest about that.
Perhaps orgs is not willing to change process d? Okay, lets be honest about that.