Make it a process (with AI)

---

This we all know: One core idea in project management is that projects are an integrated collection of processes: 

• Usually organized by "knowledge areas" wherein specific methodologies are practiced, but 
• Sometimes by objective or task (like, for instance, developing a use case or requirements set, a task with an objective that is applicable to many knowledge areas)

But then there's always the one-off, the exceptionally unique, the specially-talented-person job jar which gets the job done, but is also hard to replicate, to scale, to predict outcomes and quality.

Make it a process (*)

So, perhaps the thing is to make the one-off a defined process that can be inventoried for the next need.. 

Easier said than done?

Yes, but now comes AI agents, assistants, and avatars that can do the unique, and do it with mind numbing regularity and predictability, perhaps as good as your best project person.

Define an agent Interface

Obviously, the way things stand today, you'll need some training data, and a one-off may not have that requisite depth or breadth. Nonetheless, an agent-function, plus whatever data you have, can be enveloped by a boundary for which entry or stimulation is by an interface between you and the agent. 

Agent tasks

What would your AI process agent do?

Begin with "workflow management".  The existing workflow tools will all get an AI upgrade. They will manage the points of entry, points of inspection, partial product inventory, and most importantly they will manage process constraints. 

It will be like having an avatar expert in the Theory of Constraints and Critical Chain scheduling overseeing resources, inventory, raw materials, and agile work units.

Once you've got workflow mastered, your agent may move on to risk management, estimating probabilities, imagining tricks and traps ahead, and formulating tradeoffs for decisions.

And, the decision-tree will certainly be a AI artifact, arranging all the branches, and working the math!

What humans do

Once you've got a 'process' defined for how to make a 'process' from a one-off, your human expert can go onto the next innovation, with an AI agent to tidy up behind!

_______________

(*) Inspired by a piece from Daniel Miessler, who opines: "Like, if you're a business, it doesn't matter what your best humans can do once or three times. What matters is what you can do as a process, with consistently high quality."

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Dodging the pandemic

---

If you're a PM running a project during the pandemic, you probably have one or more of these problems:

• Supply chain issues: stuff is out of stock; stuff is not available on time; stuff costs more
• Velocity and throughput issues: Throughput is slower to achieve; there's more overhead and NVA (non-value added)
• Communication errors: Remote work is really work with restricted bandwidth; nothing really replaces the high-bandwidth of in-person person-to-person communications, formal and informal. Restrictions introduce timing errors; misunderstandings; information gaps
• Matrix assignments: to keep people off overhead, they are assigned piecemeal to multiple projects. But this introduces commitment conflicts and start-stop inefficiencies
• Innovation MIA(*): Most innovation is a beneficiary of a lot of informal collaboration that somehow surfaces a neat thing to do. Such may go MIA with remote working

So, what is to be done in such an environment as described above?

• First, bring on the slack! You need to buffer every budget ... cost or schedule ... with slack (white space) that allows for the project to absorb small shocks in supply chain, velocity blips, resource conflicts, etc. Such a strategy is the essence of being "anti-fragile"
• Second, be aware of -- and react to -- constraints (bottlenecks) that may move about ... here and then there ... as external circumstances change. You may need to be at the top of  your game applying the "theory of constraints" (**). 
• Bring in redundancy and work-arounds to keep things moving. You may need back-up supply chain options, prototypes, and ability to work with reduced scope by applying redundant capabilities (instead of 10 blades in the rack, maybe you can work with just 6 that are essential)
• Add excess bandwidth to facilitate increased informality and opportunity for interaction.

Bottom line: Make everyone in your chain aware of the lean-in you are doing so that there is confidence and support for your PMO.

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

(*) MIA: missing in action
(**) Read about Elihu Goldratt's "Theory of Constraints" on Wikipedia or elsewhere

---

Buy them at any online book retailer!

Not a process person

---

Every project has them:

Some people are just not "process persons". They never do the same thing twice the same way
But more importantly: It would never occur to them to do the same thing twice the same way.
And, given a problem, they don't seek process; and really don't see why improvisation is not just as effective.

And, you couldn't label them "lean" either."Lean" requires process and tooling to minimize redundancy and non-value repetitions.

Nimble and opportunistic
If not process oriented, nonetheless these folks can be very opportunistic, grabbing onto a situation and solving it their way. Nimble, to be sure.

And, what's wrong with nimble and opportunistic?
Perhaps nothing the first time through.

Qualities you might value
But reducing whatever you are doing to its most effective process adds reliability, predictability, and portability---the ability to make the process work with others and other situations.
And, I might add: fairness---all is treated the same way, insofar as any process can be bias free

Frustrations
Did I mention that it's really hard to put together a team of non-process people? In the first place, teamwork brings a certain process orientation with it. And, in the second place, values don't align well.
"Getting it done" collides with reliability, predictability, portability, and fairness
Beware collisions!

The worst thing
The worst thing is when the team leader is not a process person; their disdain or disregard or insensitivity to process undercuts all else, leaving the "process people" with uncertain support or value-add. Bummer! 

---

Buy them at any online book retailer!

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 valuable 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

---

Buy them at any online book retailer!

Kanban at the Kitchen Table

---

Dana Rousmaniere and Frank Saucier collaborate in an interview to talk about kanban methods for the home. And, of course, it's all built around a kitchen table white board with some sticky notes.

Have you done this at home? I have; and it works... you wouldn't expect otherwise.

But, Frank carries it a bit further than I want to go. He has structured family meetings with a checklist agenda, and then daily check-ins on project tasks.
Whoa! that's a bridge too far for my wife ... no micromanagement here.
In fact, Frank admits: "There's sometimes some moaning and groaning... "

The larger point

But, of course, there's a larger point here: Almost everything we do, formally or informally structured, as some sequence and flow -- just think about driving to work, or walking in to open your home office at the beginning of the work day (or night)

Flow and process... sequential steps; they are the building blocks of everything

Now, the lean and kanban advocates are all about improving flow, thinning out the non value-add, and simplifying the process so that work flow and work process are pretty much birds of a common feather.

Then comes scale, even in the kitchen
Who can argue with lean? Does anyone really want to do the non-lean stuff, even if they have to? No one so long as the work flow on the kanban does not require coordination with other kanban's... in that case, we move on to scale, and scale brings overhead, and overhead brings flow control, and so we all slow down.

You don't see this much on the kitchen table, unless your home project is part of a larger project for a community organization -- then comes the bureaucracy of scale.

You might say that velocity and scale have a inverse correlation, perhaps even a causation -- larger scale, lower velocity

Is it too low tech?

"I like to use low-tech tools, because it’s more important to learn good habits than it is to learn to use a tool. That said, there are plenty of digital ways to do the same thing — a good, free tool is Trello, which is essentially an online Kanban board.

But, I find that with digital tools, a lot of great ideas get buried, and the simple act of moving a post-it across a visual board is very kinesthetic. I’ve also noticed that teams have better discussions when they’re around a physical board." Frank

What's the payoff?
With Frank I agree (from personal experience in the kitchen)

• Get priorities squared away
• Manage distractions
• Teach others the tools as a life skill
• Richer communications

---

Buy them at any online book retailer!

F.W. Taylor: should we care?

---

How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor?

Taylor Who?
You might ask: Who was Taylor?
Good question
F.W. Taylor was one of the first to study business systematically -- an original "operations research" guy. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced.

But, here's news you can use: much of what he divined is still around and affecting projects! Read on ....

Taylorism, so called
Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.

Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work.

Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].

Ooops, what about Agile?
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive.

Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.

Managers have a role
However off-base that idea, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures.

Waste must be eliminated!
Every action requires definition and a means to measure results.

OMG! Not a popular guy
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practises brought great efficiencies and profitability while providing customers with products of predictability of quality.

Do it once, right
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."

Beck gets it right
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry.

He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility

---

Buy them at any online book retailer!

Blitz-scaling

---

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

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

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

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

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

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

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

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

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

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

---

Buy them at any online book retailer!

Process breakdown structure

---

A coffee shop discussion on process redesign and process improvement led me to state the obvious to my caffeine-charged debaters:

Managers responsible for the business buy results [and outcomes], not process. Process, by itself, does not sell well; what sells is results.

Process per se is a tool.  For the most part, business people hire experts for their ability to deliver results; what tools they use are somewhat immaterial [to the business person]. The same for process redesign: the design per se is not the objective; the objective is better business results.

To help the discussion along, I postulated a "process breakdown structure", an obvious play on the WBS (Gasp! WBS! I can hear the agiliers running away .... come back! It's ok)


Of nouns and verbs
Just like a WBS is an organization of 'nouns' [outcomes or deliverables] that beget 'verbs' to explain the "how" of it, so also in a PBS

The PBS is fundamentally 'nouns'....outcomes of the process....arranged  like a WBS.  The PBS has elements of hierarchy--parent/child--and relationship [example: we all have a temporary relationship to each other because we are all engaged in this blog...I wrote it and you're reading it]

The first process improvement is to do away with nouns that aren't valuable.  Lean out the clutter and reduce the complexity

And just like for a WBS, for every noun there is a verb: the activities of the process.

Sequencing the verbs
We all know there is no schedule or time dimension to a WBS.  It's as if the WBS is the 'present value' of the schedule results; all deliverables brought back to the present.  Thus, sequencing has to be done elsewhere, and that is usually in the schedule

So also in a PBS: for each noun there is a verb, but the repository for verbs is the process activity list.  Take the nouns from the PBS and verbs from the process list, and you can just about write the narrative of the process.

Just add to the nouns and verbs the sequencing, durations, and dependencies that are properties [adverbs and adjectives] of the activities in the list.  String them out in a network and you then have the process in the usual format.

Resource the verbs
Verbs require resources. Minimizing the resources; leaning out the non-value verbs and sequences that consume resources; and resolving dependencies that add more friction than value is the way to improve the process.

---

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 Lord Beaverbrook model

---

Lord Beaverbrook, a genious in getting things done with big bureaucracy under the extreme pressure of war, had this philosophy

Organization is the enemy of improvisation
It is a long jump from knowing to doing
Committees take the punch out of .....  [fill in the blank]

------------------
Lord Beaverbrook was a close advisor and confidant of Winston Churchill during WW II. His genius: making processes work. His first job was making the production of aircraft stupendous enough to win the "Battle of Britain" in the air in 1940.

---

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

Eviction, and the Belady Algorithm

---

"Depend upon it: there comes a time when, for every addition of knowledge, you forget something that you knew before. It is of highest importance, therefore, not to have useless facts elbowing out the useful ones"

Sherlock Holmes

Keep it short
In computer science and data communications, the word "cache" describes memory used to store the stuff you are going to need right away, or nearly so. There are similar storage and rapid access  requirements in the PMO: all manner of metrics, action items, staffing plans, budgets, etc fill up short term memory -- stuff you need handy to work effectively each day.

And so, in describing this it's pretty clear that there are some stand-out needs for a memory system (*):

• Fast put-away and retrieval
• Handy and accessible -- you don't have to go looking for it
• Near-term stuff is always right on top -- at your finger tips, as it were
• And, whatever you are looking for is actually in the cache -- no "cache misses"

Eviction:

But, what do you do if/when the cache fills up? 50+ years ago a IBM researcher Laszlo Belady wrote a paper which more or less described an algorithm for the optimum cache eviction protocol -- after all, cache is by its nature limited in scope (it's not a cache if it holds everything)

When the cache fills up, evict that which is not going to be needed the longest from now

Good theory; not practical, actually. How would you ever know what you are going to need longest in the future? After all, we're seeking minimum cache misses, no matter when. Several eviction protocols have been invented and tested: Random eviction (just pick something and throw it out); First In - First Out (FIFO), or the oldest stuff goes out first.

It turns out that the strategy that comes closest to the Belady optimization for minimizing cache misses is "Least Recently Used". As the name implies, if you don't use it, lose it!

Keep it local
In these days of "the cloud", what does local mean? Behind the Internet scenes, there's a lot of action on that point. "Store Forward" and local servers, etc manage latency. And of course, physical fulfillment centers, whether it's physical documents or other other stuff, are now routinely popping up about the countryside. (One should not forget the local thumb drive, or (gasp!) a file cabinet)

Size the cache
Enter: Theory of Constraints. If the cache is actually a buffer or collector ahead of downstream production -- task orders, or parts and assemblies (code units, etc count here) aka "inventory", and the cache is larger than the downstream capacity it's serving, then the cache just fills up.

There's actually no point in taking orders -- or creating inventory -- you can't address. Send people away or refuse delivery! Building inventory before a constraint may make the upstream widgets/hour look good, but overall it detracts from the project effective use of resources. ToC has been around at least 30+ years; it's amazing how it seems like "new news" to so many.

--------------------------------------
For more: check out the chapter on caching in the book "Algorithms to Live By" by Christians and Griffiths

(*)

And, with recent events, we might add:

• Secure from hackers
• Private as required

---

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

Choose your box

---

Do you buy this idea from Mark Chussil?

A box is a frame, a paradigm, a habit, a perspective, a silo, a self-imposed set of limits; a box is context and interpretation.

We cannot think outside boxes. We can, though, choose our boxes.
We can even switch from one box to another to another.

Boxes get dangerous when they get obvious, like oft-told stories that harden into cultural truth. Letting a box rust shut is a blunder not of intention but of inattention.

Boxes are invisible until we look for them.

In other words: driving yourself to think "outside the box" is a box onto itself. The "outside box" is a box --- gasp!

---

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

Process: Reflection, refinement, tuning,

---

Any process that does not have provisions for its own refinement will eventually fail or be abandoned*

- W. R. Corcoran

Corcoran is probably correct --- but how would we know? There are a lot of processes out there, many have been around forever, many oldies still effective. But, I take his point: change, adapt, or fade away to either obsolescence or irrelevance.

Of course, naturally changing demographics takes care of a lot of this somewhat automatically. New organizations, people new to organizations, and young people without the baggage of experience all tend to reinvent.

And, why not? The wheels of today are far superior to the wheels of ancient times. Can you imagine taking your chariot in to have the wheels balanced? Not likely. Perhaps the wheel does need reinvention from time to time.

Of course, we digress: reinvention is not exactly refinement, which suggests tuning on the margins. Refinement is more about lessons learned, feedback, TQM metrics, and the like, all aimed at weeding out the ineffective.

Of course, if you are locked into some kind of maturity model or ISO certification, refinement is no small matter, as changes must find their way into documentation, training, deployment, and so on.

Nonetheless, I get it: change, adapt, or fade away to either obsolescence or irrelevance.

---

Quoted by Glen Alleman from "The Phoenix Handbook: The Ultimate Event Evaluation Manual for Finding Profit Improvement in Adverse Events, Nuclear Safety Review Concepts, 19 October 1997."



---

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

Remove all the friction

---

We've all done some process design; I used to hold seminars in process design. And whether you coach it, teach it, or experience it, you hear a lot about "friction"

Friction's is not all bad: we couldn't stop a car without it. In the process context, it is either the good cop or the bad cop:

• Good cop (or supposed to be): checks and balances so the bias of one person or entity can not overwhelm the process or dictate the outcome. (Too much of a good thing: see U.S. Congress)
• Bad cop (or that's what we say it is): Interference and non-value add actions that detract from the quality of the outcome, or perhaps the quality of the process (a.k.a "the experience")

Living in Orlando, the "experience thing" is big time stuff here. 20 miles down the road is the mother ship of "experience": Disney World... 30+ thousand acres of "experience"

Disclosure: I don't work for Disney, and never have as a paid associate, but I do volunteer for their sports program helping with all manner of sports events, so I'm "back stage" a lot.

Now comes along an insightful article from Wired about removing friction in the Disney experience. If you're a process person, you'll see a lot of what you know how to do in this story, writ large!

---

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

Big Agile

---

For a long time it's been "big data". Now comes the new coinage: "big Agile", or agile on a really big scale

It's all about scaling up. The argument, if there is an argument, is about whether to (a) add more process to handle more scale -- which is somewhat like saying add a framework which itself is often a surrogate for guided workflow processes -- or (b) just add more smart teams, pump up the collaboration so that everyone is doing 360's with everyone else, and apply a touch of process to tie them together. That's the recipe, or so we are told.

In reading stuff on this topic, I was struck by this bit of wit:

 Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behavior.

Dee Hock, former CEO of Visa

What more do you need? We have the Agile Principles; we have some methodology guidance (Scrum, XP, DSD, etc), so we've got it; that's all smart people should need.

I actually agree with CEO Hock on the big picture (said picture to go along with the other biggies: data, and now Agile): a light touch in governance is likely better than Taylorism: all jobs scripted and defined to a fare thee well. Why so? Simply for the point made by Hock: advantageous behavior arises where there is flexibility to be different and challenging.

But, let me put in a word for process, especially as required in "big Agile". If by big Agile you mean a half dozen teams, then perhaps you can get away with a pretty simple guidance paradigm: do no harm to the other guys, and check in regularly.

But if you are talking seriously "big Agile" with many distributed teams, lots of interactions and dependencies on a myriad of non-development stuff, like training and logistics, then it's not good enough to just have the "dots". There has to be a systemic and sustainable way to connect the dots, and that's what's embedded in process.

Try building a million lines of code contained within thousands of objects for an automobile, to take a relevant example, without some serious processes for handling interfaces, integration testing, validation of function and feature, and customer supportability, to say nothing of reliability, security, fail safe, etc  (Remember the Toyota thing with the unintended acceleration? Was it the software?)

---

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 is a process -- or not?

---

First, the agilists tell us that they are not slaves to process, like their traditionalist brethren are. Agilists are free! And then they tell us that you must, must, must:

• Release something every two weeks, or four at the outside
• Have a daily stand-up of no more than 15 minutes
• Have a retrospective meeting at the end of every iteration
• and, so on....

And, they tell us, these are not processes but rather practices. A process, after all, has protocol, input, controls, and output.... and these don't?

Nonsense. Agile has process like every other methodology; they may be shorter in duration but they are processes nonetheless

Now comes a really radical idea into agile land: Let's do away with these processes and really be free! No less an eminence than Mike Griffiths, an independent trainer and consultant who is steeped in PMI ACP stuff, who blogs at Leading Answers, has given us this wisdom:

It's not the process, stupid!

Here's the core of his argument:

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

• Sense making – agree information gathering steps and prioritize exploratory work
• Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting
• Consensus gathering - collaboratively gain consensus on direction, approach and decisions
• Prioritization – build mindful to risk reduction and business value
• Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates
• Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings.
Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail

Did you read that last point? That's a biggie!

The typical advice is do pilots as the training vehicle... Fine, I agree with that. But Griffiths might say (though he didn't) that the purpose of the pilot is not to train on the process but to train on the ideals and principles as listed above.

Fair enough.. But CAUTION: this stuff DOES NOT SCALE. If you have a few teams of really good people who work well together, Griffiths is probably spot on re doctrine, though I'll be even these teams migrate toward process they define for themselves and work for them.

But, if you're working at scale, you probably need look towards what Kent Beck did when he invented XP: practice and process discipline! Toe the line!

I see this issue in my Agile classes repeatedly as students tell me they intend to trade process doctrine for freedom, whereas what they mean is that they are going to trade traditional process doctrine for a more agile doctrine. For newbies, that's probably a good strategy.

---

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

Looking for an honest debate?

---

Are you looking for an honest debate? It's actually not a rhetorical question. Sometimes, we want to play with loaded dice, and we don't want the other guy to know.

But, for now, let's say you want to get an honest debate on some trade you have to make in the project. And so, you put up the trade space and ask for the debate.

How to proceed?

Michael Schrage, writing in the HBR Blog Review, posits this:

If your organization is having an important argument that gets everybody hot and bothered, don’t encourage compromise or collaboration. Insist that the most passionate and articulate advocates from each side make the other’s case.

Force the best and the brightest to publicly demonstrate just how well they understand the other.  

Does this really work? Schrage gives us Gladwell as an example:

Malcolm Gladwell of bestselling Tipping Point and Outliers fame proposed a delightfully provocative way to begin his onstage debate with Sports Gene author David Epstein about whether practice or genetics is the better guarantor of professional success.

But instead of launching directly into argument, said Gladwell, they’d start by summarizing their opponent’s best arguments. The exceedingly careful, precise and thoughtful characterizations of each other’s position that followed proved remarkably entertaining and informative.

And finally, Schrage tells us:

Managers and executives confronting serious strategic, operational or cultural disagreements on issues that matter should insist that their people be able to convincingly make their opponents’ case. This is not a joke, a gimmick or an intellectual exercise. It’s a public declaration of integrity: Fairly presenting a 360-degree view — both sides of a polarizing argument or wedge issue — is essential to honest and honorable discussion.

---

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 up's and down's of risk

---

Here's my observation:

Any large bureaucracy with the inevitable personal and public politics, territorial protections, and constant tussles for dominance will have risk attitudes that tend to run vertically, not necessarily shared, consistent, or coherent laterally by process.

So, as a transaction progresses laterally through an organization, it will be buffeted or influenced by different risk attitudes as it crosses vertical boundaries in the process flow.

And, of course, as the apparent risk changes -- I say 'apparent risk', but I'm really referring to the transaction's utility -- then the SWOT of the transaction changes complexion.

In other words, what may be of great utility to me won't necessarily be of great utility to you -- so I'll support the transaction -- it's an opportunity -- but you may not -- it's a risk -- and so it gets stuck in the process unless "the big guy/gal" kicks it loose.

Counter measures
The way to keep things moving is by finding and then supporting an interest that favors the nemesis but yet is tolerable to you. After all, transactions don't have friends, they just have interests. If it favors me, I'll help push on that rock.

Sometimes, as anyone who has found this magic knows, an interest needs to be created where it does not naturally occur.

Who has not seen a totally irrelevant idea/need/favor attached to something to create the necessary grease to move things along? So long as there is legitimacy, transparency, and lack of personal corruption, so be 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

Swimming with Agile and the WBS

---

WBS? Agile? Swim lane?
Do all these belong in the same paragraph?

The WBS can still have a valuable place in the agile project, but at a higher level -- less detail -- and certainly ties product development to other swim lanes or work streams in the project, and certainly the WBS applies to other than development that is going along with agile.

Some caution: "swim lane" and "work stream" have the image of relatively few points of contact and interface -- at the beginning, at the end. In an agile project, there are many scheduled points of contact with these other streaming activities, not least at every release review.

Ooops! You don't know what a swim lane is? We read at Modern Analyst.com that a swim lane is a process diagram with this feature:

... swim lanes communicate additional information about who performs the activity or when it takes place. [Consequently] it’s typically a preferred best practice to include them.

---

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

Process vs Practice

---

I am constantly amazed at the number of PMs -- presumably experienced -- that I speak with that don't seem to grasp the idea of "process". They all seem to know practices: Risk management, change management, chartering, earned value management, etc, etc. But, ask them about how a practice fits into a process and the veil drops.

So, back to "Process 101": Input --> practice --> initial conditions, outcome with controls, constraints, and policies as modifiers/influencers on the practice. See Six Sigma and any of a number of other doctrine -- like PDCA -- about processes and process control.

And, this matters because: Because it's about dots, connecting the dots, and having a project narrative to govern by. Narrative is what makes the connection between the business case and the project charter. There's got to be a process to get from 'dot #1' to 'dot #2'.

It's probably too much in a "101" discussion to bring in the idea of process networks with nodes, connecting links, link protocols, and work flow. But, if I ever get the "201" level, those will be ideas we'll explore.

However, even at the '101' level there should be room for a discussion of 'lean' practices -- some say lean processes -- that try to optimize the value add of the process and minimize the waste of overhead. One approach is to look at batch sizes and try to find the minimization where overhead and batch size seem to work together, and to look at parallel/serial task flow, again with the idea of value add maximization.

And, at the '201' or '301' level we might bring in the Theory of Constraints to look at how moving/redesigning a constraint can reduce the cost of the process -- by reducing the cost of process inventory at intermediate steps -- and maximize the throughput.

So, with all this stuff, perhaps I should not be amazed, but I still am.

---

Bookmark this on Delicious

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