Activity - Methods - Outcomes

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

Buy them at any online book retailer!

Agile and the Enterprise

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the Enterprise!

And where does that money come from? If you're not the Federal Reserve Bank, you can't print your own money; if you're not a bit coin miner, you can't create coins.

So, the money comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise expectations

So, here's the thing: if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations .... starting with: value return on resources invested.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is required.

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience. Enterprises don't work that way.

There are rules

What makes an enterprise an enterprise is size and scale. And there is the rub: Sad to say, but size and scale is always more than a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. Such then brings rules, procedures, accountability, etc. into the frame.

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard three elements of the narrative you've heard before:

1. Scope: what is it you are going to do
2. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
3. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

You can't handle the narrative?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

Buy them at any online book retailer!

Numbers, numbers! Can't do without them

---

Numbers are a PM's best friend

Is this news?

I hope not; I wrote the book Quantitative Methods in Project Management some years ago. (Still a good seller)

So, here's a bit of information you can use:

Real numbers: (**)

• Useful for day-to-day project management
• 'Real numbers' are what you count with, measure with, budget with, and schedule with.You can do all manner of arithmetic with them, just as you learned in elementary school.
• Real numbers are continuous, meaning every number in between is also a real number
• Real numbers can be plotted on a line, and there is no limit to how long the line can extend, so a real number can be a decimal of infinite length
• Real numbers are both rational (a ratio of two numbers) or irrational (like 'pi', not a ratio of two numbers)

Random numbers

• Essential for risk management subject to random effects
• Not a number exactly, but a number probably
• Random numbers underlie all of probability and statistics, and thus are key to risk management
  
• Random numbers are not a point on a line -- like 2.0 -- but rather a range on a line like 'from 1.7 to 2.3'
• The 'distribution' of the random number describes the probability that the actual value is more likely 1.7 than 1.9, etc
• Mathematically, distributions are expressed in functional form, as for example the value of Y is a consequence of the value of X.
  
• Arithmetic can not be done with random numbers per se, but arithmetic can be done on the functions that represent random numbers. This is very complex business, and is usually best done by simulation rather than an a direct calculus on the distributions. 
• Monte Carlo tools have made random numbers practical in project management risk evaluations.

Rational numbers:

• A number that is a ratio of two numbers
• In project management, ratios are tricky: both the numerator and the denominator can move about, but if you are looking only at the ratio, like a percentage, you may not have visibility into what is actually moving.

 Irrational numbers

• A number that is not a ratio, and thus is likely to have an infinite number of digits, like 'pi'
• Mostly these show up in science and engineering, and so less likely in the project office
• Many 'constants' in mathematics are irrational .... they just are what they are
  

 Ordinal numbers

• A number that expresses position, like 1st or 2nd
• You can not do arithmetic with ordinal numbers: No one would try to add 1st and 2nd place to get 3rd place
• Ordinal numbers show up in risk management a lot. Instead of 'red' 'yellow' 'green' designations or ranks for risk ranking, often a ordinal rank like 1, 5, 10 are used to rank risks. BUT, such are really labels, where 1 = green etc. You can not do arithmetic on 1,5,10 labels no more than you can add red + green. At best 1, 5, 10 are ordinal; they are not continuous like real numbers, so arithmetic is disallowed.

Cardinal numbers and cardinality

• Cardinality refers to the number of units in a container. If a set, or box, or a team contains 10 units, it is said it's cardinality is 10. 
• Cardinal numbers are the integers (whole numbers) used to express cardinality
• In project management, you could think of a team with a cardinality of 5, meaning 5 full-time equivalents (whole number equivalent of members)
  

 

Exponents and exponential performance

• All real numbers have an exponent. If the exponent is '0', then the value is '1'. Example: 3exp0 = 1
• An exponent tells us how many times a number is multiplied by itself: 2exp3 means: 2x2x2 (*)
  
• In the project office, exponential growth is often encountered. Famously, the number of communication paths between N communicators (team members) is approximately Nexp2. Thus, as you add team members, you add communications exponentially such that some say: "adding team members actually detracts from productivity and throughput!"

 Vectors

• Got a graphics project? You may have vector graphics in your project solution
  
• Vectors are numbers with more than one constituent; in effect a vector is a set of numbers or parameters
  
• Example: [20mph, North] is a two-dimensional vector describing magnitude (speed) and direction
• In vector graphics, the 'vector' has the starting point and the ending point of an image component, like a line, curve, box, color, or even text. There are no pixels ... so the image can scale (enlarge) without the blurriness of pixels.
  

 ----------------------------

(*) It gets tricky, but exponents can be decimal, like 2.2. How do you multiply a number by itself 2.2 times? It can be done, but you have to use logarithms which work by adding exponents.

 

(**) This begs the question: are there 'un-real' numbers? Yes, there are, but mathematicians call them 'imaginary numbers'. When a number is imaginary, it is denoted with an 'i', as 5i. These are useful for handling vexing problems like the square root of a negative number, because iexp2 = -1; thus i = square root of -1. 

---

Buy them at any online book retailer!

Schedule management: who's in charge?

---

I mentioned the critical path and the most important path (they are different, sometimes) in a posting this week. Thus the question is begged: who makes all these decisions about resources assigned to the schedule, and who manages the buffers, and who manages the constraints (roadblocks)?

The buck stops with the PM, of course. 

Well, not exactly! Not all the time.
 

There's this problem: You've got a job to do; you've sequenced and scheduled it

But, in the middle of your critical path there is another independent project (or task) over which you have no control. In effect, your schedule has a break in its sequence over which you have no influence.

Yikes! 

This is all too common in construction projects where independent "trades" (meaning contractors with different skills, like electrical vs plumbing) are somehow sequenced by some "higher" authority.

So, what do you do?

If you have advance notice of this critical path situation, you should put both cost slack and schedule slack in your project plan, but there may be other things you can do.

 

Cost slack is largely a consequence of your choices of schedule risk management. 

Schedule risk management may have these possibilities:

• Establish a coordination scheme with the interfering project .... nothing like some actual communication to arrive at a solution
• Schedule slack in your schedule that can absorb schedule maladies from the interfering project
• Design a work-around that you can inexpensively implement to bridge over the break in your schedule 
• Actually break up your one project into two projects: one before and one after the interposing project. That way, you've got two independent critical paths: one for the 'before' project and one for the 'after' project

 At the end of the day: communicate; communicate; communicate!

---

Buy them at any online book retailer!

Supply chain scheduling

---

What can I say here that you've not heard before?

First: we are living in a time of scarcity, and so strategies for allocating scarcity come to the fore.

Second, demand for the scarce drives price -- no news there -- but demand itself may color supply and thereby schedule. Supply will not be directly correlated with price. Why? Because supply is what is going to be allocated, and price in dollars may not be currency. The currency of supply may take these forms: 

• allocation may bring loyalty into the mix; 
• may bring commitment to very long term relationships as the price of access
• may favor the cash deal over credit
• may require large up-front down payments that didn't exist before 
• may require quid pro quo: you have something I want; but I have something you want

Scheduling the scarce

So, now your job is to schedule in the context of such a landscape.

You begin with the normal risk tolerant scheduling techniques like those explained in "Critical Chain" theory:

• Be sure you understand that the 'most important schedule path' may not be -- technically -- the critical path. 'Most important' is where the critical value is as viewed by the customer or sponsor.
• Protect the 'most important' path by allocating what resources to that path first, and starving, if necessary, others
• Generously buffer around all the key milestones so that none are 'fragile' in the sense of bringing down the project if the nominal target date is missed

Architecture may help

Your architect can help you by designing-in all the anti-fragile strategies so that a missing part or resource, or a  sub-optimum substitute, is not fatal or cause a chaotic outcome. Your job is then to schedule these strategies into the master plan.

• Redundancy
• Negative feedback for stabilization
• 'Rip-stop' interfaces between subsystems, objects, and other elements

Your CFO may help

• Cash is king when demand exceeds supply
• Long-term contracts with favorable financial incentives may free up supply

Your take away:

Scheduling with scarcity is not just an exercise in time management. All the other disciplines can play a part.

---

Buy them at any online book retailer!

Just what we need: another reorganization!

---

"Whether in government or private business, office reorganizations are invariably touted as efficiency moves, when just as invariably—as anyone who has experienced one can attest—their short-term effects are redundancy and paralysis.

Naturally, the extent of these ill effects correlates to the amount of thought and planning—or lack"

Scott Anderson “The Quiet Americans".

What to do?

As a practical matter, PMO should reflect this experienced voice in project plans by planning for an initial dip in productivity, increased waste (likely increased cost) over the short term, and an extended schedule to allow this all to unfold.

To manage the risk, buffer all the critical tasks and milestones, and assume some less-than-expected performance in the short-term.

All this to give time for new relationships to form, new processes to be practiced and debugged, and for a steady-state to form and become apparent. 

And, of course, some stuff won't actually work; so some adjustment of the reorganization is to be expected, but perhaps only after a good shake-down period.

---

Buy them at any online book retailer!

Classified projects --

---

Most of my career has been working in the black and grey world of classified projects. 

If that is your domain, heed these words:

It is the nature of classified projects that "successes are unheralded and .... failures are trumpeted"

JFK

So, if you have an idea of putting your successes on your resume, looking for your next job, gig, or career move, beware!

 

---

Buy them at any online book retailer!