Tuesday, January 17, 2017

Agile as a recursive methodology

In the past in my describing the adoption of Agile by conventionally trained managers and sponsors  I've described the "grand bargain" that has to be struck between sponsor and project. In effect, to repeat a bit, the "change" is first with the management paradigm of fixed-scope for a fixed price.
The essence of agile is unfixed scope -- tactically -- with a fixed scope (product framework) strategically.
Thus, by example which is simple enough we can all grasp the point, if we enter into a project to build a software shopping cart, a functional cart is the strategic objective of the project.
  • There is a general framework of functionality for such a cart agreed to in the business plan and the project charter, but
  • Many of the detailed feature/function/performance artifacts and objects will "emerge" as conversations go forward during the course of the project;
  • In other words, feedback of early deliverables will influence later deliverables.

In that sense, agile is a recursive methodology in that results are applied to the process of creating results. Thus the backlog somewhat begets the backlog -- a classic case of recursion.

Consequently, first: the agile backlog is constantly changing, at least in theory. In practice, a lot less so.

And, second: agile dismisses the idea of structured requirements (shalls and wills) so as to substitute "conversations", put down as vignettes in the form of stories and use cases.

Conversational requirements obviously requires some creative thinking about verification and validation (V-and-V) that is often part of a downstream activity, quite apart from development.

And, third: agile is realistic vis a vis a project of intangibles wherein there are really no physical limitations to constrain requirements.

All this takes us back to the challenge discussion: When is agile project "done"?
My counsel is: agile is a best value delivery, within constrained budget and time, of the highest priorities that the money will afford. All else, see V2.0.

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

Saturday, January 14, 2017

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

Wednesday, January 11, 2017

Leadership without impulse

Point: Impulsive and unpredictable are some leader's styles. Such keeps managers -- who revere plans -- off guard and even defensive, but it wreaks havoc on strategy (ever changing) and metrics (rebaselining at every turn).

Of course, your competitors may also be constantly off guard. In some businesses (start-ups, sports) and some military situations (See: General George Patton), "impulsive and unpredictable" is a great offense.

[Leadership] .. comprises a number of moral qualities among which may be mentioned: force;initiative; determination; a strong sense of justice; loyalty, to both superiors and subordinates; good judgment; generosity; self-possession; energy; decision.

The qualities of leadership inspire loyalty in one's subordinates; and this loyalty, accompanied by confidence in the [leader's] professional ability, gives [the leader] such an enthusiastic support from them that [the leader] is, in times of crisis, able to demand and accomplish what might appear to be the impossible.

History abounds with instances where great leaders have inspired such confidence and enthusiasm .... It requires both the moral qualities and the brains and knowledge to make a great leader. Both may be improved by application, study and reflection.

Raymond Spruance
Admiral, US Navy
Force commander at the Battle of Midway, June 1942


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

Sunday, January 8, 2017


If you're in the construction industry you probably know about and have experienced "design-build". Notice that there's a word missing after "design", to wit: competitive bidding.

Ooops, a typo? No, there is a body of knowledge around this that says that it's faster-cheaper for the same quality to go "design-build" than "design-competitve bid-build".

In effect, one team -- architect, general contractor, and owner rep -- carry the project all the way through.

The "faster" thing is obvious: there's a missing step, so the cycle has an inherent time advantage. The "cheaper" thing is not so obvious. Why should it be cheaper? There's nothing built in to drive the cost.

Best Value

Maybe it's not cheaper (though the track record over years seems to say it's cheaper), but it should be a best value project. 

That's the segue to: How do you decide which team is the team you are going to go with?  Certainly not lowest-cost, because the cost is not known until the design is known. So you decide on the basis of "best value"

Ah yes! Recall what value is: the best combination of quality, feature, and function that fits a budget. (Did I mention I wrote the book? "Maximizing Project Value". See the cover below)

And so, best value must mean value optimized for one or more of the variables. Of course, your bias will be different from mine, so your optimization will be different from mine. Nonetheless, each opportunity does have a "best value"

And, best value could be "lowest cost, otherwise acceptable". But, often it's not. There are other considerations other than cost. (We'll leave corruption off the list)

Public sector
But, if you're in the public sector, where the public expects probity when expending funds, how do you explain "best value"? Can it even work in the public sector?

Answer: Yes, it works.  In the U.S., some 20 states have made it legal, even desired, to go design-build. So the arguments that convince are out there.

If you read through the Wikipedia article under the link above, you'll see a pretty good to-and-fro on the good, the bad, and the marginally acceptable about design-build. There's even a design-build handbook and of course a design-build society.

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

Thursday, January 5, 2017

Information asymmetry

The playing field is not level; there are asymmetries all around.  Life is not fair, etc

The news, if it is news, is how asymmetry has crept into the project office or project management generally
  •  Not an efficient environment, meaning everyone does not have all the same information to make decisions. Some have access to 'big data' results; others do not
  • Price does not reflect marginal cost, meaning that project labor, at least, doesn't reflect a broad market cost for the next unit of labor; rather, labor is often paid a premium wage, justified as an investment in quality
  • Deals are blocked because of information asymmetry; opportunities go unfulfilled
  • Risks are assumed where risks may not exist, thus putting one project office in a disadvantage compared another PMO with a better handle on the situation. Why? Lack of credible information. Some have it; some do not.
  • Advertising ... sometimes called "signaling" --  distorts value, or redirects it.  A PMP, college degree, or other certification may create value for the certificate holder, but does it create value for the employer?
    Perhaps. But, there's a value-asymmetry at work. How many worthless, or more kindly worth-less-to-the-employer, PMPs are there who have the certificate, etc and thereby command the premium?
Some of the theory on this goes back to the work of George Akerlof, Michael Spence, and Joseph E. Stiglitz for their "analyses of markets with asymmetric information" for which they jointly won a Nobel Prize.

George Akerlof also wrote a book, "The Market for Lemons", in which he applied the 1970 used car market as example of the application of asymmetric information and the value distortions therefrom. Nobel prize. Anyone who has bought a used car understands this asymmetry between buyer and seller .... lemon or not? Only the buyer knows

And then, to layer on some more stuff, we have these:
  • Regulatory and statutory limitations on information sharing
  • Moral hazards (distortion of incentives or rewards)
  • Behavior ... are interests aligned? How can you even tell if information is asymmetric and the relationship is not efficient?
For more on this, check out this essay in Wikipedia: Principal-agent relationships -- construction industry

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

Monday, January 2, 2017

Project Management in the US Federal Agencies ... it's the law (now)

EXCEPT FOR DoD (there's always an exception for DoD)
In the U.S. federal agencies, project management is now the law:

You can read a summary of the bill, Program Management Improvement Accountability Act at this link

(Sec. 2) This bill establishes as additional functions of the Deputy Director for Management of the Office of Management and Budget (OMB) requirements to:
  • adopt and oversee implementation of government-wide standards, policies, and guidelines for program and project management for executive agencies;
  • chair the Program Management Policy Council (established by this Act);
  • establish standards and policies for executive agencies consistent with widely accepted standards for program and project management planning and delivery;
  • engage with the private sector to identify best practices in program and project management that would improve federal program and project management;
  • conduct portfolio reviews to address programs identified as high risk by the Government Accountability Office (GAO);
  • conduct portfolio reviews of agency programs at least annually to assess the quality and effectiveness of program management; and
  • establish a five-year strategic plan for program and project management.

The head of each federal agency ..... shall designate a Program Management Improvement Officer to implement agency program management policies and develop a strategy for enhancing the role of program managers within the agency. .....

The Program Management Policy Council is established within OMB to act as the principal interagency forum for improving agency practices related to program and project management.
Of course, DoD has had formal project management practices for years. And, this is not unique to the United States; other countries have similar statutes on the books.

In the age of Agile, one always wonders if the "fix" is more regulation. We'll see if this goes the way of the "cost benefit analysis" that was introduced to much fanfare some years ago, but had only marginal effects in the political environment of the federal agencies

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

Thursday, December 29, 2016

The requisite law of variety

Now, this could be a bit stuffy: "The Requisite Law of Variety"

But actually, it's an interesting concept to consider, to wit:
  • Essential Elements (E): these are outcomes, results, or other artifacts that you want to have some control over, even if you are Agile
  • Disturbances (D): these are events or actions that impact E .... usually there are a lot of these!
  • Regulation (R) or controls: these are the means or actions to limit the impact of D's. Even in the Agile world, there are some controls or protocols to regulate the pace and rhythm
  • Passive capacity (K): in effect, buffers and elasticity that limit the fragility of the system and allow for some absorption of D without breaking E 
The Law is a bit mystical when expressed as math, essentially saying:
"the the variety -- or set -- of the E's that you need control over should be greater than (1) the variety disturbances-reduced*-by-regulation and (2) further disturbances-reduced-by the buffers or elasticity."
* reduced, absorbed, or mitigated
Anthony Hodgson puts it this way:

[The Law of Variety] ... leads to the somewhat counterintuitive observation that the regulator must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E.

This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.

If you are familiar with the ideas of "anti-fragile" in system design, this last sentence is a good alternate phrasing for what makes systems anti-fragile, i.e. resilient

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