Friday, February 27, 2015

Business literacy

In a recent essay, we learn that law students are now beginning to get courses and intern experience about running a real business. How novel! People who work for money acquiring an understanding of how money is made in a business.

Now, looking through the PMBOK and similar guides and manuals, you'd be hard pressed to find much from a MBA agenda or even basic accounting for non-financial project managers. I'm constantly amazed at the blank stares I get when I talk about the general ledger and the chart of accounts for the project, or the balance sheet, or the cash flow analysis. Hello! Is there anyone home?

Usually there is some sign of life when you bring up NPV -- they say: "isn't that the effect of time on money?" (Actually, not exactly. It's the effect of risk experienced over time, but let's not quibble if life is stirring)

And, there's actually no excuse anymore. You can find free downloads of ebooks of the dummies' guide to an MBA. Or, gasp!.. go to a library. Actually, in the downtown City of New York public library I recently observed that the reading rooms were full of young people staring at Mac's. (Off axis question: why are there no PCs in the reading rooms?). In fact, the NYC main library was about full... just sayin': people use libraries.

And, of course, talk to your F&A person... I'll bet they'll explain the Chart of Accounts for your project quite readily

Let's banish business illiteracy!

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

Wednesday, February 25, 2015

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

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

Monday, February 23, 2015

Never stop learning

"I advise my students to listen carefully the moment they decide to take no more mathematics courses. They might be able to hear the sound of closing doors- James Caballero." "Everyone is a Mathematician CAIP Quarterly 1989*

Well, not exactly

It's better written this way in my version:
My advice to everyone is never stop learning; what that means is continuously improve the mind in professional skills, people skills, and outlook. When you decide you've learned all there is worth knowing, you may be able to hear the sound of closing doors.
*As quoted by Glen Alleman

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

Friday, February 20, 2015

Let'em figure it out

"Let them figure it out" is the mantra for small team management at its best. I'm constantly amazed at how fast and successfully small teams converge to a local optimization, finding a methodology for doing whatever they are doing that maximizes their interests.

In several recent situations I was an observer and a participant as 20 or teams of anywhere from 2 to 6 people were given the same task, given the same instructions, given the same resources, and had the same strategic goal.

What happened?

There were about a half dozen unique methods that were synthesized in real time, tested, and the most advantageous selected. What I noticed were several dynamics working nearly simultaneously:
  • Self organization: who is going to do what -- mostly, a volunteer thing as to who does what, though informed by task, skill, and capability of the team members
  • Convergence: fail quick, fix, and retry til it's working well. You can feel it when the non-value add stuff dissipates and it's all about value-add
  • Local interests: Local interests are both personal and team oriented. Each person tends to maximize their own interests to the extent that they fit in the overall team envelop; and the team optimizes to max out their contribution to the strategic goal
And the PMO? The PMO was there to set the strategic goal; put the resources in place, having recruited the teams; and knock down the issues that were not foreseen. And, lest it not be forgotten: to provide feedback during and after -- both a real-time incentive, and a after-action atta-boy

This stuff actually works! But, did I mention virtual teams? Virtual teams have less bandwidth and so their velocity is correspondingly less. Convergence times are greater, etc. But, the principles apply

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

Wednesday, February 18, 2015

Points v hours re estimating

You're probably fluent in "hours" -- anyone who's managed to acquire some seniority in project management can speak to hours, think in hours, and reasonably compare one effort to another if given hours.

Fair enough.....  But are you also fluent in story points? Or other estimating surrogates? Can you think in one and then think in the other, fluently using each to its best advantage?

Mike Cohn, who wrote a really good book -- perhaps the Bible -- on estimating agile projects, has a posting that tells us to be multi-lingual so we can estimate different horizons in different languages. Or, better said: Use the most optimum language according to horizon.

His recommendation:
  • Points for the far horizons -- as in several sprints ahead -- and
  • Hours for the close in stuff, like the sprint right in front of you.
So, what's the rationale here, and is it the right thing to do?
  • Long term, we tend to look for similar experiences for guidance. Long term it's more like: "Is it bigger than a breadbox; smaller than .... ?" (I actually have never seen a breadbox, but I can imagine a box to hold a loaf of bread -- I learned that expression right out of engineering school, and it's stuck)
  • Long term, we naturally tend to think in analogies, less so in scalable metrics, so breadboxes and points come from the same modus operandi -- analogies. And, points have the advantage of being easier to add and average than breadboxes.
  • Long term, we are interested in average performance, albeit with unusual long tail events thrown out because their circumstances are not likely to repeat and thus to include them will distort the average
  • Short term, we can see from today until tomorrow and it's easy to switch languages and say: That object is going to take X hours to test or to refactor, etc.
Then no less a renown software eminence than Ron Jeffries weighs in with about the same idea: short term, do it one way; long term, do it another. But Jeffries has a larger mission: getting rid of estimating as constituent of software development! Though he also says, estimating isn't going away, so lets make it work for us to get to the real project objective: Value. I can buy that!

Then, related to the long/short term thing, in an email "info item" about estimating, brother Mike goes rogue:  OMG! Cohn says: you don't have to do estimating if you don't need to prioritize or if no one is asking for predictions.

This is akin to: If the tree falls and no one hears it, was there a sound?

My comment to this advice: NO! (Strong message follows). A project -- or a personal task -- without estimates is totally blind to the future possibilities and probable outcomes.

Frankly, it shouldn't matter to you who wants (or doesn't want) to prioritize -- everything that is otherwise not governed by the physics of sequencing requires some prioritization -- and every consumption of resource should be considered in the context of scarcity: all things are constrained! There's no "limitless" anywhere.

For more on this general topic -- if you're really a non-believer in estimates -- I refer you to the numerous blogs and twitters on #NoEstimates! A good place to start is here.

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

Monday, February 16, 2015

Project Management the Agile Way -- 2nd Edition

When they call and ask you to write a second edition, you really can't say no. And, thanks to all who have bought the book and read it. Your support is what drives the publisher to ask for second go around.

And so what's coming in V2.0?
  • When is Agile DONE?
  • Agile in the waterfall -- or Agile, the Hybrid
  • Transitioning to Agile
  • Discussion questions for critical thinking
  • Modular design within chapters -- Sprints for reading?
  • More web-based bonus content

Look for it this fall!

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

Friday, February 13, 2015

Know everything but understand nothing

Big data. We know it all, but do we understand anything really useful? Lord, I hope so!
Data warehouses abound, the cloud is ever bigger, data flows in by the billions of bits, and yet:
  • projects still fail; some spectacularly, even with Kanban boards filled to the brim
  • businesses still can't find the winning recipe, and
  • others walk off with $billions of profits -- why not me?
Well, you won't find the answer in this posting. If I knew it, I'd make my own millions with it (probably not billions, but who knows?)

But it does seem a modern conundrum that with ever more data, project successes creep ahead -- and surely the trend line is a bit more positive than it might have been -- with agile methods giving a bit better results to smaller scale software projects (more scale coming as we figure out how to do it effectively), more speed in the project office with better tools, and surely better productivity per contributor.

But, alas, alack: We still get the headlines about woeful project performance, challenging our profession to show value add (do I really need to pay a project manager to get bad results? I can do that on my own!), even as robots and uberization are on our doorstep!

Will more data help? More information on requirements? More information on the science? Surely it can't hurt so long as it can be processed and reduced to something actionable.  I think that's the key: if you had the data, what would you do with it? If nothing, then don't collect it; certainly don't pay to process it.

Perhaps understanding can come with less data! OMG! Is that possible?

Wednesday, February 11, 2015

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?


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."

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

Sunday, February 8, 2015

Agile: the meaning

Dilbert: We need 3 more programmers.
Boss: Use agile programming methods.
Dilbert: Agile programming does not mean doing more work with less people. Boss: Find me some words that do mean that and ask again

Dilbert is a creation of Scott Adams
And so, you might ask: what does agile mean?

How about this?

Agile means getting effective project results even in the swirl of complex and uncertain project requirements, primarily by applying small teams, working collaboratively, to deliver increments of business value, with priority according to business effectiveness, importance, and urgency
Ooops! I seem to have left out anything about process. Is agile a process-free zone? Of course not! No one does anything functionally without applying a bit of process, even if it's only two steps.

My observation -- and personal experience -- with myriad small teams is that they self organize to optimize their self interests amazingly fast, first trying one process -- perhaps a baseline process -- and then quickly shifting to another to find a "local" optimization. Sometimes there's an obvious leader; sometimes it's all for one; one for all.

When/where collaboration improves their lot, they'll readily collaborate. Where it's problematic is when collaboration demands are laid on top-down with no obvious improvement in the local process and no apparent connection to goals or objectives. If the top-down thing is legitimate, then the project leadership needs to get in the communications mode to show how all the dots connect! 

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

Wednesday, February 4, 2015

Components, objects, containers

Thirty years ago the big evolution in software was objects, and the objective of objects was to make software more like hardware insofar as you assemble objects into systems, and then address the object through a specific interface -- the API, or application programming interface.

And, no small matter, the objective of object programming was to transform software art and science into software engineering, a direct parallel to hardware engineering: make things according to spec's, assemble them at their interface, and they work!

And, of course, reuseability: design and build the object once; reuse it many times. Within the the object, components are just the lower level blocks within objects.

Then, of course, virtual machines and run-anywhere language, like JAVA, which gave rise to portability across different hardware. Just bring your VM and objects with you and you can run anything anywhere

What's not to like?

Well, the weight of a VM for one. A VM operating system is no small matter, and sometimes it's just overwhelmed. And, the cloud raises the scale of things, making the object a bit too low level.

Now comes 'Containers', and analogy is to the shipping containers that come on trucks and ships. Containers have been around about a decade, but lately they've gotten more buzz with the cloud. The advantage is that containers have boundaries and interfaces something like objects, but they typically contain many objects that give rise to an application, and containers run on over a lightweight "engine" that is less burdensome to the host than a VM OS.

But here's the news for many project offices: In some cases it's practical to take existing large scale programs and restructure them into many smaller containers.
Gilt Group, an online store, turned seven big applications in its website into 400 smaller pieces, making it easier to update
PMO and Containers
Two advantages:
  1. Now your PMO has a library of reuseable containers, making estimating your next project all the simpler, but
  2. Also you're closer to the Agile world of smaller functional units, and units that can be used in shorter smaller scale iterations to build functional entities.

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

Monday, February 2, 2015

Change v Transformation

Change: things are different, or will be. Often a matter of process and function
Transformation: Change + values or philosophy that are changed as well

Ron Ashkenas tells us in an essay that we still don't get it, some 10 years after notable John Kotter wrote his seminal article "Leading Change: Why Transformation Efforts Fail." Some say 30% or more fail. Of course, this begs the question: what is failure, or perhaps harder: what is success?

Ashkenas says:
"Unlike change management, it [transformation] doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting.

More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future.

It’s much more unpredictable, iterative, and experimental. It entails much higher risk. And even if successful change management leads to the execution of certain initiatives within the transformation portfolio, the overall transformation could still fail."
Of course transformation is unpredictable! Who can say where a change in beliefs and values is going to lead? Who can say if such is really a good thing.

We can put parameters around objective change management stuff, but it's hard to measure, much less predict, non-objective phenomenon. About the best you can do is look at the A/B situation: A: the way it was; B: the way it is now.

A/B testing is a big thing in many projects these days. How else to actually evaluate things? So, is it change or is it transformation? Usually the former shows itself right away; the latter may be generational (See: transformative politics)... You'll just have to wait and see; or better yet, get promoted and have someone else wait and see.

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