James Madison -- Federalist 51 and PMO

---

18th century political theorist James Madison was one of the authors of the Federalist Papers, a group of essays about republican (small "r") government on a nation-scale, written and intended to sway public opinion toward ratification of the U.S. constitution.

He is the author of Federalist 51, one of the most famous and cited of the 85 essays. It's about checks and balances in the main, separation of powers, etc.

But, for the PMO, here is a passage from 51 that seems to hit directly on the need for project governance, but governance that has definitive checks and balances -- "auxiliary precautions" that "oblige it to control itself" in Madison's words.

In other words, the quality of governance -- not too much concentrated power and not too many intrusions -- should not be dependent exclusively on good will -- angels governing -- especially where there is a lot at stake that could lead to nefarious acts

"But what is government itself but the greatest of all reflections on human nature?

If men were angels, no government would be necessary. If angels were to govern men, neither internal nor external controls would be necessary.

In framing a government which is to be administered by men over men, the greatest difficulty lies in this:

• You must first enable the government to control the governed; and in the next place oblige it to control itself. 

A dependence on people is no doubt the primary control on government, but experience has taught mankind the necessity of auxiliary precautions"

James Madison 

writing in Federalist 51, circa 1780's

---

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

Action and effort

---

"[There is] a critical balance that any organization has to manage -- the balance between freedom of action for the parts and unity of effort for the whole.
Too little autonomy for the parts leads to inaction, inflexibility, hesitation, and lost opportunities.
Too little unity of effort means that individual [organizational] achievement is not synchronized, exploited, or leveraged"

General Michael Hayden
"Playing to the Edge"

Although he didn't say it as such, Hayden was very close to the Principle of Subsidiarity when he spoke of autonomy for the parts, and he was speaking like a system engineer when he spoke of unity of effort of the whole, especially the recognition that sequencing, phasing, and complimentary interaction -- without setting off chaotic responses -- is essential for getting the most out of the parts arranged as a system.

---

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

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.

Some call it "de-cluttering". Don't hang onto the stuff you really aren't going to use.

And, of course de-cluttering the non-value add 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 contributes to making the customer deliverable a good thing in the customer's eyes; anything that makes the customer more successful; and anything that gives the customer the willingness and capacity to pay.

A lot of project and business stuff would not fit this definition directly. 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

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

Not-measurable predictions and forecasts

---

Not-measurable predictions and forecasts: ever made one? Actually, who hasn't?

There's personal safety in not being measurable. Indeed, you can fill space and take up time with blather that is not accountable: if what you forecast and predict are not measurable, but yet fill a space where a forecast is needed, what's the risk? Nobody can hold you accountable for it!

Actually, there is a risk, not usually found on the project risk register: Absence of accountability often begets exaggeration, if not also overconfidence and extremism, all of which may have measurable consequences.

And, so we read that others have gotten onto this idea also:

There is a familiar psychological mechanism at work here. [Studies] show that if people expect that others will evaluate the accuracy of their judgments — that is, if people feel they will be held accountable for their views — then they tend to avoid cognitive pitfalls such as overconfidence and the failure to update beliefs in response to new evidence.

[Researchers] have demonstrated that accountability has this effect because it encourages people to pre-emptively think of ways in which they might be wrong — before others do it for them.

But when people make non-falsifiable predictions, they feel less accountable. After all, if a prediction can never be disproved, then it poses no reputational risk. That lack of accountability, in turn, encourages overconfidence and even more extreme predictions.

And, so the antidote is?

• You can measure anything? Perhaps in theory, not really in practice, but nonetheless the idea sells books and lectures. However, it's the place to start: How would I know I'm DONE in project parlance?
• Don't accept blather as a substitute for critical thinking. Of course, this requires you have a "blather filter" you can engage, and then the personality to challenge the blatherer
• Always ask: can I measure the outcome; recognize success? If not: back to the drawing board for a different formulation.

---

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

The book of Teams for Portfolio and PEO

---

I'm willing to bet that every PEO (program executive officer) in the Pentagon has read General McChrystal's book*, titled "Team of Teams". This book is this year's book on teamwork for the big dogs: PEO's, portfolio managers, and large scale program managers.

Obviously, it's written in a pseudo-military context, covering mostly McChrystal's time in Iraq as the senior special forces commander, but the lessons are easily ported to the civilian domain of large scale projects and business or agency endeavors.

What's in it for program managers and portfolio leaders
The big takeaways are given by the title of the book:

• The payoff and advantages of teams at small scale -- shared commitment, speed, and collaboration to achieve mission and goal -- are obtainable at large scale
• By corollary, reduction-style organization (or "reductionism" in McChrystal's vernacular) -- by which is meant hierarchical work breakdown with parallel breakdown of management tasks -- is too slow and too myopic, and too prone to suboptimizing for tactical advantage
• Networks replace hierarchies; senior management and middle management are all nodes on a common network.
• As in all networks, multi-lateralism replaces stove-piped escalation.
• There is network access to decision-making data
• Complexity is a world onto itself; complexity is a lot more than complicated, because complex systems and situations defy exact forecasting and understanding

For McChrystal, and especially in a context of time-sensitive opportunities, the first point (dare I say 'first bullet'?) is the main point: it's really speed of decision-making and deployment, made possible by breadth of collaboration.

You can't get rid of some stovepipes
One thing he says that struck me is that no matter how extensive a network, at some point it comes up against the boundary of another network or a stovepipe which is not transparent. Then what?

His solution is to send someone into the other camp to be a emissary and collaborator. In the world of States, we call these people ambassadors. The concept is applicable to stovepipes and other management challenges.

ToT is not a new idea, but McChrystal's insights are worthy
In all the project management books I've written over the past 15 years, I've extolled the advantages of teams of teams, though my experiences are small set beside McChrystal's. So, in some ways, I'm a very sympathetic reader of what McC has to say:

• ToT is not efficient and not inherently lean. Teams overlap; teams have redundant staff and materials; a lot of the network communication is not useful to many who hear it. Reduction style management is F.W. Taylor's management science: everything lean to the point of no excess cost anywhere. But Taylor was not a team guy! (Attention: agile planners. Agile is not particularly efficient either)
• Reduction style plans are fragile: subject to breakdown in supply and timetables, and require expensive re-work when things go awry (who's not heard: plans are the first casualty of reality?). But.... such plans can be the best way to do something if only all the risk factors would go away.
• Complexity is non-linear and may be all but unbounded: Nobody has ever calculated how many game of chess there are. "By the third move, the number of possibilities has risen to 121 million. Within 20 moves, it is more than likely you are playing a game that has never been played before"
• Big data won't save us: Ooops! did McC not get the memo? Big D is the answer to everything. Well, except for the complexity thing. Just ask the climate people to predict the weather. But, the antidote, by McC's reckoning, is to time-box or pin things to a horizon.  Just handle the data and complexity " ... over a given time frame."
• "Prediction is not the only way to confront threats; developing resilience, learning how to reconfigure to confront the unknown, is a much more effective way to respond to a complex environment."

---

* Written with Tantum Collins, David Silverman, and Chris Fussell,

---

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

Maturity model

---

Yuk! No one wants to read about a maturity model. Isn't that a tool from 30 years ago?
Nonetheless, over at herdingcats, there is an image of a model that captured my attention for a couple of reasons

• The image itself is an attractive presentation
• The substance is clear enough that most can see some advantage of every step

This model, like models, is a simple and abstracted view of real life so that we focus on the substantive points. That is, no one works in an organization that is exclusively on one level or another. The points being:

• In some things, we're level 1 or 2, making it up as circumstances emerge -- Innovation may occur here.
• In other things, we've advanced to level 4 or 5 because we know exactly how to do it, and we're committed to making it even better --- Productivity (and profitability) may occur here.

And, so having read this far:

• Is there something useful here, or
• What's the utility?
• What's the action item for a project office?

Answer:

• Maturity models are checklists, on the one hand -- stuff we should be doing. Are we doing them?
• Maturity models can serve as strategic objectives (to climb the steps), giving a glimpse of a differentiated future. Do we have a plan to get to one step or another? After all, who wouldn't be striving for the fifth step, always focusing on improvement?

---

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

That "trust" thing... again!

---

Here's a point about trust that recently arose in my agile class.  A student said traditional methods lack trusting relationships, whereas agile teams are more likely to embrace trust.

Maybe/probably so; history would be seem to be on the side of the student

Consider the  theory of "Management Science", as developed in the early industrial age around 1915 by Fredrick Taylor.  Taylor -- and his disciples -- held that all jobs could be described by a "job description" and that any qualified person could be plugged in -- so long as they were not "a square peg for a round hole" Thus: plug and play staffing.

(Aside: I took the name of my company -- Square Peg Consulting -- from the problems I observed trying to be a good "Taylorist" in the Defense and Intelligence domains in the 80's)

And, because these plugs were largely anonymous to management, bureaucracy was invented to contain and direct work, more or less anonymously, via protocols and policies -- No trust required!

Just follow the rules, or perish.

Along comes agile and replaces large scale bureaucracy with trust!  What a concept! Now, admittedly, trust is hard to scale -- requires personal knowledge in the main. So, as scale increases, trust and bureaucracy trade places.

The trend du jour is "flat" organizations and open space. Why? To get back to the virtues of a small scale -- trust and agility -- with a large organization. If everyone has to gather by a common water cooler, by and by people will get to know one another.

Steve Jobs famously put the only rest room at Pixar in the Atrium... everyone had to go there by and by. Agilist Alistair Cochburn calls this communication by "osmosis"... absorption due to being the same place.

---

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

Hub and Spoke

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and as an EE, I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

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

Authority and power

---

Authority and power: often misunderstood; often abused; sometimes used effectively

I suggest the following about authority and power  :

• Managers have authority by virtue of institutional/constitutional position, and power by virtue of their exercise of authority
• Authority is the ability and the institutional right to authorize (to say YES)
• With or without authority, you can always say NO (and gum it up; staffers do this all the time)
• Power comes from the fear/threat/utility of the application of (authorized) resources
• Really effective power comes from the ability to communicate, where communication means to be able to instruct/educate/persuade/motivate.
• However, it's also true that a leader (less so a manager) without authority can still have power -- perhaps very effective power -- by virtue of their communication skill.   

Someone with authority but no real power can say "do this" but it won't get done or it won't stick. Stickiness is the real mark of power... say "do this" and it gets done, and it sticks! (No back channel work arounds, no problems of subordination; it just sticks!)

Of course, authority can segue into authoritarian.
We've posted on that before:

---

Bookmark this on Delicious

Democracy, government, and GitHub

---

Clay Shirky is a frequent speaker on TED. The other day I ran into his recent talk on how democracy, government, and GitHub are related. That's not self-evident to be so I looked in.

GitHub, for the unaware, is an open source source-control system (aka configuration management, or source repository) from the genius' at LINUX. The big claim to fame with GitHub is that is completely distributed, no central control, but has a shared protocol for managing updates and relations about and between objects.

Shirky comes into when he discovers that even government agencies are using it to manage the relationships, something like mind maps, among constituents, regulations, statutes, and documents.

Very interesting idea when you think about it. And lots of project management applications at the PMO level, as well as at the cost account or work package or iteration level.

Here below is the TED presentation, but equally interesting is this explanation of how GitHub works using a project document as the object:

---

Bookmark this on Delicious

Modular contracting

---

From the White House in Washington we get this news:

There is to be "Greater Accountability and Faster Delivery Through Modular Contracting"

And good news that is, indeed. In a document helpfully titled: "Contracting Guidance to Support Modular Development" we learn that it is US policy to encourage:

agencies to shift away from the bloated, multi-year projects so common in the past to a more nimble approach. The guidance provides our IT, acquisition, finance, and program officials practices for how they can, working together as part of an integrated program management team, break investments into more manageable chunks; eliminate the costly lag between when the government defines its requirements and delivers solutions; and begin delivering workable solutions shortly after contract award. By requiring frequent deliverables, agencies will also be better able to hold contractors accountable for keeping projects on track and delivering solutions that truly meet agency needs. And by breaking investments into smaller chunks, agencies may be able to drive more competition – including small businesses that might not have been equipped to compete for the massive, multi-year projects of the past. And more competition means a better value for the American people

Agile government projects, anyone? :)

---

Bookmark this on Delicious

That agile governance thing

---

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don't let yourself be lulled into inaction.

Bill Gates

I wonder if Bill's quote is on Ballmer's wall somewhere next to MS's strategic plan for mobile computing?

You have to wonder if their governance, given their size, is open enough to innovation? Surely, all the look-ahead trend setters are not exclusively in Silicon Valley.

Maybe they need to be more agile?

Governance and agile methods may seem like an oxymoron—but not so. A means to govern is essential for orderly project functioning. Without governance, the advantages of adaptive and evolutionary methods could be overwhelmed by functions bolted together haphazardly and rendered operationally ineffective, expensive to maintain, and not beneficialdisadvantageous to customers and stakeholders

Governance 'should's'
•A governance program should be purposeful about maximizing the business potential of a project.

•Governance should be dedicated toward minimizing the risks to business performance.

•A governance program should enable and promote innovative and imaginative solutions, and

•Governance should deter behavior that strays too far from norms.

In short, a governance program exists for five reasons that are in effect the governance mission statement:

Governance Mission

1. To oversee and approve investment on behalf of business beneficiaries;

2. To codify decision-making rights to enable make it possible for teams to have autonomy and freedom of maneuver;

3. To enable and promote innovation, evolution, and technical excellence within the framework of architecture and operating norms;

4. To be the ultimate arbiter of risks that affect business performance and accountability; and

5. To provide accountability for compliance to mandatory standards.

Governance is built on quality principles. Four principles guide an effective governance implementation:

Governance Principles

1. Proportionality: Governance should be applied proportionately to the amount at stake.

2. Clarity: Governance should provide clarity for mission and purpose, scope boundaries, decision-making authority, and decision rights.

3. Subsidiarity: Governance should respect the principle of subsidiary function: governance should not intrude into the management of functions that are best left to functional and project managers.

4. Lean: Governance must be lean, timely, and responsive, respecting agile principles to provide enough, but ‘just enough’, oversight and control to accomplish the governance mission.








A project management tip: Decision policy for the project manager

• The simplest policy for decision making is... always make a best-value decision based on the collective value of the risk-weighted factors

• When deciding among alternatives, pick the alternative that informs the business most favorably, even if there is suboptimum result for the project

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

Government technology opportunity

TechAmerica has issued a very readable report entitled Government Technology Opportunity in the 21st Century. There are four top level recommendations:

1. Develop a Professional Program Management Capability (you might ask: isn't this a long time coming? Hasn't the US federal government been in this business since WW II?)
2. Promote Agile/Incremental Development (Now of course this is a genuine newbie)
3. Strengthen Risk Management (again, a bit late, but welcome anyway)
4. Enhance Internal and External Engagement (needed for agile, but needed in any event)

On the first point, this telling quote from someone who contributed to the report:

“Strong program managers have overcome poor requirements, aggressive milestones, limited resources and constrained processes to deliver mission capability, while processes have not been able to compensate for a poor program manager even with clear requirements and sufficient resources.”

On the second point, we are told this:

The benefits of agile/incremental development can be seen in the results of a survey of commercial IT developers published in the June 2008 issue of Dr. Dobb’s Journal and cited by Scott Ambler, Chief Methodologist for Agile and Lean at IBM, in discussing the effectiveness of the methodology.

Survey respondents compared agile to other methodologies and rated it as follows:

 Productivity—82% rated it somewhat or much higher
 Business Stakeholder Satisfaction—78% somewhat or much higher
 Quality—77% somewhat or much higher
 System Development Cost—72% somewhat or much lower

To implement agile, the report goes on to cite a few regulatory and cultural hurdles to overcome. Glen Alleman puts it this way:

... self directed teams sitting in the same room with their customer, letting the requirements emerge as the money is being spent, probably isn't going to pass the smell test of Congressional oversight of spending the public's money

Nevertheless, if the recommendations in this report are acted upon, the federal IT business will be the better for it.

Bookmark this on Delicious

NICE Cyber

The National Initiative for Cyber Education (NICE) is hard at work.  From their website, we learn that: "Today, there is little consistency in how cybersecurity work is defined and described throughout the nation. The lack of a common language to discuss and understand the work requirements of cybersecurity professionals hinders our nation's ability to:
-Baseline capabilities,
-Identify skill gaps,
-Develop cybersecurity talent in the workforce, and
-Prepare the pipeline of future talent."

Thus, a workforce framework has been developed by NICE, a unit of the National Institute of Standards and Technology (NIST).

The seven NICE categories are:

1. Securely provision - conceptualizing, designing and building secure IT systems;

• Information assurance compliance
• Software engineering
• Enterprise architecture
• Technology Demonstration
• Systems requirements planning
• Test and evaluation
• Systems development.

2. Operate and maintain - the support, administration and maintenance necessary to ensure effective and efficient IT system performance and security;

• Data administration
• Information system security management
• Knowledge management
• Customer service and technical support
• Network services
• System administration
• Systems security analysis.

3. Protect and defend - the identification, analysis, and mitigation of threats to IT systems and networks;

• Computer network defense
• Incident response
• Computer network defense infrastructure support
• Security program management
• Vulnerability assessment and management.

4. Investigate - investigation of cyber events or crimes, which occur within IT systems or networks, as well as the processing and use of digital evidence;

• Investigation
• Digital forensics.

5. Operate and collect - the highly specialized collection of cybersecurity information that may be used to develop intelligence;

• Collection operations
• Cyber operations planning
• Cyber operations.

6. Analyze - review and evaluation of incoming cybersecurity information to determine its usefulness for intelligence;

• Cyber threat analysis
• Exploitation analysis
• All source intelligence
• Targets.

7. Support - specialty areas that provide critical support so that others may effectively conduct their cybersecurity work;

• Legal advice and advocacy
• Strategic planning and policy development
• Education and training.

 

Bookmark this on Delicious

Governance or error?

Take a look at this:

Is this pilot error or a violation of governance? I'm not the first to ask the question. Our friends at Dark Matter first raised the point.

Could be either, or neither: it could be mechanical.

How to know? And, does it matter the motivation?

Well, actually yes. Governance is in the wind these days, what with agile and all. On the one hand: all hail initiative and daring! On the other hand: who's got the big picture in mind?

Certainly the 'captain in command' is the ultimate team leader. No central authority can intervene, short of shooting him down (I assume a lady is not in command, but she could be, of course).

And, I'll bet he's not reading the flight manual either! Improvisation is the paradigm.

Trust is what it is about at this point. All concerned, especially the two ground observers, are bound to trust the judgment and skill of the captain.

But motivation is still on the table.  The motivation for more agility in governance is to lean out the overhead and concentrate all energy on throughput, that is: governance that actually promotes deliverable output that leads to mission outcomes.  Insofar as our daring captain is motivated for the right reasons, I say: yea verily! 

 Bookmark this on Delicious  

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

The achievement test

There's a lot of angst in the PM community about project management and management governance as being 'large' vis a vis  'small', or perhaps better said as: project management as plan-centric  vis a vis  'agile'. Even hierarchical vs relational enters the conversation.

And rightly so.  Means matter. 

One reason they matter is that most of us are not artifacts of 'Taylorism', the business theory of  "people as interchangeable parts" insertable into an [almost mindless] process.  But for most, the governance culture of the project intersects with our personal and political ideas of governance.  That intersection may be harmonious, but sometimes it's not.  Where not: move on; otherwise: let's get to work.

I've quoted Alistair Cockburn before, but it's worth remembering:

Almost any methodology can be made to work on some project

Any methodology can fail on some project

To repeat: means matter. 

But of course, the 'ends' matter most. That's where 'achievement' comes into play.

Achievement should take up more of our energy--more, but not all, to be sure--than that which we put into debates over governance and methodology.

A similar theme was struck in an article I read this past month, from which I borrowed the title for this post.  The idea there, and the idea here, is that what matters most is throughput: results--enabled by an effective governance scheme--that are consequential for the people and enterprises affected.

An achievement test for projects is not high science; here are the five big points:

• The project produces the objects of greatest value, most importance, and most urgency as judged by the stakeholders
• The project beneficiaries are better off for having the benefit of the project outputs.
• The project team earns their just rewards for a job done well according to the performance measurement baseline [PMB]
• Project outputs beget business outcomes that  increase the value of the enterprise, and
• The sponsor-investors who underwrite the project receive a reasonable value as a return on their investment

.

 Bookmark this on Delicious    

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

Business Rules Manifesto

The folks at businessrulesgroup.org have written a manifesto, entitled, conveniently enough, the "Business Rules Manifesto"

Who knew!?

Seems like everyone has a manifesto these days.

In any event, it makes interesting reading. There are ten 'articles' that more or less lay out the 'rules about "rules"'. Perhaps the articles should be called meta-rules.

Article 2 and 3 are my favorite:

Article 2. Separate From Processes, Not Contained In Them
2.1.
Rules are explicit constraints on behavior and/or provide support to behavior.
2.2.
Rules are not process and not procedure. They should not be contained in either of these.
2.3.
Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1.
Rules build on facts, and facts build on concepts as expressed by terms.
3.2.
Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
3.3.
Rules must be explicit. No rule is ever assumed about any concept or fact.
3.4.
Rules are basic to what the business knows about itself -- that is, to basic business knowledge.
3.5.
Rules need to be nurtured, protected, and managed.

So let me put this in my words.

Business rules are actionable specifications of behavior that explicitly implement a policy.  The policy could address legality, ethics, responsibility, authority, or custom.

The specification has three [at least] arguments: ~condition, activity or behavior, constraint or boundary~.  Of course, there could be others: ~'date applicable', 'applies to', 'exceptions', 'inclusions', 'extensions', 'authorized by', 'appeal to'~ are examples. Constraints or boundaries are enforceable, either by system functionality or administrative procedures.  Behavior can be animate or inanimate on the part of 'actors'.

Sometimes, the arguments are arranged in an 'if-then-else' logic:

IF ~condition~, 

THEN ~activity or behavior~~boundary, constraint~, 

ELSE ~activity or behavior~~boundary, constraint~.

Too much structure?

How about this example: "No receipts are required for business expense items < $25"

Now, I use the term business to explain all this, and it probably connotes a front office or back office organization, but in fact, 'business' is the enterprise, and enterprise could include everything from a commerce activity to a weapons platform in a military context.

In this regard, project managers should engage business analysis to construct business rules as a part of any requirements definition and specification process.

 Bookmark this on Delicious  

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

Systems Assurance Guidebook

The National Defense Industrial Association, NDIA, in 2008 published a systems assurance [SA] guidebook entitled "Engineering for Systems Assurance".

From the executive summary, the threat:
"For decades, industry and defense organizations have tried to build affordable, secure, and trustworthy systems.  Despite significant strides towards this goal, there is ample evidence that adversaries retain their ability to compromise systems"

And this definition of SA:
"System Assurance is the justified confidence that the system functions as intended , and is free of exploitable vulnerabilities...."

In an article in this month's Crosstalk, the journal of defense software engineering, there is a discussion of how SA fits into the DoD's program acquisition framework, the general lifecycle of large scale programs [projects] in the DoD.

The whole concept is built around an idea called an "assurance case".  In the case, the program manager and system engineer assert, with proof, that the functions are indeed free of exploitable vulnerabilities.

Frankly, its good to know that someone is on the case!  What with China, Google, and a host of others including the social networks, SA is more important than ever before.  The guidebook is worth a read.

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

The Subsidiarity Principle

What does the Catholic church have to do with project management? Well, do you remember the encyclical “Rerum Novarum” of 1891 by Pope Leo XIII? If not, then to make a quick point, among other things, it postulated the concept of subsidiary function, also called subsidiarity, to differentiate responsibilities between the Vatican and other units of the church. However, the idea has spread far and wide and is embraced in modern business thinking and progressive project management--like agile methods.

In a word, what it means is push things down: more importantly, don't interfere with subordinates. Have faith they know what they are doing, and more likely they will do the right thing.

There are rights and responsibilities that come with this principle. The central authority has a right to expect responsible behavior of its subordinate, but retains thea right to verify performance— – to trust, but with verification— – and intervene to impose corrective action.

The subordinate unit has a right to expect a degree of autonomy, with reasonable inspection and verification, so long as the subordinate acts responsibly. The subordinate has a responsibility to act in its own interests and in the interests of the central authority, taking care to not over- optimize at a low level.

When the principle of subsidiary function principle is extended to project planning, the first planning criteria is that plans should not be unnecessarily obtrusive; in particular, an agile plan should not direct, prescribe, or otherwise limit maneuverability and activity beyond the establishment of acceptable norms and conventions.

In other words, planning is to be done by the most competent and responsible decentralized project unit that is competent and responsible.

For progressives, it's not hard to buy into subsidiarity!

Are you on LinkedIn?

Share this article with your network by clicking on the link.