Crafting a value statement

---

Value, like quality, is elusive to define "they" say. In the eye of the beholder, etc.

Fair enough

What do we think of this manifesto (*)?

"The purpose of professional management is to serve clients, shareholders, workers and employees, as well as societies, to harmonize the different interests of stakeholders"

Certainly "professional management" includes professional project management. And, by extension the purpose (read: value) of projects is not different from the purpose of those who manage them.

Not so fast!

Some would rebut this thesis this way:

"Accountability to everyone means accountability to no one"

Perhaps.
But some many years ago this overall issue was worked pretty hard; the outcome was the "Balanced Scorecard" which recognized that the interests of all parties did indeed need to be harmonized and provided a framework for accomplishing same.

However, lest we forget, the PMO gets measured by some, but not by all. And, say what you will, the measurers will be satisfied by the measurees before anyone else.

And that -- the interests of the measurers -- at the end of the day, is the value statement of the project.

_______________

(*) Davos manifesto of 1973 for the World Economic Forum

---

Buy them at any online book retailer!

microknowledge vs micromanagement

---

Robert Gates, former U.S. Defense Secretary, wrote in his memoirs that a strong and effective leader in a big and complex organization needs to put the time and energy into acquiring "microknowledge" but refrain from "micromanagement".

An interesting thought, to be sure. Let the emphasis lie on "... put in the time and energy... "
But, this stuff is not free.
Didn't Malcolm Gladwell say: 10,000 hours to be an expert?
Well, microknowledge should not be 10,000 hours worth; indeed: most Defense secretaries don't even serve 10,000 hours.

So: "Microknowledge"? What's that?

• Think of it as the knowledge you would need if you were to micromanage -- thus, it's the knowledge you use to assert leverage, influence, and legitimacy over those you do lead.

Understanding vs direction
In other words, you need to understand the traffic while you resist the impulse to direct the traffic -- others can do that for you. (*)

• And, it's the knowledge you use to make decisions about delegation (this individual can likely to "this" but would not be good at "that"...) and assess performance.

But, of course, there's a dark side: microknowledge also what feeds the old saw: "he knows enough to be dangerous, but not enough to be effective" If this said about you, then you've crossed the line from legitimacy and leverage to nuisance and nemesis... Back off!

-------------
(*) Think of the scene from the movie "Patton" when the General himself is standing in an intersection of tangled tank traffic directing their movements... you probably don't want to do that, even though with microknowledge you might be successful

---

Buy them at any online book retailer!

The many flavors of scope creep

---

Can there be scope creep in Agile? 
Doesn't agile define creep away in a stroke: "Scope is whatever is prioritized in the backlog that fits within the budget (OPM, other people's money) and the time.

The backlog changes all the time, but that's not creep, it's just backlog management."

What I just wrote is a "best value" definition of scope. But, sometimes it doesn't sell.

I credit my agile students with these observations about "creep", to wit:

Project scope creep: it may be well and good that a true pure play on agile has no conception of scope creep, because the backlog is simply rebuilt as a zero-base-backlog (ZBB) after every iteration -- if not after each iteration, then certainly after every release.

Consequently, after every release, you should be able to stop and be satisfied you've delivered the best possible stack of high value objects. Amen!

Resource scope creep
On the other hand, if you can't get commitment for dedicated teams because the resources are needed elsewhere, then you are saddled with the overhead and inefficiency of rolling out and rolling in resources. This is resource scope creep -- spending more on resources' training, recruiting, and assimilation than the budget allows.

Clearly, this is a different flavor than project scope creep.

And, it's been around since forever!
Who's not heard of "resource plug-and-play"?
The plug-and-play process: just define a role, line up the role with appropriate resumes, pick one, plug him/her in, and you're off to the races!

• For more on plug-and-play, see the work of F.W. Taylor and "management science" wikipedia.org/wiki/F._W._Taylor

Agile to the rescue!
The fix is in: a pure play in agile means having fully dedicated teams that use the inevitable white space in the team schedule to improve the product -- more testing, more refined refactoring, working completely through the technical debt -- but not to get off the team and go elsewhere, only to return later.

Ooops!
The idea of giving up on matrix and other plug-'n-play resource schemes is pretty much opposed by managers not willing to give real agile a try.

Shifting from input to output
Again, it's an input/output focus tension... managing the white space by moving resources around is an input focus; leaving resources in place to use the white space for quality is an output focus.

Traditional schemes often put resource managers in charge of finding resources for the project manager. Obviously, those resource guys are going to focus on getting their job done according to their metrics.

Agile schemes are a bit different: once the resource manager has given up the resource to an agile team, it's the team leader who's responsible for getting good productivity and managing the white space on behalf of a best-value product

---

Buy them at any online book retailer!

Let them 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.

Local optimization
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!

Not so fast! Is virtual local?
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

---

Buy them at any online book retailer!

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.

Business and the PMBOK?
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, education is free!
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 finance-and-accounting person... I'll bet they'll explain the Chart of Accounts for your project quite readily

Let's banish business illiteracy!

---

Buy them at any online book retailer!

About choice

---

I've been working on a couple of projects with my wife.
From her I get this little item in a text:

I wasn't laughing... honestly!

---

Buy them at any online book retailer!

Approaching team burnout

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

Buy them at any online book retailer!