Friday, January 30, 2015

Uberize the project team

To add to the lexicon of project management we now have:
  • To be uber'ed
  • To uberize
  • Uberization
Say what?

In an interesting essay, we can now see ahead to the uberization of many technical tasks, to wit: any time work can be put in finish-to-start segments, we can hire the expert-of-the-moment to do them. It's much more flexible than contracting for an independent for an extended term, like life-of-the-project.

Oops! Did someone say 'finish-to-start'? Isn't that what project schedules are all about?

Is this the uber'ed PMO:
"Just as Uber is doing for taxis, new technologies have the potential to chop up a broad array of traditional jobs into discrete tasks that can be assigned to people just when they’re needed, with wages set by a dynamic measurement of supply and demand, and every worker’s performance constantly tracked, reviewed and subject to the sometimes harsh light of customer satisfaction"
Farhad Manjoo

OMG! We're just getting around to figuring out where robots fit into the project, and now comes uberization. One can only wonder how the PMBOK of 10 years hence (10 years? perhaps five!) will be written.

Thursday, January 29, 2015

History is always someone's opinion

As project managers we always have one eye on the rear view mirror:
  • Project history databases provide the benchmarking for new estimates
  • Benchmarks set the velocity goals for Agile teams
  • Actual data form the coefficients for equations -- usually linear -- that purport to forecast the future (See: earned value linear equations for efficiency and cost/schedule to/at complete)
  • Track records are used to vet vendors, contract employees, and justify promotions.
To wit: history is all around us!

And, we note:
History is always someone's opinion!

Thus: history may not be objective. We hear this missive repeatedly: you are welcome to your opinion but not your own facts. Well, swell, if the facts are indisputable, but often they are not. Facts and opinions mix right at the outset, so not only are you welcome to your opinion, but you may be authoring your own facts, welcome or not.

And then comes biases: there are so many boutique biases that it takes pages to define them. So, again, as thinkers, we're not objective, and go for that! It would be unimaginable not to have imagination... of facts and history. In other quarters, it's called revisionism, one of hundreds of "isms" to go along with dozens of biases.

Thus, beware the admonition to look to history for objective facts. We are told the best decision making is fact-based... but only if you are welcome to your own facts!

Monday, January 26, 2015

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.

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?)



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

15 ways to communicate or improve communications


Some New Year's lists are more practical and useful than others. Here's 15 ways to get leverage out of your communications. Given the center spot of communications in our business, this list -- from "A girls' guide to project management" is worth a look.

One suggestion you don't see all that often is this one:

6. Create a communications asset register A communications asset register is a list of all the communications assets that you have created for the project. That includes:
  • Newsletters
  • Press releases
  • Internal magazine articles
  • Posters
  • Flyers and leaflets
  • Photos

And, of course, there is this one that is ageless:
3. Use checklists
  • Create checklists for tasks that you do frequently like hosting Project Board meetings or project kick off.
  • Checklists are in use in hospitals and airlines because they help people remember everything they need to do and ensure nothing gets forgotten.
  • Pick a few tasks that you struggle with (for me it’s creating POs and then paying the invoices) and create a checklist so you don’t have to think about it anymore.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, January 23, 2015

Done, as in Agile DONE


Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... definition of done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my DoD as it were has been these three questions:
  1. Is it done when the money or schedule runs out?
  2. Is it done when the sponsor or product manager says it's done?
  3. Is it done when Best Value* has been delivered?
    * The most ,and the most affordable, scope within the constraints of time and money
If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical DoD would be something similar to:
  • The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
  • The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
  • The code was either pair programmed or peer reviewed.
  • The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
  • The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 
Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. In other words his theory is tested in the crucible of a trying to make money or fulfill a mission by writing software. How swell for us who read Cohn!


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, January 20, 2015

Intruder alert


Cyber attacks are in the news almost daily, and certainly high profile projects, or projects in high profile businesses are not immune. Indeed, theft of proprietary project information is high on many lists of the criminal mind.

Of course, your IT should be on the case, but it might help if you can talk to them a bit in their language about how safe are your project proprietary files.

Here's a nice primer from one the US national laboratories at Los Alamos. The article is in one of the back issues -- November 2013 -- of their Science and Technology Magazine (free online subscriptions)

Unfortunately, the theme of the article is: they're going to get in. The trick is detect the intrusion and then mount countermeasures. It's a play on: for success "they have to be right only once; you have to be right every time"

Of course, one is led directly to Nassim Taleb with two big ideas:
  1. Black swans: I can't imagine it could happen to me, but of course, it can! Thus: heads up! if anyone actually needs that advice in this day and time.
  2. Anti-fragile: I can sustain a big shock and keep on truckin' (or, if I am doing my systems right, I can sustain a big shock, else I am in a world of hurt)
And one is also led to one of the key principles of system engineering: loose coupling, and the ability to decouple quickly (read: instantly) -- that is, disconnect and isolate. We've been loosely coupling railroad cars since 1840 or thereabouts; we've had ejection seats in aircraft since the '50s... why not computer systems?

Personally, I keep anything important on a physically disconnected drive. It's only connected for short periods to get updates. The cloud is a step in this direction, but even clouds are not as safe as physically disconnected storage.

So, you've been warned, as if you've not read this stuff before elsewhere


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, January 17, 2015

Integrity is free... or should be!


In an essay recently published, Elizabeth Doty, in a take-off on Phillip Crosby's "Quality is Free" idea, as told in his 1979 book of the same title, tells us:
Integrity—or lack thereof—remains a critical challenge for companies today. Whether it involves promising a client that our software will work in their setting, adhering to investment guidelines with people’s retirement savings, or performing the correct medical procedure, we owe it to our customers, employees, shareholders, and the world at large to be responsible about what we commit to and what we deliver.

Now we are not given in real evidence of the criticality of this challenge -- we are pretty much left to think of our own experience -- but it's suggested that there is a "commitment drift" that may have settled in.

There seem to be two elements to the drift idea:
  1. We're really not committed, so the integrity of promises made is more of a fair weather thing... if things go well, you get what you expect, but if there's trouble, the commitment may be lacking, or worse: corners are cut to give the facade or impression of integrity
  2. We're committed but we've over-committed, so the integrity of the promise is more of Ponzi scheme
The remedy for this drift seems to be the well known formula: under promise, over deliver. To put this to action for PMs we do these things -- which, by the way, are "free", only to cost something if not addressed up front:
  1. Do not accept single point estimates for anything, because that means no serious thought has gone into the downside
  2. Do not schedule without buffers or slack, because no plan survives actual performance
  3. Do not not plan: that's just stupid to start off with only a hope and no real plan
  4. Do not expect performance to emerge where it's not even promised -- example: miracle occurs here!
  5. Do speak truth to power; eventually you are going to have to face them, so earlier is better; later will clearly get you a demerit
  6. Do walk away if your personal integrity is challenged... your reputation is leverage: don't give it away

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, January 14, 2015

Baselines, baselines


In a recent Agile class I facilitated this discussion re baselines:

Student 1:
 "I have a new Operations Director, and he says once you've missed a date, you re-baseline, and the item is no longer indicative of a bad/out of date status. In previous positions, we didn't always or weren't allowed to do that, so that they could track the original dates vs. current progress. Just wondering how others handle this."

Student 2, in reply:
"When I baseline a project, it is once and done. How can one measure truly the progress and planning of a project if the baseline is reset every time a date is missed? I agree that this would indicate a false sense of progress, a false green.

The only exception I can think of is if the project plan introduces a significant change that is approved by the project board and sponsor that impacts greatly the objectives and especially the schedule.... "

My facilitation:
Not exactly!
Re Student 1: if  you've missed a date, that's a variance. The baseline is still the plan you are managing to so long as you are trying to recover the schedule.

Re Student 2: "once and done" doesn't work either. There may be many reasons to rebaseline as the project goes along. It's not like you have a budget of 're-baselines' and you can only use so many. However, the key to the whole thing is the second point: "... significant change approved by the [controlling authority..]"

So here's the thing: first common sense always applies. In most non-trivial situations you have two plans at all times:
  1. The baseline which is the agreement between the sponsor (business) and the project
  2. The operating plan which is the day-to-day plan derived from the baseline
As project manager, you must have a strategy to merge or bring together the operating plan and the baseline so that at the end of the day, the baseline is the plan of record... all variances of record are measured against the baseline.

Now, if it becomes the situation that the baseline is no longer valid -- approved changes, etc -- such that there is no practical way to merge the ops plan with the baseline, then you rebaseline:
  1.  Record and archive all variances to the baseline -- B1
  2. Replan the project; this replan becomes the second baseline -- B2
  3. At the project conclusion, sum the archive of variances from B1 with the variances accumulated in B2. These become the cumulative variances of record.
To wit: you get no free lunch on variances just because you re-baselined. And, this is the deal in Agile or traditional... no escaping there either.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, January 11, 2015

The shape of the table



The shape of the table matters. Ask anyone who has negotiated.

Want to even the playing field? Make the table round.
Want to be agile? Make the table round.

From tables to agile? How did that happen?

One way to get agile -- or increase agility, or velocity -- is to purge hierarchy. Flat is better. Square is ok; round-and-flat is better yet. There is no head of the table. At least by seating, there's no chief among chiefs, though in every group or team some dominance will emerge.

We can extend round-and-flat to portfolios -- all projects equal; and to projects -- all work streams equal; and to the WBS: all major activities equal.

And the advantages of round-and-flat are: less hierarchy; less dominance; improved safety; shorter and quicker lines of command and communications; more lateral interaction; and close-at-hand working to foster innovation. From all this we get a better ROI: more production at less cost.

What's not to like? Really, nothing, unless you are a control person. In that case, you may be pretty uncomfortable.

You ask: what about a virtual round table? Does that work for remote workers the way it works in a co-located venue?

Not exactly.

Remote working has a slower velocity, and a poorer track record of innovation. We are social, and do our best work in a social environment. It may be only you and me; but generally it holds that even if only pairs, the paired environment works better than the sole contributor. (If you really are working alone, add some background, audio or visual: music, chat, even TV with the sound off.)

Take away message: go round!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, January 8, 2015

The no-math math book



This is a story about an inability to accept change that ended as you might predict. -- or perhaps it's a case study in organizational change management --

And, we find this story in a history book, or perhaps it's a math book. In any event, it's not too often that I feature a math book here on Musings. But, making an exception, let me describe a math book with no math -- or, actually, it's a history of math book with no math. I'm talking about "Infintesimal, How a dangerous mathematical theory shaped the modern world" by Alexander, an easy-to-read history of the early life of calculus (I hear you yawning!)

And we should care?

Actually, about the consequences of not accepting change, the book is very instructive, with obvious lessons for the big organization, project or business.

About "infintesimals", the concept is used almost every day: without it, project managers couldn't make simple statements -- though certainly important statements -- like 'the confidence of finishing the project on time is 60 to 80%'. Confidence intervals are the consequence of a bit of calculus on the underlying probability distribution.

So, what do we find out in this book:
  • The concept we now call calculus began emerging in the early 15th century in Italy. Emerging insights... now there's a concept for you!
  • The Catholic church -- actually, the Jesuits -- fought it tooth and nail for nearly 200 years. The Jesuits had a full-blown monopoly on universities and university curriculum, so they didn't need or want changes
  • One of the most accomplished mathematician of early calculus was an Italian who fled the Jesuit grip, settled in France in the 18th century to develop his theories -- and French-fried his name to Joseph-Louis LaGrange. Thus ended Italian dominance of mathematics.
For me, the most revealing thing was the iron grip that the Church -- and the Jesuits -- had on all of mathematics for so long a time, not waning until the 18th century. What was the Church's interest, and why so protective? Control of their university monopoly for one thing; but the real agenda was control of the public thinking of virtually all the mathematicians and scientists, some of whom challenged the  orthodoxy of the Church.

Ooops! Challenge a top-down rigidly hierarchical organization with a lot to lose if toppled? That's trouble, with a capital T for sure. So, what's going on here?

First, in the 15th and 16th century, math and science was part of the philosophy curriculum -- that is, beliefs and secular truths. Though we might find religious control of math an oddity today, the intersection of science and religion continues to vex in the 21st century, some 500 years on.

Second, Paradoxes ... they, the Jesuits in charge -- couldn't accept paradoxes because everything was supposed to be neatly and hierarchically ordered by the Devine. Paradoxes were viewed as a form of disorder that no Divinity would sanction. Thus, no earthly curriculum could sanction them either.

And the paradox that caused all the angst? Infinitesimals! Or, the infinitely small. Why should the Church care what mathematicians were thinking about really small stuff? Because at time, the principal math was geometry, based on very orderly and hierarchical bottoms-up proofs. But, infinitesimals are not geometric with bottom-up proofs.

And, a bottoms-up orthodoxy supported the top of the heap. Thus, any challenge to thinking or constructing things from lower order proofs was a challenge to the hierarchical constructed organization. To challenge one is to challenge the other. 

So, what is this infinitesimal idea? Using the 16th century notion -- still valid -- it is the idea that any geometrical figure, like a line, or a surface, or a solid, can be subdivided endlessly into ever smaller increments. A meter long line can be divided into decimeters, and then into centimeters, and then into millimeter-long increments. If we want the line back, we merely multiply 1000 increments of 1 millimeter each.


So, from millimeters, we can go on subdividing  until.... Until in the limit, there are a nearly-infinitely large number of such increments, each of nearly-infinitely small size (read: all but 0 size). Thus arises vexing paradoxes, in the limit:
  • Infinity of increments x 0 size of each increment = something finite (the dimension of the original geometric figure)
  • Infinity / Infinity = something finite (the ratio of two similar geometric figures)
The Jesuits were having none of it; but, as we know now, infinitesimals are the foundation calculus. Something like Einstein who famously rejected quantum physics because he declared that the Devine would never sanction a probabilistic location of small particles. But, now we have physical proof of that very thing. Just as calculus is accepted as mainstream math.

And, what happened to the Jesuit's monopoly and the Church's grip on the thinking of mathematicians? Well, the monopoly is certainly all gone; and the mathematicians of the day fled to Protestant states, like France, England, and Germany. And, pressed on.

And, the thus the change management lesson is written: Beware the ankle biters with emerging and new concepts to offer. Change or perish!


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, January 6, 2015

Good ideas ... testable ideas



Do you buy this?
The most irritating innovation insight .... seems paradoxical, but it’s true: good ideas are bad for innovators.
Michael Schrage thinks so as he writes:
" .... the successful innovators I observed spent less time on identifying and developing good ideas and more time testing their hypotheses. In fact, these teams and groups made the testable business hypothesis the center of their innovation effort."
Of course, the point he is trying to make is that a testable hypothesis may lead to innovation, and if so, then by definition, the underlying idea is good; whereas some other good idea may not be testable and so more or less ends without benefit.

Is this insight useful to project managers? (I hope so, or why write about it here?) Consider:
  • A testable hypothesis is "shovel ready", to use the political vernacular popular in the U.S. That is, if it's testable, then it's got to be a shorter timeline with less investment than some competing idea that is not.
  • "... business hypothesis is a testable belief about future value creation. It is not a search for truth or fundamental understanding; a business hypothesis suggests a possible or plausible causal relationship between a proposed action and an economically desirable outcome.
     
    If there is not an explicit and understood measure or metric for that new thing, it is not a testable business hypothesis. And if it isn’t in writing, agreed upon, and shareable, it’s not a business hypothesis. Many good ideas fail on all counts above."
Causal relationships, agreed upon, and metrics: what more could a project manager want?

  • The causal thing is harder than you might think, since the business is often not stationary, moving under the project and thus disturbing cause-and-effect.
  • And "agree upon"... would that it be every time!
And metrics! We can all sign up for that. Nothing like a measurement to spur things along
So, anything new here? Likely not, but sometimes it just helps to review.




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, January 4, 2015

Deep Smarts



Deep smarts: Experience-based business-critical knowledge

Dorothy Leonard
Deep smarts: when you've got them, you want to keep them.

In the project business, deep smarts could be the SMEs with the bona fides in some technology or knowledge domain that win new business -- those individuals that are the discriminating difference between winning on exceptional merit, or a me-too offer that's probably only got cost going for it.

Or, deep smarts are what leaders have that makes the difference between delivering discriminating and strategic business value, or simply another entry in a crowded space.

And the issue is? ....

These folks know their value and they not prone to shoot themselves in the foot, to wit: if an attractive offer comes along, they might just take it!

And, they may be just a bit self-serving (actually, who isn't from time to time?) as they may "hoard knowledge", building an asset for that possible day. (Who's not proud of the experience they have, or the special capabilities they've developed?)

But anyone who has tried to do "knowledge transfer" as both associates and consultants walk out of the door know that it's no small matter to be effective in retaining the know-how in-house.

Indeed, whenever I've added consultants to a team, I've always assumed that my investment is short-lived. That my ROI from staff has to be immediate, because there's no long-term future, benefit, or return coming from temporary staff themselves. Thus, their contribution has to be in the sustaining difference made in the business itself -- everything else walks on.


Dorothy Leonard has addressed this issue for us. In her book "Critical Knowledge Transfer" -- with co-authors Swap and Barton; and in an hbr.org she makes these points:
Lack of time or resources can, of course, constrain knowledge transfer. But one barrier to passing deep smarts along to the next generation that is often unaddressed is the expert’s inclination to hoard knowledge.
Financial incentives, personal ego, and discontent or frustration with the company are three of the top reasons individuals choose to keep their expertise to themselves.
But they’re also three issues that managers can actually change.

And, so what to do? My approach:
  • Pair up: from the outset, pair some permanent staff with the temps. Give the paring a mission: No knowledge hoarding!
  • Exit plan: Figure out what to ask, and how to capture the answers as the SME prepares to leave. Be sure to let the SME know what they can't walk out with
  • Retention incentives: when someone announces an untimely departure, try for an extension with a retention incentive but only if there is commitment to share knowledge
  • Document: if it's intellectual property per se, document it, but don't forget the non-disclosure agreement. You might even file a patent or record a trade-mark
  • Non-compete: if you're concerned about a SME walking over to a competitor, a non-compete agreement may be required
  • No enemies: Avoid the burning bridge. Stuff has a way of coming back, and you might just find that useful
  • Kiss-and-tell: You might want to get an agreement on any pre-approval of post-employment tales that might find their way into social or professional media, publications, etc.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, January 1, 2015

Happy New Year!



Happy New Year!
 
 

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com

Read my contribution to the Flashblog