The Economics of Strategy

---

A good blog read on this topic -- the Economics of Strategy -- is found at herdingcats
written by Glen Alleman.

 

In his posting, Alleman makes a couple of important points:

• There are many tactical actions that can be taken within a project -- like attention to risk management -- that ultimately have strategic outcomes for the business: enhanced profit on the income statement, sustainable free cash flow, and a stronger balance sheet
  
• Likewise, there are many tactical decisions about product features and functions that will enhance customer value but have only marginal impact on business outcomes, and yet have strategic consequences for the business. See: customer loyalty

Four elements of strategy

Of course, attention to strategic finance and customer satisfaction are two of four components of a good business strategy. 

A third is development of the business capability and capacity to innovate and produce. Typically, there is a cost-benefit and cost-outcome analysis that is required to figure out how much to invest in training and development of people, and how many robots to purchase.

A fourth is just do what you do all the better. That is, invest in operational effectiveness -- lower overhead, fewer reworks, more throughput for the dollar.

All four contribute

So, when you are considering all economics contributions to or effects on strategy, the balanced scorecard of finance, customer satisfaction with the value delivered, investments in organizational development, and improvement in the economics of throughput

---

Buy them at any online book retailer!

If the customer is not satisfied .....

---

If the customer is not satisfied ...
First question: How would you know if the customer is not satisfied? Is customer satisfaction one of your project metrics? Good grief, I hope so! If not, you might want to consider this little ditty:
 

• If the customer is not satisfied, they may not want to pay.
• If they are not successful, they cannot pay.
• If they are not more successful than they already were, why should they [pay]?

Niels Malotaux

Paraphrased a bit

---

Buy them at any online book retailer!

Agile C.R.A.C.K. customers

---

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Spiral methodology, writes about the ideal customer for agile projects.

Boehm's perspective:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

More from Boehm on Agile:
Take a look at other Boehm'isms about agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

---

Buy them at any online book retailer!

Leveraging customer relationships

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

Normally the SPOC for a business development effort.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive,
Business, Technical and Users requirements – Securing the sign off on the
requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities,
in order of increasing importance, and determining the “fit to need” alignment of
the requirements
d. Map solution requirements to the vendor solution/product portfolio, and
determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team,
and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as
needed in various verticals that are needed to address the solution design and
product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

Buy them at any online book retailer!

C.R.A.C.K. customers

---

Barry Boehm on the C.R.A.C.K. Customer

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

Take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

On customer satisfaction

---

Is customer satisfaction one of your project metrics. Good grief, I hope so! If not, you might want to consider this little ditty:
 

•  “If the customer is not satisfied, they may not want to pay for our efforts.
• If they are not successful, they cannot pay.
• If they are not more successful than they already were, why should they [pay]?”

Niels Malotaux

Paraphrased a bit

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Firing your client -- free at last?

---

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

This essay gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:

• They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
• They say it's an easy job they can do themselves.. unless you want to be micromanaged
• They want to talk about themselves instead of the job task... unless you want to be their counselor
• They say they've tried to get the job done with many others, and they all failed.. so might you!
• Rude, insensitive behavior.. unless you like the bad-ass type
• Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Keeping a sense of Fidelity

---

Fidelity, faithfulness, and commitment often seem to be the tension between:

• What the customer/sponsor/user want, and
• What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:

• If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
• If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
• Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)

Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

So, who's responsible for Customer?

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive, Business, Technical and Users requirements.
Securing the sign off on the requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities, in order of increasing importance, and determining the “fit to need” alignment of the requirements
d. Map solution requirements to the vendor solution/product portfolio, and determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team, and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as needed in various verticals that are needed to address the solution design and product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The voice of the customer and system engineering

---

General James F Amos, in a 2011 interview says that he had appointed himself player-coach (his phrase) on a number of troubled projects. That caught my eye: I had to read further.

 Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!

And of course he's right: if the Marines had waited 14 years for major solutions, like the mine resistant reconnaissance vehicle developed for Iraq, it would have never arrived in time.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering.  In the post war 1950s, Schrieve's team pretty much invented how to do military weapons programs -- the exception being the WW II program for the 'bomb', a program that Schriever did not participate in.

In the book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Customer focus -- a quotation

---

If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he al­ready was, why should he pay?

Niels Malotaux

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

C-R-A-C-K (as in Agile customer)

---

What's a CRACK Agile customer you might ask?

 

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:

 

• Collaborative: they will engage with their customer peers and with the development team
• Representative: they know the product or system requirements and can represent their constituents accurately
• Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
• Committed: they take their job seriously and make every effort to advance project success
• Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation

Good grief! Why keep this in the agile space? Doesn't eveyone want a CRACK customer? How could it be otherwise?

If you're curious about the agile/traditional thing, and agile stuff in general, take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004. It's got some really good things to offer.

 

Bookmark this on Delicious

Value stream mapping

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

So much for the customer

This is probably not newsworthy, but it's nevertheless telling:

"[A journalist recently] ...  asked what consumer and market research Apple had done to guide the development of the new products."

“None, it isn’t the consumers’ job to know what they want.”

Steve Jobs
As reported by Steve Lohr

Actually, this behavior is not unique to Apple. Sony has been similarly credited, the Walkman being a most prominent example.

Is this good guidance for project managers?

Some thoughts:

• It's hard to argue with success
• There are not many like Steve Jobs!
• Prima facia: You don't need the customer embedded in the team to build great products

My opinion:

• Go for it! Ask the customer
• If you're bidding competitively, you'd better ask the customer!
• Pay attention, and learn whom you can trust
• If the situation allows, ask after a prototype exists ... Facebook, GroupOn anyone?
• But don't ask too many, in less you are prepared to handle the "wisdom of the crowds"! [And this applies in the competitive environment also]

 Bookmark this on Delicious    

Are you on LinkedIn?    Share this article with your network by clicking on the link.