Resume tic's

---

Want a job in "big business", or want to pursue "gigs" with the big guys?
Here's some resume tic's from the those that know the General Motors' needs:

The "new" GM will want workers who are highly creative and capable of working autonomously as well as collaboratively. 

The future employee will take initiative and have a strong technology background, good communication skills, and project management capability

Well hello! That's a prescription right out of the PM playbook

• Communicate
• Collaborate
• Create
• And, did I mention: initiate!

---

Buy them at any online book retailer!

Multi-lingualism

---

MIT is to open a new College of Computing.
That's nice for them

Of note, however, is this bit from L. Rafael Reif, MIT President, as quoted in the press

The goal of the college is to "educate bilinguals of the future"
And, to be clear, bilinguals are people whose 'other interests' are -- among others -- biology, chemistry, politics, history, and linguistics who are skilled in the techniques of modern computing that can be applied to them

Who said IT guys are one-dimensional? No longer; they can be bilingual
And, by extension, so can the project managers of the world be something other than PM-nerds
We can learn other languages as well!

Better yet: we can be multi-dimensional in both knowledge and wisdom -- what a concept!

Never stop learning is probably the right take-away!

---

Buy them at any online book retailer!

Great project management

---

Give pause to this insight:

"The mark of a great ship handler is never getting into a situation requiring great ship handling"

Admiral Ernest J. King

The paraphrase is obvious:

• The mark of a great project manager is never getting into a situation requiring great great project management

---

Buy them at any online book retailer!

Initiative and independent action

---

From Viscount Nelson, victorious British commander in chief at the naval battle of Trafalgar, we get this insight for initiative and independent action, as described by Admiral James Stavridis in his book "Sea Power":

Nelson knew he would not have clear and instantaneous communication ... [making] precise command and control impossible.
As [Nelson] said in his [planning] memorandum: "Something must be left to chance; nothing is sure ... "
"In case signals can neither be seen or perfectly understood, no captain can do very wrong if he places his ship along side the enemy ..."

So, there's some good stuff there for project managers:

• Don't lean heavily on the idea you will always be in touch when it matters
• Accept the idea that command and control systems have their limits; other processes work also
• Do think it through and commit to a plan -- even though the plan itself may not survive first contact with project reality [some would call this making an estimate .... gasp!]
• Set expectations and then unambiguously delegate authority to meet those expectations

Something to be avoided:

• Nelson was killed in the battle, taking one risk too many 

---

Buy them at any online book retailer!

Blitz-scaling

---

So, I'm just catching up with the buzz about blitz-scaling, the business model that says:

Get to scale fast! Actually, get to even larger scale even faster.
Blitz your way there!
Only the fastest to scale wins; there's hardly a spot for number two

One might ask: What's the debt and debris accumulated in blitzing scale?

Reid Hoffman has an answer in his book, titled no less than: "Blitzscaling: The lightning-fast way to massively valuable companies"

• Conventional process-oriented decision making supported by "facts" and analysis of risk, discounted cash flow and the like, are out
• What's in is speed, decisions based on instinct and partial data, and a willingness to pay the downside if risks don't work out

Ok, almost anyone could imagine that deregulating is going to allow speed with some broken glass along the way.
In the past Reid argues, business put a high value on not breaking the glass.
Efficient and predictable processes with predictable outcomes was king.

• Remember the "Theory of Constraints" developed in the early '80s: Efficiency in resource utilization was the answer to better business
• Remember: the customer is always right?
• Remember: product quality counts very high --- 1950 quality ideas and 1990 error management (Defined process control; Quality is free, Six-sigma etc)

According to Reid: all good stuff, but too slow!

• Speed is almost axiomatically opposite efficiency. Many resources will be wasted when you go as fast as you can
• Don't let the customer get in the way; customers are notoriously cautious adopters
• Quality can come later; get a product out there and set the frame 

If you read my post on the evolution of Agile, you'll recognize the connectivity of blitz-to-scale with the evolved principles

---

Buy them at any online book retailer!

Agile: revolution to evolution

---

20 odd years ago, Agile was a revolution in methodology and some say a revolution in business objectives, all set down in some now-well-known principles from the last '90s.

But, has there not been an evolution in the last two decades?

Mike Cohn, a spearhead in the Scrum world to be sure, says this:

Originally, agile meant valuing individuals and interactions, working software, customer collaboration, and responding to change.

Agile was about cross-functional teams working closely together to innovate new products or solutions that couldn’t have been developed any other way.

These days agile seems to be about

• Improving productivity,
• Reducing work in process,
• Increasing velocity in any way possible,
• Holding teams accountable for finishing everything they say they will, and,
• Doing just enough that an organization can call itself agile without really being agile.

He's probably right on this.
So, what happened?

For agile to be anything other than a cottage industry, it had to marry up with serious business people who put up the money and expect effective functional results in-line with business objectives.

And, being a capitalist economy, projects have always had to line up with capitalist objectives:

• Relentless drive to reduce cost, 
• Produce more, and 
• Drive the bottom line (profit margin)

The soft side of agile, the camaraderie of harmonious teams focused on product by and large, when modulated by capitalism, comes out looking like the Cohn view of evolutionary Agile.

It's not personal, it's business!

---

Buy them at any online book retailer!

Alice, the Cat, and Agile

---

I've heard it many times that this little ditty is the essence of why Agile is problematic with its dearth of plans, estimates, etc:

"Would you tell me, please which way I ought to go from here?
'That depends a good deal on where you want to get to,' said the Cat.
'I don't much care,' said Alice.
'Then it doesn't matter which way you go,' said the Cat.
'So long as I get SOMEWHERE,' Alice added as an explanation.
'Oh, you're sure to do that,' said the Cat"

- Lewis Carrol from "Alice's Adventures in Wonderland"

Not so fast!

• No Agile project is sans a Narrative or Vision or epoch story
• No Agile project is without some tie to the business, and thus a business outcome or influence,
• No Agile project is without some commitment of resources from the business -- folks I know don't work for free

On the other hand

• Some Agile projects have trouble getting off the stage; to wit: Are we done yet?
• Some Agile projects spend the money and get little done, certainly little for the business
• All Agile projects benefit from some degree of planning and estimating, if only to frame the project onto the right first step.

Alice and the Cat are not Agilists!

---

Buy them at any online book retailer!

The Agile Canon

---

I thought this posting on the "Agile Canon" was worthy of passing along in its entirety. So, there's the link for a pretty good read on the most important elements of a canon that all should be interested in adopting:

1. Measure Economic Progress: Outcomes, means to measure, means to forecast
2. Proactively Experiment to Improve: Assess options, embrace diversity and variability, execute experiments to improve
3. Limit Work in Process: Visibly track work by category, communication delays are a form of WIP
4. Embrace Collective Responsibility: don't blame others, don't blame others by name, don't blame the circumstances, accept and embrace responsibility for outcomes
5. Solve Systemic Problems: Be de-constructive to the root cause, be aware of both static and dynamic influences

---

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!

Does software actually fail?

---

Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail": Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults": Never fails is as above; faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults. To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.

Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability. And that can’t be done. Here’s an example to show it.

Consider deterministic software S with the specification that, on input i, where i is a natural number between 1 and 20 inclusive, it outputs i. And on any other input whatsoever, it outputs X. What software S actually does is, on input i, where i is a natural number between 1 and 19 inclusive, it outputs i. When input 20, it outputs 3. And on any other input whatsoever, it outputs X. So S is reliable – it does what is wanted – on all inputs except 20. And, executing on input 20, pardon me for saying so, it fails.

That failure has a cause, and that cause or causes lie somehow in the logic of the software, which is why IEC 61508 calls software failures “systematic”. And that cause or causes is invariant with S: if you are executing S, they are present, and just the same as they are during any other execution of S.

But the reliability of S, namely how often, or how many times in so many demands, S fails, depends obviously on how many times, how often, you give it “20″ as input. If you always give is “20″, S’s reliability is 0%. If you never give it “20″, S’s reliability is 100%. And you can, by feeding it “20″ proportionately, make that any percentage you like between 0% and 100%. The reliability of S is obviously dependent on the distribution of inputs. And it is equally obviously not functionally dependent on the fault(s) = the internal causes of the failure behavior, because that/those remain constant.

---

Buy them at any online book retailer!