So it's several years ago, and I am working for a certain type of
company in the midwest. You probably know the type -- most of what they
do is move money around from one large group of people to a smaller
group of people, collecting a fee along the way. About a fourth of the
company is "IT", and maybe another fourth is operations or customer
service.
I was in IT.
Shortly after I started the company hired a new director of software
engineering; he put out a number of initiatives. One of these
initiatives was to form a sort of "quality council", or engineering
sub-committee. Ideally, maybe, we might join with the project
management and analysis people, and possibly the sysadmin and hardware
people, to create an "IT" quality committee, but for the now, the group
would be limited to the software developers and database guys.
Now exactly what the director was planning, I'm not sure. And I don't want to get into the business of divining
intent; it's so easy to come up with motives for someone that could be wrong, yet might explain behavior.
(
Sidebar: Consider the co-worker who is always shrugging off
work, coming in late, and blaming other people. You might think the guy
is just a jerk, and expect him to try to paw off work on you while
subtly re-defining his deliverables to be as small as possible. Your
predictions about the guy might even be right ... until you find out his
wife died in a car accident the week you were hired, and his son has
cancer. The point here is that the way we see the world based on intent
might even work - and be horrible wrong. So I am reluctant to judge.
Now, back to our show ...)
What I do know is that he made a public announcement that, as a department, we were pursing
CMMI Level 3 (or something equivalent), and that to do this, we were going to bring in a consultant for ninety days or so to help us out.
Enter BJ the consultant. Again, I don't want to get into intent, but I can describe behavior.
In the first month the consultant was here, he arranged meetings with
developers and our "people people" branch, the analysts and project
managers. He asked them what they were working on, and about the state
of our projects. He pulled out a two-hundred question questionnaire
about the state of IT, and wanted everyone in the department to answer
it. (We ended up having the quality committee for software engineering,
the folks who would take over after BJ left, doing the questionnaire
collaboratively in about an hour. My job was to lead that committee.)
I asked him to get involved in a few projects, to show and teach "risk
management by osmosis", and BJ did manage to attend one meeting where
the technical staff pushed back on requirements that were not "ready to
go yet." Otherwise, BJ did not "have the time" to get involved in
actual projects.
And that's about it.
After two weeks, I was getting restless. BJ pointed out that you
can't make a plan to improve unless you know the lay of the land, so you
need to start with an
assessment. You know "unless you know
where you are, a map won't help" sort of stuff. Come to think of it,
BJ had several little statements he used. Things like "Becoming a
learning organization is the hallmark of Agility" or "We will become a
zero defects organization."
That zero defects line sort of got to me. I mean, I knew a little bit
about software development, and zero defects has a price -- consider the
software on the space shuttle -- and I didn't think our organization
was willing to pay that price. Moreover, I was pretty sure that no one
had ever told the guy that zero defects was our goal.
What was going on here?
Fish or Cut Bait
After three weeks of working with the guy, I still didn't know where we
were headed. We didn't have a plan. It's hard to explain the sort of
way he had of speaking. You'd walk away, thinking you had the whole
thing figured out, then suddenly realize that he hadn't actually
committed to anything specific.
We even met with my boss, the manager of application development, to
figure out what BJ was going to have done when. He wrote down some
dates on a piece of paper. I remember walking out with my boss in the
rain; she said something like "well, now we have the guy. He has to
deliver something by October 15th, or else we have him."
Suddenly I realized: No he doesn't. The meeting didn't change
anything. The guy was going to continue doing whatever he was doing,
and, on October 15th, he was going to deliver some two-page report or a
powerpoint or something. For example: He might deliver a "finding of
gaps", then need a month to write a proposal to address the gaps ...
But it never got that far. BJ got another job offer. He was scheduled
to leave in three weeks, to terminate the contract early. So we
interviewed the next guy from the offshore company to be his
replacement.
In the phone interview, I asked what the guy would actually do. He
replied "well, it depends - I don't even know where the gaps are.
First we need to start with an assessment ..."
It would be hilarious ... if only it weren't so tragic.
It's a long story. I'll try to make it short, really.
So we fired BJ
Well, ok, that's a little too short. First, we told the consulting
company that no, we wouldn't be taking their replacement. It was my job
to tell BJ that we would not need his services for the duration; that
he could leave early for the new job.
Then BJ did the one thing that impressed me in his entire term of
service - he told me that he did not want to leave the job unfinished.
Yes, he could leave today, but he would like to come back in two weeks,
when his term would have been up, to present his findings of fact to
management.
That impressed me. Really. I mean, by this time, the guy probably
realizes that we're unhappy with his services. For that matter, we're
going to call his company, from whom we place dozens of people
full-time, and ask them not to bother to bill us for the services he did
render ... and yet he wants to come back and give us some value.
Good for you, BJ.
Two weeks go by, I line up everyone in software engineering from team leads to the director, and BJ makes his presentation.
The Presentation
Sixty-odd powerpoint slides. Conceptual frameworks, maturity models,
process improvement stuff, IT standards, all kinds of stuff. Plus some
cliches.
Really, it was like the guy got some generic slideshows from the
software engineering institute and pasted them all together. It was ...
odd. About ten minutes in, our management team started to ask for
"meat", or for "actionable items"; the guy skipped a few slides and said
"it's coming" (I really can't make this stuff up.)
Then we had it: Three slides. White background, plain black text, no
graphics, you could tell these were the ones BJ made, and they
basically identified the frictions and fractions of the departments;
that we had pain points in identifying requirements, with project
schedules, or in understanding how the role of the analyst was different
than the role of the project manager, and so on. For the first two
slides, management literally said "tell us something we didn't all ready
know."
On the third slide, someone say "Now that
is interesting." On the way
out, another manager said "that third slide actually told us something new."
Wait ... what?
A month on-site, taking probably three person-months of staff time, at $120 an hour ... for a slide? For four bullet points?
Now again, I get in trouble when I assume intent. It is always possible
that my understanding is wrong. A few years later, when I told his
story to a friend, he replied "oh, yeah. BJ was doing the
consultant's gambit. It makes perfect sense."
The Consultant's Gambit
Say you are a complete stranger to a company and are brought in to
consult. Say the organization has at least three or four layers of
management. It's probably screwed up, right? I mean, it has humans in
it. People do what they think they need to in order to advance. they
are selfish, and management is probably sufficiently disconnected from
the actual work to "miss" some things. (That's why they turn to gantt
charts, templates, process and metrics, right -- the appearance of
control?)
So you make a bet. The organization is probably screwed up. You can
come in, ask the do-ers some questions about what is wrong ad what they
would do to fix it, then present those ideas to management. For that
matter, you might be able to
just see what's wrong; obvious problems could exist that can't be recognized because of the culture. Or you might know enough
rhetoric to fake it. ("what? You don't write down all your test cases?
What? You don't count your bugs?", etc.)
The funny thing is, this kind of consultant has some chance to do good.
I mean, the people at the bottom may very well know what is wrong and
have ideas for how to fix it. If the consultant really does "just"
listen and pass on ideas without injecting rhetoric, that might add a lot of value. (It might be value that a college intern could add, but that's a different blog post.)
Sadly, too often.
I've seen consultants that come in, throw around some cliches, create a
powerppoint slide or a 3-ring binder, then disappear.
How can you tell
the good ones?
Separating the wheat from the chaff
First, ask the consultant to make actual project contributions. Next,
ask them questions -- ask for guidance. It's fine for the consultant to
ask clarifying questions, but when every question comes back with an answer "what do you think?" you may have a gambit-player on your hands.
The thing is, realizing you have a player on your hands is
too late. So you'll want to ask the right questions in the hiring interview -- specifics about how prior engagements were structured and what the consultant actually did. If he claims to "like to get my hands dirty", ask what that means -- is it contributing on requirements, on testing, writing SQL, setting up servers -- what?
I can do more blog posts on consulting if you'd like; I certainly have energy to explore exactly what a software (test?) consultant might be and why you might want to use one. Or not; the comments feature is your friend. But before you leave, do me a favor and check out
Brian Marick's ideal consulting gig, and compare and contrast that with BJ, and ask yourself -- which one would be a better for for you? And if it's Brian ... why is that the minority?
I've got more to say, it you want to hear it. If not, there's a new test conference coming up in Nashville in March, interviews of testers to gather, oh, and I'm working on book on how to reduce the cost of testing.
Plenty more to come -- what would you like to hear about tomorrow?