Difference between Building Something and Managing Something

The ever enlightening Art Petty has a post over at Tanveer Naseer's blog that got me thinking.  What is the difference between building something and managing something?

To me, when you're building something that hasn't existed previously, there are a series of steps what you're building goes through:

1. Ok - what ever you're building is "Ok", meaning it solves the problem for which you're building a solution.
2. Better - The thing you've built solved the problem and now you've improved it.
3. Well - You thing does the job well.  For all practical purposes, that means you show it to people without apologizing.
4. Good - People are impressed enough with what you've built that they show it to other people and say it's good.

There are levels above good, but they are refinements that are distinct without necessarily being different.

Now, if you are managing something, it already exists.  Hopefully it's "Good", more likely it's "Ok" and could be made "better".  The import point is that it's purpose for existing has already been identified.

In this case, managing something is about refinement and continuity.  Maybe there are parts that are replaced, tuned or refined, but continuity is the defining characteristic.

Maybe it can be better thought of like this:  Building is about creation, managing is about continuing.  

Things That are Near Though Distant

Sei Shonagon wrote "The Pillow Book" between 989 and somewhere a little after 1,000 AD.  She offers a picture of what life was like in the Japanese Royal Court and what life was like for an ambitious woman a thousand years ago.  You also get a clear picture of what she was like.  She was good looking, and knew it.  She was intelligent and not shy about competing with men or women to prove it.  She enjoyed her lovers, rarely passed up entertaining experiences and could be a little bitchy when the spirit moved her.  My kind of woman! [Editor: Get to the point.  Let's be honest, you have no more chance with a woman who died a thousand year ago than you do with one alive today...]

What's interesting is what has changed and what hasn't.  I offer two of her entries as examples:

109. Tthings That are Distant Though Near
 - Festivals celebrated near the palace. *
 - Relations between brothers, sisters and other members of a family who do not love each other.
 - The zigzag path leading up to the temple at Kurama.
 - The last day of the Twelfth Month and the first of the First. **

110. Things That are Near Though Distant
 - Paradise
 - The course of a sail boat.
 - Relations between a man and a woman.

I would add one more to the list of "Near Though Distant" - Project completion.

It's What They Do Know that Just Ain't So

Maison Fleury  had a fantastic post about how people misunderstand mortgage laws in America and are making bad decisions because of it.  He reminded me of the American humorist, Will Rogers statement: "It's not what people don't know that hurts them. It's what they do know that just ain't so."

In our brave new world, how is that idea going to effect individuals making financial decisions, supra-national organizations like the European Union making financial-political-structural decisions, countries working out the economics of fiat money or central bankers dealing with currency manipulation?

In all each of these situations, people grew up with a particular paradigm for interacting the world. And surely they were successful because they made good decisions working within that paradigm. However, what if the world has changed and the old paradigms are no longer helpful?

To be successful today, will we not only have to escape the old paradigms, but also understand new ones before we can move ahead. 

Those who see the world more clearly have an advantage over those who don't. Which individuals, countries or organizations will adjust more rapidly and appropriately?

"It's not what people don't know that hurts them. It's what they do know that just ain't so."

Why Are You Reaching that Conclusion?

A friend of mine's roof has a hole in it.  I was talking with him the other day and he commented that the upcoming season is supposed to be the driest on record.  Maybe he researched weather patterns, looked at prediction analysis and cross-referenced that with the Farmers Almanac.  Or maybe he reached that conclusion because if anything else happens, he has a real problem.

Why I love RFPs

Dave Bressler has a wonderful post about fixing the RFP process.  He looks at it from the vendor perspective.  While I agree with many of Dave's suggestions, I'd like to offer my reasons for loving RFPs.  Of course, I'm predominately looking at it from the client perspective.

Clearly Defined Project Purpose
RFPs force the stakeholders to think about, write out, order and agree what the goals are for the project/software/etc.  Companies will often have very vague reasons for wanting to do something and even less understanding of how to evaluate if its successful.  Forcing executives to agree to and state the purpose of the exercise is critical.  Believe it or not, RFPs are a great way of doing this, if for no other reason than the fact that stakeholders usually have to go to the CFO or Board to get approval to spend that kind of money.  (Note: The longer I've worked in software, the more I've come to love CFOs.)

Checklist for Decision Making
RFPs provides a checklist that stakeholders have to agree to and then use to justify why they want to go with a particular solution.  Many times on the client side, you only get limited amounts of time from critical stakeholders.  Whatever they profess, key stakeholders rarely devote the type of time a major project needs.

First having the meeting to agree to the checklist and discuss the importance of different items is key from an education perspective.  Then when it comes for vendor evaluations, which is often months later, the checklist provides structure from which to have discussions and make evaluations/decisions.

Lacking the structure of a checklist with which to evaluate multiple solutions, stakeholders will often latch onto the first solution they see that seems to address their needs. **please see note below.

Understanding what You're Buying
RFPs go a long way towards addressing the asymmetries in understanding and product expertise.  Vendors know infinitely more about the products and market space than prospective clients.  Hearing different vendors answer the same questions is extremely educational for stakeholders.  For example, often times a stakeholder won't understand answers being given, but if three vendors answer a question in one way, while one vendor provides a completely different answer; one gets an opportunity to have real discussion about why.

Determing the Price to Pay
Price is rarely a deciding factor, but having multiple bids is critical for getting a good price from the vendor you do select.  Especially if the selection period covers one vendor's year-end or quarter-end.  Often times one vendor will drop their price to a ridiculous level because that salesperson needs the sale for some reason.

There's a great line from Warren Buffett: "You can't be any smarter than the dumbest competitor you're competing against."  When there are equivalent products and one vendor is willing to drop their price by say 80%, even if you'd never select that vendor, other vendors have to drop their price to an equivalent level.

Understand, price has nothing to do with selecting who you're going to go with, but having multiple bids has everything to do with how much you pay for the product you've selected.

I hope this helps you understand why I love RFPs so much.

**Note: I don't think people working for vendors fully understand the importance of presenting first.  Most often in client firms, there's really only one way discussed to do something.  So the first person who can suggest a viable way to do it gets to do it that way.  So managers/executives are "trained" to go with whatever way they see that works first and move forward rapidly with it.  There is a huge advantage to being the first vendor who presents.