Value flow

---

About value (*)

In many posts in this blog, I have established these propositions:

• That there is a distinction between project value and business value, and 
• That the interests of the customer/user, sponsor/stakeholder, and project manager are to be balanced among these parties, even as they all compete for attention as value is developed. 
  

We recognize that:

• Each has their own needs and wants, 
• Each has their own sense of urgency and importance, and 
• Each has an idea of the investment they want to make and the risk they are willing to accept.

Value planning challenge

The planning challenge for project sponsors is to fashion a practical and rewarding opportunity from the myriad of permutations and combinations of needs and wants, colored by urgency and importance, affordability, and risk. 

 

To make the best of opportunities requires goal setting and strategic development in the context of mission and vision. 

• Mission provides the compelling call for action. 
• Vision provides the epic narrative and points the way ahead. 
• Goals set the stage; goals motivate business strategy and, in turn, motivate project strategy

OE and project objectives:
Business goals, extended through business strategy, drive project objectives. But of course business strategy also drives operational effectiveness (OE) ....

OE being the quality of the operations and operating programs that amounts to doing things better with predictable repetition (see: Michael Porter for more ideas like these). But even predictable repetition, if done better over time, like projects, add value to the business.  

OE and projects, working together, are two instruments of strategy. They are interdependent. The outcomes of projects may well affect operations—add, change, or delete them—thereby closing the loop on goals and strategy, as captured on the business scorecard 

Strategic Plan

Here, at the bottom of this post, is the bottom line:

Strategy is a plan that integrates continuous improvement of operational effectiveness with a vision and narrative for differentiated innovation attained with projects

 

-----------------------

(*) Some of the material in this post come from Chapter 2 of my book, cover illustration below, "Managing Project Value"

---

Buy them at any online book retailer!

Running a business

---

On the one hand:
Follow the science; follow the engineering; follow the facts; adhere to policy and precedent

On the other hand:

Listen to the customer; stay ahead of the competition; keep an eye on shareholder value; don't be late!

As one prominent CEO opined, business decision-making is all about a talent for making trade-offs. In effect, "situational decision-making" somewhat akin to "situational leadership". Different and multiple styles to be fitted to the situation:

• Nothing is so simple as "follow the facts" and adhere to precedent. 
• Nothing is so "lacking sense" as just "listen to the customer"

Here's another idea: seek stability and predictability. The fact is that without either, your only recourse is to apply a heavy discount to future value. 

Not so fast! 

Maybe your business model thrives on instability, in effect working off the 'rate of change' rather than the steady-state. 

Many 'transactionalists' work this way, making large bets on even small changes (very large times a very small number may still be a quite large number, aka: the "one-percent doctrine").

But if you are the business leader that heads toward the unpredictable, then you should be thinking of how to make your business "anti-fragile", to wit: to be able to absorb great shock without collapse.

• By having interior firewalls to stop risks from propagating
  
• By having redundancy to fill in for failed capability and capacity
  
• By having reserves to cover losses
  
• By not being totally "just in time" because there may not be time
  

No matter the model for decision-making, an internalized methodology that you can apply with confidence is your best tool, to be practiced and made like "muscle memory"

 

---

Buy them at any online book retailer!

Counter-party risk

---

Define counter-party: 

In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.

 

In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 

 

Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.

 

About counter-party risk

So, you are about to enter into a transaction with another party. What might be the risks?

• Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
• Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  
• Willingness to perform their side of the transaction when the whole deal comes under stress may require backup

What is your strategy; what are your tactics?

• Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
• Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  

---

Buy them at any online book retailer!

Mapping project value-add

---

To get things in the right sequence, let's define "value-add" before talking about mapping value-add

Simply put, insofar as one-time projects are concerned (setting aside repetitive services, etc):

Value-add is anything you can make out of stuff -- to include intangible stuff -- that is ultimately delivered to the customer, or makes the deliverable a good thing in the customer's eyes.

And so, the mission for the PMO becomes: build and deliver value to the customer. Such implies a process to acquire "stuff". Then to mix, modify, and assemble; test, package, and deliver.

Fair enough
And so, how to lay out this process?
Enter: Value stream mapping

Value stream mapping
Value stream mapping may look like a new label on old wine. But even if that is so, the wine ages well. In the old days, we simply called it process mapping.

• Activities are usually arranged in finish-to-start precedence; 
• Feedback loops are established to promote stability; 
• Points of control, and control limits are established; and
• Value is accumulated, step by step.

Some would call this an earned-value view of value mapping. Fine with me.

Getting lean
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 workflow steps, and other governance and ancillary activities, like a trouble report or a status report, are evaluated for value-add. Presumably, such an evaluation leans out the unnecessary detail and complexity of too many rules.

A lot of governance would not fit the value-add definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without some non-value overhead that goes along with everything.

The map
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

---

Buy them at any online book retailer!

Evaluating prospects -- alternatives

---

Daniel Kahneman and Amos Tversky may be a project manager's best friends when it comes to understanding decision making under conditions of risk. 

Of course, they've written a lot good stuff over the years.....my favorite is "Judgement under uncertainty: Heuristics and biases".

The original prospect thinking
Tversky and Kahneman are the original thinkers behind prospect theory..  Their 1979 paper in Econometrica is perhaps the best original document, and it's entitled: "Prospect Theory: An analysis of decision under risk".  It's worth a read [about 28 pages] to see how it fits project management

What's a prospect?

 A prospect is an opportunity or possibility with both an upside advantage and a downside risk. Said another way: by opting fo a prospect, you might gain something you don't have or lose something that you do have, that something usually measured in monetary terms.

Prospect theory addresses decision making when there is a choice between multiple prospects, and you have to choose one.

And, a prospect choice can be between something deterministic or certain and something probabilistic or uncertain.

What's the Theory? The big idea
So, here's the big idea: The theory predicts that for certain common conditions or combinations of choice, there will be violations of rational decision rules. 

Rational decision rules are those that say "decide according to the most advantgeous expected value [or the expected utility value]".  In other words, decide in favor of the maximum advantage [usually money] that is statistically predicted.

Ah yes! Statistics .... lies, damn lies, and statistics!
Shocking news -- sometimes, we ignore the statistics. Ergo: violations of rational decision rules.

Evaluating alternatives and prospects: Violations of decision rules driven by bias:
Prospect theory postulates that violations of decision rules are driven by several biases which we all have, to some degree or another:

• Fear matters: Decision makers fear a loss of their current position [if it is not a loss] more than they are willing to risk on an uncertain opportunity.  Decision makers fear a sure loss more than a opportunity to recover [if it can avoid a sure loss] 
• % matters: Decision makers assign more value to the "relative change in position" rather than the "end state of their position"
• Starting point matters: The so-called "reference point" from which gain or loss is measured is all-important. (A small gain matters more to those that have nothing, than the same amount matters to those that have a lot) The reference point can either be the actual present situation, or the situation to which the decision maker aspires. Depending on the reference point, the entire decision might be made differently.
• Gain can be a loss: Even if a relative loss is an absolute gain (to wit: I didn't get as much as I expected), the lesser outcome affects decision making as though it is a loss
• Small probabilities are ignored: if the probabilities of a gain or a loss are very, very small, they are often ignored in the choice.  The choice is made on the opportunity value rather than the expected value.
• Certainty trumps opportunity: a bird in hand ... in  a choice between a certain payoff and a probabilistic payoff, even if statistically more generous, the bias is for the certain payoff.
• Sequence matters: the near-term counts for more. Depending upon the order or sequence of a string of choices, even if the statistical outcome is invariant to the sequence, the decision may be made differently.

---

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

Fred P. Brooks on Estimates

---

Dr. Fred Brooks, Jr.'s "The Mythical Man-month" is still required reading, even if written decades ago.

And, as these things go, it has a lot of humor, but also a lot of wit. There are dozens of quotes from this book floating about, but here's one worth writing down:

"It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers"

Of course, some would say, in response: Then, make no estimates at all!

Yuk! No estimates is actually worse because that means that there's been no thought put into outcomes, value, and worthiness. No one can run a business very successfully for very long if that's the mindset.

---

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

Most projects run on "little data"

---

"Big Data" is the meme du jour, but most projects run on "little data", the sort of data that fits into the constraints of spreadsheets like Excel. It's everyday stuff that drives estimates, scorecards, dashboards, task assignments, and all manner of project analytics.

So, assuming you using Excel as a spreadsheet for doing actual calculations and data entry, and not a row-column table version of Word, you will find that you to do some analytics and data analysis from time to time.

Pivot tables are one spreadsheet data tool, but that's not the discussion today. Today, it's filters, which is the Excel name for the process and tool, but which the database people -- familiar with SQL for row by column -- would call a query.

And so, how to do a filter in Excel, something practical for the project manager? There are youtube's galore on the subject, but here's a neat, step by step, illustrated process that goes from the simple to the advanced.

Just what the PMO need to get into the data business

Some other rules
Beyond what you will read in the linked article, there are a few data rules that will make life simpler

• Every column should have a header or title that is unique, even if just column1, column2, etc
• Only one data value in a cell. Thus, first and last names should be in separate columns; so also city and state. But maybe also captain and ship's names. This is called "normalizing" the data
• Keep the static data in separate row/column areas from the data that changes. So, if a ship sails to San Francisco on a certain date, the ship's description goes in one area; the city description in another; but the city/date/ship is dynamic and belongs in a third area.
• Don't put 'word processing' paragraphs or labels in the middle of the data. In other words, maintain the integrity of row by column
• It's good to have at least one column that is guaranteed to be uniquely valued in each cell, like a row ID
• If you can avoid using "spaces" in the data, that's good. It makes the query more sure. So, "column1" instead of "column 1"

 

---

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

Agile starts here

---

Even though the business case tells me what product I'm building, detailed outcomes of software projects, viewed from afar are not very predictable. But... up close, they are. 

From this we get the fundamental architecture of agile projects to wit:

Agile projects are strategically stationary but tactically emergent

And, 'stationary' means... ? Stationary means that no matter when or where you view the project, it's strategic intent and outcome are invariant --- the same, unchanging.

And, 'emergent' means... ? Emergent means that detailed requirements may be created, deleted, updated, or deferred as circumstances reveal themselves and the project moves along.

How do we move from stationary in the far view to stationary in the near (up close) view?

• First, write a business case. And, from that a project charter. Those two dots should connect. These get you strategic intent and far view stability. These need not be heavy documents; often, a single page will drive a lot of project.
• Second, adopt the idea that for each segment of work put in process (WIP) on a Kanban board or a sprint or iteration, the backlog for that unit of work is fixed and frozen. This gives up close stability. And, tactical estimates can be done on such a fixed scope of work. 

What about that bug-a-boo of estimate or no-estimate? This really shouldn't be a question, but it always is:

• The sponsor is going to come with a top-down budget and schedule. In a real business, there are budgets, period.
• The project must respond to the business case. The response is usually made in the project charter.
• The project charter has two constituents: 1. The project's counter proposal to the top-down budget, and 2. the estimate of risk to close the gap between the business budget and project's counter-proposal.

The accountants among us may recognize the similarity to a triple entry balance sheet:

• Business value and budget on the one hand
• Project risk (liability) and capabilities on the other hand

In point of fact, for many years, I've been calling this balancing act a project balance sheet. The business gets one side; the project gets the other side (and, of course, the project gets the side with the risk... you wouldn't imagine it would be any other way!)

---

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

To borrow a phrase: Semper Fi, but in Agile land

---

"Semper Fi": the Marines' short hand for their motto: Always faithful

To take nothing away from the Marines, in Agile land, this means....

Fidelity, faithfulness, and commitment, but to what?:

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

Are these in tension? If yes, 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."

---

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 best of the bad ...

---

You can read zillions of books, papers, and posts about the business case in project. In fact, there are four books illustrated below that have a chapter on the business case.

But, you won't find much on projects that don't have a viable economic business case, except for the universal advice: don't do the project!

Not so fast! That advice is economically sound but may not be operationally viable. Really, what do you do when there's no project outcome that's NPV positive, but you have to do something to improve or salvage operations (process, service, or product)?

"Do No Harm" becomes "Do the Least Harm". To wit, take the best of the bad as a reference case (or baseline), and then compare the other alternatives. You might wind up with a "Best (of the bad) Value" decision, to wit:

"Best (of the bad) Value" optimizes the solution operationally at the least worst cost"

So, if doing nothing is not an option, or, more dramatically, failure is not an option, then go get as much funding as you can to deliver the best value you can. That'll be the best (of the bad) value for the funding.

---

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

Agile cost of value

---

Everywhere I go I make it clear that agile in the enterprise begins with a business case. I make this point in my books* and blog postings over and over. The logic of this is obvious on its face: if you are going to spend other people's money (OPM) they'll hold you accountable. Accountable for what? That's what the business case is for... to answer that question. And, if your processes require a project charter, you can morph the business case in the charter.

But agile goes a step further: agile asks that the customer/user/product manager be embedded in the project and empowered to interpret the requirements in the backlog: sequence them, give them priorities, and recommend new ones, ones to change, and ones to delete.

So, given that empowerment, what then is the utility of the business case. What happens to accountability?

Actually, and in the spirit of keeping it simple, yet effective:

If the customer/user/product manager recommends changes in requirements, not anticipated in the business case, and these changes are material to the business proposition (cost of value), Agile provides two methodology opportunities:

• The retrospective evaluation leading to the next formulation of the next iteration's backlog, and
• The release planning session (or process), leading to production releases to the business.

Beyond these methodology opportunities, each business may have processes to handle business case changes that would overlay the project methodologies.

In each opportunity, the witting and accountable product manager goes back to the business case to evaluate impact to the cost of value, very likely consulting with affected stakeholders. It could be messy of course, and it could delay things, but following the agile principle of provoking change early on, it's really in the job jar of the agile product manager to be pro-active about attending to the business case.

---

* Maximizing Project Value, Chapter 3, discusses the agile business case
Project Management the Agile Way, Chapter 2, also describes how to build an agile business case

---

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

Business case -- the case for communication

---

I picked this up from an email blast from Mike Clayton entitled  "It isn't all logic". He's writing about business communications in general, and that's fine, but as PM's the business case is often the first business document we address.

So, think of brother Mike's comments in the context of the business case you're about to write.

Mike says:

We might think we use data and reason to make our decisions at work, but on most occasions, we'd be fooling ourselves. Never under-estimate the impact of the intangible, the informal, and the downright irrational.

Who are you? 
Before we consciously process an argument, we unconsciously assess the person who is making it. So always ensure you make some reference to your credentials early on: why should I trust what you are advocating? The elements to consider include: your experience, expertise and knowledge; you background, honesty and integrity; and understanding f the issues and how they affect me.

 What do I care? 
 Psychologists are divided. Some say we make our decisions based almost entirely on emotional factors. Others say we make our decisions based entirely on emotional factors, and use the logic of an argument to justify our decision to ourselves. Either way, you have to show me why it matters and appeal to my sense of justice, fairness, compassion, outrage, fear or some other emotion.

 What's in it for me? 
 When you get around to the facts, this will be the question I most want answered. So you need to look at your proposal from my point of view and give me the answer to 'why?' Put this in early - almost as soon as you have laid out your credentials. You are not writing a novel, so I'll want you to get to the point quickly; not keep me in suspense.

 Keep it simple
 Fewer reasons are better than more reasons. Lots of reasons are worst of all. The more reasons you give, the more I suspect you lack confidence because each is weak. Pick your best and give me one, two, or three reasons; no more.

Keep your language simple too
No one buys from someone they don't understand (except some rich people when they buy technology). All of the costs.  Three benefits or fewer, but but give me all of the costs, risks and down-sides of your proposal. If not, I will have a reason to blame you later, if the decision I made to agree with you turns out to be wrong.

 Anticipate my objections
 Take all of the wind from my sails by listing any concern a decision maker might have and addressing them all, on-by-one.

 Make it compelling The average business case is dull to the limit of endurance. You are not writing a novel, but you do want o be read. Use a straightforward structure that flows logically from one section to the next, answering questions in a sensible sequence with well-chosen evidence and examples.

Craft your language with care and keep it short and sweet.

---

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

Telling a story with data

---

Jim Stikeleather, writing on the HBR Blog Network, has five useful and usable ideas about applying data to weave a narrative and tell a story.

This comes up all the time in project management, starting with the business case, but going all the way through to test scenarios for user validation.

His points are good ones because, frankly, they're actionable by project managers, not just blah, blah:

Find the compelling narrative.  You are competing for the viewer’s time and attention, so make sure the narrative has a hook, momentum, or a captivating purpose. ... encourage examining relationships among and facilitate interacting with the data – think gameification.

Think about your audience.  The visualization needs to be framed around the level of information the audience already has, correct and incorrect:

• Novice: first exposure to the subject
• Generalist: aware of the topic
• Managerial: in-depth, actionable understanding of intricacies and interrelationships with access to detail
• Expert: more exploration and discovery and less storytelling with great detail
• Executive: only has time to glean the significance and conclusions

Be objective and offer balance.  Even if it is arguing to influence, it should be based upon what the data says–not what you want it to say. Viewers and decision makers will eventually sniff out inconsistencies which in turn will cause the designer to lose trust and credibility, no matter how good the story.

 

Don’t Censor. Don’t be selective about the data you include or exclude, unless you’re confident you’re giving your audience the best representation of what the data “says”.

 

Finally, Edit, Edit, Edit. Also, take care to really try to explain the data, not just decorate it.

---

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

Tell me what you know

---

I don't think this is new insight, but I'll repeat it here for the record. In his recent book "Takedown" about his years in executive leadership of U.S. intelligence analysis, Philip Mudd* writes about Colin Powell's* approach -- in three steps -- to being an 'analysis consumer', something every project manager is almost every day:

1. Tell me what you know
2. Tell me what you don't know
3. Tell me what you think

If every risk management experience followed the Powell protocol, we'd all be the better for it. (Left unsaid: the Rumsfield version of the Powell protocol about the 'unknown unknowns' and the Ignorance Management Framework!)

Mudd goes on to give his insights re analysis, certainly something every Business Analyst or project office analyst should heed:

1. Maintain objective separation between those who analyze (analyst) and those who use analysis product for decision-making (analysis consumer)
2. Be abundantly clear in the analysis product vis a vis the Powell protocol (as above)
3. Always understand that an intention is not always supported by a capability, and that possession of a capability is not sufficient to impute intention.

Now, a close look at Mudd's third point is really instructive if you are bidding competitively for project work:

• Among capabilities of your competition, what are the competition's intentions (beyond trying to win, of course)?
• Among the intentions of your prospective customer, what are the customer's capabilities to effectively use/employ/absorb your deliverables?

 

Not without coincidence, this leads directly to Chapter 12 of my most recent book "Maximizing Project Value" (see links below) re 'game theory': the systematic means to assess the intersection of intention and capability.

---

*Philip Mudd: Former counter-terrorism executive at CIA and FBI
Collin Powell: Former U.S. Secretary of State, and Chairman, Joint Chiefs of Staff

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Decision models for business rules

---

If you're a business analyst or requirements analyst then a good deal of your time is devoted to business rules and the way those rules are represented in requirements, use cases, and user stories.

Modernanalyst.com has recently posted a couple of essays on decision models and the way that the underlying  individual decision tables are integrated into a more macro view of the decision model.

Part I is entitled Why Decision Tables are not enough: From Decision Tables to Decision Models and Part II is a follow-on: More on Decision Tables and The Decision Model in Practice

The authors posit that decision tables should be treated like any other relational table in a relational paradigm, thus requiring adherence to certain rules for building information by rows and columns. For instance, decision tables should follow the normal rules of normalization, which in a few words, removes redundancy and generally provides for the maxim about data: "enter once, use many"

From the first essay that presents a six step process for building decision tables we learn that we can expect:
...  a deliverable that is more valuable than its pieces. The resulting model is:

• Comprised of the most atomic pieces of business logic (no Ors, no ELSEs, no OTHERWISE, one conclusion fact type)
• Based on disciplined fact types
  
• Normalized to minimize redundancies
  
• Predictable in structure and
  
• Aligned with business performance and directions.
  

From the second essay we learn that the benefits of decision tables are explained this way:

• A decision table is an intuitive visual representation. This circumvents the need for other less friendly representations – such as formal language, strict grammar rules or fill-in-the-blank sentence templates.
  
• Both business people and technical professionals understand a decision tableif it is devoid of technical artifacts.
  
• Some forms of incompleteness, inconsistency, and redundancy become visible ina decision table.
  
• Certain technologies lend themselves to easy automation of decision tables. In fact, most Business Rule Engines (or Business Rule Management Systems, BRMS) accept decision tables as a format for creating and making some changes. That’s because automation ofdecision tables into such engines is fairly straight-forward.

These essays have a good exposition of the author's ideas, but there is a supporting 20 page "primer" (in pdf format) about decision models that is worth a read. You can find it -- after free registration -- at this location.

---

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

Four rules for business success

I've recently learned that Sam Palmisano, the retiring--and successful--C chief of IBM, has four rules for business success

1. “Why would someone spend their money with you — so what is unique about you?”
2. “Why would somebody work for you?”
3. “Why would society allow you to operate in their defined geography — their country?”
4. “And why would somebody invest their money with you?”

That's swell for IBM, but his successor--a lady C Chief in waiting--has been named, so most of those reading this blog are unlikely to lead IBM for at least the next 10 years. Thus, I move to the project management domain.

Caution: changing domains is often problematic. Some things just don't port from one to another. But try this for fit:

Why spend money with you is the grist of project PROPOSAL THEMES. If you ever written a proposal for competitive work, the first question to be asked is "what's the win theme?" The win theme, like its counter part, the project theme, is for the seller the way to win business; and is for the buyer the reason to buy from the seller. It's a bilateral theme to be viewed from both parties.


Why would somebody work for you is at the heart of TEAM RECRUITING. In the agile space, teams are recruited, not assigned. But if you've not got the elevator speech on why work for our team, you may have the right to recruit, but what if nobody wants to work with you? SOL!

Why would society allow you to operate is an obvious THREAT for the risk register. If you can't handle the politics, your project may be DOA and over before it begins!

And why would somebody invest their money with you is a question is all about BUDGET SCARCITY. Stakeholders have choices. It's a rare company that has more to invest than there are quality projects to fund. So, we're right back to competition, only this time we're competing for resources. Can you speak to NPV, IRR, and EVA? If you can't handle this alphabet challenge, you may find your project high and dry waiting for another opportunity.

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

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.

Messy information systems

Do you buy this idea?

... science-based, method-driven approaches can be misleading. Contrary to their promise, they are deceivingly abstract and removed from practice. Everyone can experience this when he or she moves from the models to the implementation phase. The words of caution and pleas for ‘change management’ interventions that usually accompany the sophisticated methods and polished models keep reminding us of such an implementation gap. However, they offer no valid clue on how to overcome it…

Does this mean you have to see it to believe it, or does it just validate the ideas of progressive elaboration (defined in the PMBOK as continuous improvement and refinement) or emergence (unpredicted--though perhaps predictable--interactions of system elements that become known)--or neither?

No matter how you go on this, you might like the book review of "The Labyrinths of Information: Challenging the Wisdom of Systems" by Claudio Ciborra as reviewed by EightToLate

Bookmark this on Delicious

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