Agile in the infrastructure domain

"They" say agile isn't for hardware. Perhaps so. But one of my agile project management students made this comment about agile in the IT infrastructure domain. He says he wants to:

...... incorporate a hybrid (traditional/agile) methodology in the IT infrastructure (servers, networks, etc) side of the business because I believe it is a huge competitive advantage in the managed services industry to show value earlier than traditional PM can do.

He goes on with this bit:

I have been finding that by incorporating the iterative, phased approach from agile allows each phase to use the traditional externally dependant waterfall method.

It shortens the original planning phase, since it is now distributed accross phases, reduces errors in estimating because each phase is estimate individually, handles change better, and delivers a better end result.

Could an agilist say it better? Of course this is not science; it's just one person's opinion with little benchmarking behind it. Nevertheless, it's instructive that agile ideas are not just about software where it's relatively easier to change things, and thus things get changed. In the more physical world of hardware, there is a place for agile ideas.

Bookmark this on Delicious

Monitor and Control

If there's one behavior that's almost an axiom in the project management business it's "monitor and control" the project

And the tool guys are all over this, offering all manner of tools for monitoring, and some tools for controlling.

So, what is the "monitor and control" agenda? Here's my list (without the usual references to project plans, earned value method, IMP/IMS, etc. All good practices to be sure, but too specific for the point I am trying to make):

Project monitoring (and monitoring tools and systems) has these functionalities:

• Sense, measure, and gather metric data
• Interpret data and compare to milestones, budget, goals
• Report data (meetings, dashboards, reports)

Project control

• Impose or remove constraints, to include authority, responsibilities, policies, standards, rules, work flow
• Allocate or de-allocate resources (money, staff, tools, environment)
• Plan and execute responses to monitoring data (act on the monitoring)

Monitor and control should form a closed loop (I'm all about closed loops. Open loops are dangerous because it means that whoever is in charge of input is clueless about outputs, and vice versa. You can't really control what you monitor if the loop doesn't close. And, of course it has to be timely: a poorly phased loop actually causes more trouble than it avoids)

• Plan
• Do
• Monitor the 'do'
• Control according to the monitor data
• Monitor the control activity

And go around this loop monitor-control-monitor as many times as necessary
Of course, at some point it may be necessary to re-plan the baseline

Bookmark this on Delicious

Good will

"Good will" is an accounting term. It means, in effect, the intangible worth of something that is given a monetized value. You won't find good will on the balance sheet.  It comes up all the time when valuing a company for sale. Good will is the value of the relationship that a company has in the market place.

So, we aren't accountants here, so what's the point?

The point is that intangible value appears a lot in the value proposition of projects. And, good will comes up a lot in change management exercises. We often call good will "soft benefits". Soft benefits have a dubious cause and effect. Yes, we know there's some correlation (things move together) but one always wonders if they are cause and effect (A moves because B moves). What's the alternative? The alternative is a 'confounding factor': A is moved by C, but so is B, thus A and B move together.

This may be more information than you need.

Here's a change management example of 'good will' from one of my students:

The strong success that we realized came through recognizing the organizational significance of the 'front-line, Level 1 operations guys', whose positions had at one time been considered prime for outsourcing.

Once we helped leadership to recognize the breadth of these guys' scope, and good work and goodwill that they had facilitated, we were able to make the strong case that thier roles were much more critical than had previously been understood.

Making the case for these guys helped to bring their loyal support in terms of understanding the 'as is' and helping to drive out and optimize the 'to be.' Transparency prevailed and the outcome was definitely a win-win situation.

Win-win! You gotta like it when a plan comes together

Bookmark this on Delicious

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

FOURTH OF JULY

---

This office is closed on 4 July due to circumstances beyond our control

Sign on British Consulate in the USA

Bookmark this on Delicious

That moral hazard thing

Moral hazard: we learn these from the knowledge base at wikipedia:

A moral hazard is a situation where there is a tendency [by a work package manager, for example] to take undue risks because the costs are not borne by the party taking the risk.

And, somewhat related, we are informed that "adverse selection" is described this way:

Adverse selection is a situation where an individual's demand for [relief from risk] is positively correlated with the individual's risk of loss (e.g. higher risks buy more insurance), and the [project manager] is unable to allow for this correlation in the [project plan]

---

This discussion about moral hazard came up with some of my students in my Agile PM class. We were discussing how tightly to schedule a project.

My thinking: a plan without slack is not really a plan; it's a hope.

Two ways to get slack planned into the project baseline:

1. Assume there's always going to be "labor loss"... That is, no one can really work 100% of the time they are schedule to work. It just doesn't ever seem to work that way. From dental appointments to coffee bar chat, some labor is lost. I always estimate 15%
2. Put in what I call "pipeline buffers", to allow some "breathing" in the schedule plan. (I may call it pipeline buffers, but others call it critical chain method) 

(Many reading this blog may have never seen an install of pipelines; nevertheless, I'll describe it by saying that what they do is put in expansion joints every few lengths by letting the pipe zig and then zag. These zig zags absorb the changing length of the pipe with temperature, something like an accordion, and something you have to worry about in the physical world)

So, now moral hazard: the team knows there is slack built-in. In the agile business, we don't schedule for more than 85% of velocity, and we always put in a zero activity iteration before every release (a release is some number of iteration's deliverables). If the team knows this, it creates a moral hazard. They know they can use the slack without having to pay the price of the longer schedule.

And, that creates the correlation of the adverse selection dilemma: a demand for schedule relief on the one hand, and a correlation with the propensity of work packages and iterations to run over.

What's a PM to do to fight moral hazard? Here are a few ideas:

• Incentives to do good, i.e. pay for performance (or 'show me the money')
• Penalties if the schedule is blown
• Keep the labor loss to yourself; that just happens. No point in offering it up to the general population
• Make it hard to use the buffer time (after all, the PM should be in charge of constraints, not the inmates)

In effect, any schedule that's going to work has got some slack (some room to zig and zag)

About architecture

I probably misnamed this posting. It's as much about architecture as it is about the architect.

In the fifteenth century, an architect was a liberal arts guy with an eye for structure, symmetry, and form. Consider this passage from a description of the time:

A true architect can't be just a master of his trade. He had to be a well-rounded person....let him be educated, skillful with the pencil, instructed in geometry, know much about history, have followed the philosophers with attention, understand music, have some knowledge of medicine, and be acquainted with astronomy and the theory of the heavens".

(Of course, the pencil was not invented until late 16th century, so this passage from 100 years earlier is translated from the Latin or the Italian with some flourish)
And then we learn this:

Architecture is the defining art. It creates civilization. It constructs homes and lays out cities...It designs temples, revealing the will of the gods...It produces machines, guaranteeing victory in time of war and prosperity in time of peace... It builds empire

---

I will say this: some of my best software people were music majors. The poetry of music fits well the poetry of software.

Someone who builds empire!
I always wanted one of those. (I got no closer than being someone's Vice President, and we didn't have much of an empire to speak of)

But on a serious note, you can see these passages at work in some of the world's most interesting buildings (See: Opera House, Sydney), but also in some of the most elegant digital processing, to say nothing of the beauty of the recent Apple products.

Architecture is alive and well all around us and in every project, whether we acknowledge it or not. Everything we design or build has architecture--no structure, tangible or intangible, is without it--and every structure, whatever it is, is probably for the better if an architect has weighed in.

And, I've always advocated an architect on the project team. Now, I'm wondering how I ever did without one.

---

Quotes taken from "Da Vinci's Ghost" by Toby Lester



Bookmark this on Delicious

Authority v authoritarian

A couple of issues have recently come into my frame:

• Authority that becomes authoritarian
• Institutional sustainment that subsumes mission

Re the first point: authority. We're not talking about moral authority here; we're looking at positional authority and the potential abuses of positional authority. Who in the project domain has such a position? There are two:

• Project manager (or portfolio manager, or program manager or executive, depending on scale)
• Governance board (the policy and control guys, to include the project sponsor)

Every leader and every manager wants authority to back up their responsibilities. The Principle of Subsidiarity says put authority with the lowest competent authority in the pecking order. Everyone I know buys into that idea. But, for purposes of discussion, let's just stick with the PM.

What's expected of authority?

---

• Decisiveness: to include willingness and capability to make a decision, to make it timely, with to have sufficient moral authority that it has stickiness. (I hate it when it comes unstuck!)
• Order and protection: hold off the barbarians at the gate so that lean, effective work can be done
• One stop shopping: in other words, not a committee; and, the buck stops here and does not circulate in an endless do-loop of do-nothings
• Ability and willingness to say yes: (this is different from just making a decision) almost anyone in a bureaucracy can say no. That's what bureaucracy is for... to distribute and diversify the risk. Saying 'no' is the same as executing Plan A: Do nothing; often that is the low-risk thing to do. (See: Congress, US, 2012)
• Overcome the ankle biters: Closely related to 'saying yes', this is a little different: it means overruling all the staffers that say no.
• Keep your head when others don't: This is the pressure thing, and the antidote to panic. (See: Mann-Gulch tragedy)
• Transparency: this may be the meme of the day in the decision and authority business, but it's really code for fair and equitable treatment of all the constituents, though some will lose and some will win. It doesn't mean everybody gets a medal. And, this is different from lack of secrecy: Secret has its operational purpose in some spaces. (See: OSB, dead)

So, what happens when authority gets authoritarian?

• Intolerance for an alternate point of view.. that is, intolerance for decision inputs that are not convenient
• Intolerance for not adhering to doctrine... that is, our way or the highway
• Secrecy without operational purpose... no time to justify to the rif raff
• Panic decision making that leads to sacrifice of the little people
• Decision making without consideration of the sacrifice of the little people (See: Stalin, J) 
• No decision making at all... just stall
• No consultation because the decider is self-certain
• The inner circle is small... group think may be all there is

An interesting bit of trivia is given to us by Daniel Kahneman in his book "Thinking, fast and slow": in an authoritrian regime, people can be persuaded to accept a false message by the simple expedient of frequent repetition. Say it enough, and it's believed. And, you don't even have to repeat the whole message. Through a phenomenon known as "priming", the message is effectively repeated by just touching on the priming message.

What about institutional sustainment?

---

Instutional sustainment is about survival of the enterprise.
Fair enough
What if sustainment requires compromise of mission?
Now, we've got an issue. The legitimacy of the enterprise may hang in the balance.

Questions: Should the enterprise go out of business if it can't sustain the mission, or the other way around: change the mission to fit what's sustainable?

My experience is that in the private sector, it's the latter: change missions. That's ok; that's destructive innovation

In the public sector, perhaps it's not so simple: the mission may be everything. If this or that institution can't make a go of it, change the institution.

Now, the hard part is when authortitarian governance intersects with instutional sustainment. It may morph into sustaining the authority over both mission and institution. At the very least, the authoritarian will seek to sustain the structure that gives sustenance to power.

What's the remedy? Well, the Arab spring is one example. Upset elections are another. In the private sector, it's activist shareholders. In the project business, it's solidarity among team leaders.

Bottom line: it's good until it's bad. Then, it has to be resisted and fixed.

Bookmark this on Delicious