Start-up in large enterprise

---

Brad Power says this in a blog posting that caught my eye:

"In this world, customers expect their suppliers to surround their products with data services and digitally enhanced experiences. This means that many organizations and their leaders are running as fast as they can to quickly build their software capabilities."

And, for the PMO, it more or less means answering this question posed by Power: "How can these companies overcome the inevitable leadership, organizational, and cultural challenges involved?"

Actually, that's a tall order. Change:

• Leadership biases, perhaps even biases against doing software at all ("we're hardware ... ", and so forth)
• Organizational biases, perhaps separating the hardware from the software (OMG! I can't let go of the product software!)
• Cultural biases, like run fast, when perhaps it's been years since we've done any running

Power claims that there are units within large corporations that have been successful. But Power tells us there were questions that were hard to answer:

• How to reorganize: project, functional, or some other?
• Who to run it?
• In-house or out-source?
• Where to locate in the world?
• How to connect and integrate it to existing product lines? (did you ask what "it" is? And, is the mother ship friendly or a foe?)
• How to change the business scorecard, and
• How to change compensation plans to go along with these changes (Oh, that's a biggie!)

Probably Power is right when he says address the first two, and then have the team address the remaining questions, though it will take C-level support when you get to the business scorecard and the comp plan.

Oh, did I mention hiring the kind of people you might not have even looked at before? And, by the way, they look different, dress differently, and demand an environment that is likely a lot different.
Should they have the same comp plan and career path, or something custom to their needs?

And, gasp! Agile... we have to put up with that as well. There goes the neighborhood.

This stuff is hard. The main message here: allow for lots of time, because it's going to take lots of time. Don't build any project schedules without some slack; you'll need all you can get.

---

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

No Dice!

---

It seems that every PM starts with dice or coins to understand both probability and statistics -- mean, variance, sigma, etc

Fair enough; it's not a bad starting point. Everyone has thrown dice or tossed a coin at one time or another.

Here's the things to know if you try to port your experience with games of chance, like dice and coin tosses, into the project domain to address risk and uncertainty.

First, with dice or coins:

• The long term statistics and probability distributions are known, and not amenable to management intervention to change or challenge the outcomes.
• The only uncertainty is the outcome of the next throw; all other statistics are known.
• A long string of outcomes that don't appear random, like HTTTTT for a coin toss of heads or tails, does not suggest a bias

Second, none of the above applies to projects. In the project domain:

• The long term statistics and probability distributions of risk and uncertainty are NOT usually known, but if they were they ARE amenable to management intervention to change or challenge the outcomes
• The are many uncertainties that could affect the outcome of the risk event; almost all statistics are unknown.
• A long string of outcomes that don't appear random does suggest a bias

And so, is it pointless to study probability and statistics, or to get familiar with the concepts?  NO, NO! (And strong message follows)

Here's why you should know a few things:

• The Central Limit Theorem that predicts a central value among random outcomes can work for you to simplify estimating, and to validate estimates and observations
• Bayes Theorem is a powerful idea about using observations to improve predictions
• The Law of Large Numbers could save you a ton of money and time by showing you that it's not necessary to measure everything
• Expected value is a tool for avoiding many of the flaws of averages while also reducing a lot of data to something meaningful to carry forward to sponsors and non-quantitative managers
• Confidence limits give you some wiggle room to establish credibility but avoid the pitfall of a single point estimate that is almost always wrong.

I could go on, but you get the point. Study statistics! Keep learning stuff
And, if you want to follow-up, start with the videos at the Khan Academy, probably the best material around for the beginner.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile starts here

---

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

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

Agile projects are strategically stationary but tactically emergent

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

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

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

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

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

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

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

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

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

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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

---

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

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

---

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

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.

---

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