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.

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!

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

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.

---

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

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!

---

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

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

---

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

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

---

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