I worked pretty darned hard on a process improvement proposal and submitted it the other day.

“The other day” — the day they happily granted to me after I mentioned needing a weekend to complete and return from a week’s travel. “The other day” — a business week before they actually wanted to get the project under way. “The other day” — a day which capped several days’ worth of email volleys discussing ambiguous aspects of the RFP. “The other day” — the day I felt very good about what I learned and who I became as a result of crafting the more involved parts of the proposal. And finally, “The other day” — the day I truly knew that it would be a good thing if I didn’t win the bid.

The contract had many benefits. OK… not too many. OK… Two:

(1) Name-brand client.

(2) Lots of revenue from this business unit, with hints of possible follow-through with other business units of the same company.

(2.5 — sorry, cheating) I would have had the smaller of the roles — being PM, Lead Appraiser and CMMI Instructor, with much of the leg-work being done by contractors I was bringing to the table. Meaning, 2-3 people working at any given time and I wasn’t one of them.

They rejected our bid on price alone. They claimed to like our proposal which described in detail with a full project schedule what we’d do. They reject us after I tried no less than three (3) times to get them to cut us loose before I put in the effort to write the proposal. And, after each time, they insisted that we bid nonetheless and reconsider our position so that we’d be able to bid with integrity.

The problem, as I see it now, was that they could have us bid with integrity, but I don’t believe they had the freedom to request for the bid with complete integrity.

>>>> What does this have to do with Agile or CMMI?

Probably everything.

This prospective client is easily the epitome of “traditional” companies. Probably the epitome of non-agility. And, for all I know, also emulates the epitome of an organization pursuing CMMI for all the wrong reasons.

One thing I know for sure. They are contractors to the Federal Government, which most certainly isn’t known for treating IT contractors with any consistent professional respect or courtesy.

In many ways, both the prospect and the Feds have their hands tied by pesky things like Federal Acquisition Regulations (FAR) and so forth.

Though, one of the attributes (value propositions) of my company’s approach to CMMI (the Agile CMMI approach) is exactly why they wanted so strongly for my company to bid. Yet, when it came down to it, they couldn’t keep from allowing the you-know-what from rolling down hill and treating the offerors in much the same way their clients treat them. FAR or no FAR, when they had the opportunity to do otherwise, they chose to not break the self-defeating cycle of no-trust relationships.

The style of no-trust relationships includes (but are not limited to) the following attributes:
- planting much of the risk on the contractor,
- burdening the contractor with time-based AND milestone based status reports (as opposed to actually being involved and knowing what’s going on), and
- placing a due date for something the contractor has no control over (like their ability to make progress).

Yet, they wanted *us* to take the Agile approach to doing our work.

Can everyone see why this might not have been the best contract to win?

So I made sure that we covered ourselves by describing serious assumptions and then making our prices based on market rates. No discounts.

Since they never even came back to ask about the price, I’m completely satisfied that they didn’t choose us. The contract was to be Time & Materials, so all they saw was our rates along side what we expected to be the “maximum” hours/week at each rate. (Don’t forget that the minimum could have also been ZERO.)

Their loss… and better now than later.

As you can guess, I never had a good feeling about them as a client. I had a suspicion that they’d be difficult ((hence, all my push-back)) and I was looking for anything to prove me wrong. A more mature (and sincere) organization might’ve asked whether there might have been some misunderstanding about the work that led us to price ourselves the way we did. Again, which they never did.

There’s a difference between honesty and sincerity. One can be both, and that’s usually what we all expect. Those of us who operate with integrity have no trouble being both. I also believe one can be entirely and authentically one and not the other. I think I sensed that the prospect was being entirely honest, but not entirely sincere. There was something in the way they behaved. I must’ve been picking up on that in our interview, in their RFP, and in our email discussions.

In the end, they didn’t prove me wrong and I believe we are all much better off for it. Both for not being picked as well as for going through the exercise of creating the proposal.

I’m quite busy these days as it is, and, there will be other work, so I’m in no way worried.

I guess what readers can take-away from this experience is that for agile concepts to work, you must be able to sniff out whether you will truly be able to implement agile, or whether the prospect likes the sound of it, but isn’t ready (or willing, or able) to actually let it flourish. AND — you must be ready to let it go. You must be willing to stand your ground. You must be able to see the silver lining.

The Entinex CMMI FAQ with the obnoxious name is now up!

It’s not done — there are questions that have not yet been answered, in addition to a likely world of questions we haven’t thought of.

So… Please browse and be sure to send me any follow-ups, corrections or additional questions you’d like to see answered.

On another topic: I’m at a week-long an annual event called "Consultants Camp" in a spectacular middle-of-nowhere called Mt. Crested Butte, CO.  .  I’ll blog a little more about it later in the week.  It’s quite extra-ordinary.

In a recent pair of “sales” meetings with CMMI-related prospective clients we encountered an interesting but unfortunately not terribly surprising commonality.

In both meetings, we learned that we had provided the prospect(s) with completely new and highly valuable information about their choice/need to pursue CMMI practices. This is the kind of outcome we at Entinex like… to demonstrate our value by being proactive and educational in our meetings. “Sales” appointments for Entinex are as much our interview of the prospect as it is their interview of us.

Here’s the unfortunate but not terribly surprising commonality: Ours wasn’t the first company to be interviewed by either prospect. And, the “highly valuable information” we were providing our prospects, to us, was actually rather fundamental. In our minds, we can’t go forward with an engagement without the kind of knowledge from our clients that this “highly valuable information” provides *us* — let alone what it means for the client. We guess this is what sets us apart in our industry and what allows us to be more “agile” than our colleagues.

In fact, after communicating the information, each client’s response/reaction was “That’s a really good question. We don’t know the answer. We didn’t know we had a choice. We have a choice?”

So… what was this critical piece of information?

Basically, it’s along the lines of asking our prospects, “what exactly is *your* client asking from *you*? And, have you considered taking this alternate approach towards meeting that expectation?”

?8^(blank stare of bewilderment)

Yes, valued readers, we were simply taking our clients’ customers priorities and values into consideration before we set about to solve their process needs.
(The actual question, it seems, must be a very proprietary thing since we sound like the only company asking it, so… I must put on my “CEO hat” once in a while and actually try to keep to ourselves some modicum of market differentiation — you understand.)

We also noted that in each case, the prospect assumed we’d be giving them a formal, all-too-common Powerpoint song and dance. Again, that’s not our style, and, it’s not focusing our attention where it matters most: on the client. Instead we simply sat down to talk about their situation and needs and dive into what they already knew about their own needs, filling them in on what they need to know before making a decision to go forward, and how we’d go about ensuring that we meet their expectations.

Herein lies perhaps one of the keys (if not the crux) to helping CMMI and other process-types along in their ability to understand Agile, and implement process disciplines that can also be Agile. The focus must be on the customer’s needs.

So many of our CMMI colleagues (often called “competitors”) focus on the implementation of the CMMI as the goal, when really, it’s not. What *is* the goal is helping *our* clients meet *their* business needs, and by doing that we are focusing our efforts on the right things and on things that help our clients make (or save) money.

Looking beyond the commonly-held value-proposition that process improvement has its own ROI, if we as an industry ever want to be able to make positive inroads towards the “agilization” of CMMI and other process disciplines, we must make the paradigm shift towards the customer’s *business* needs, and not just their prima facia stated goals of “achieving CMMI ‘level’ X”.