Remoting the physical job

---

Old news: Remote work on software and administrative tasks is routinely applied in projects.
New news: Remote work on physical jobs is, or will be, moving to projects from operations and production
Other news: Is this outsourcing by another name?

Assisted robotics

So, what we're talking about here is assisted robotics.

• In production, we've been flying airplanes, taking pictures, sniffing bombs, and assisting robotic fulfillment in warehouses for years ... very successfully (measured in human jobs displaced and quality of outcomes)
• Robotic-assisted medical procedures are more common place than they were

But in one-off projects, assisted robotics has been a costly thing

But, it's coming!

• Designing building a new antenna for spacecraft? Need to work in a 'clean room'? I can operate a lot of the machine tools and assembly tools from home, or least from a remote project office, and I don't have to put on a 'clean suit' to work on the antenna!
• Building cable bundles and other physical assemblies: do it with human-assisted robotics. Did I mention: no errors, ever! And perfect solder joints.
  
• Working on bio-tech, or chem-tech? Hazardous? Bring on the assisted robotics!

There's a pattern here:

• Multiple robots do most of the work
• Humans intervene to stop and start the work, and to trouble-shoot when the robot gets stuck

Computing the RoI

• There's capital investment (CapEx) in the robotic machinery (Hopefully, you can make business of designing and building one-off space craft antennas)
• There's overhead expense to train the workforce to be a robot's assistant
• And there's project direct expense to add project-specific instructions to the robot's operating system
• And don't forget that although robots can work 24/7, without fatigue and frustration, the human handlers do need time off or shift rotation
• But overall there's less labor input and higher quality output (less rework, etc) that drive the 'return'

Outsourcing by different means

Did I just say that humans are to train robots to take their jobs away?

Ooops! That may not be the right message

Is this just a different outsourcing problem?

---

Buy them at any online book retailer!

When A comes before B

---

When A comes before B

If you understand the nature of A and that of B, and if starting B depends on A, then getting A done before B sounds easy, but sometimes it makes you wonder!

• Is there a preamble to B that should be done before A is completed?
• Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  
• Can B really start after A, or are there other dependencies on the start of B?
  
• Do I really want B to start, or do I want to pause and start C somewhere else? 
• If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
  

And, there's this:

Schedule depends on sequence
So, if you're thinking about sequencing, you're probably also thinking about schedule: if I plan for "this sequence", how long is it going to take?

Or, the other way around: if you are working on a schedule, you have to get the sequence down first.

Scope is what you sequence, but ...

It seems obvious, but it's worth saying: you have to know what you are going to do. To wit: you can't sequence that which you don't know about. 

And furthermore, even then there may be sequencing errors that you discover once you understand the full extent of the scope. Leave some slack for the unknown!

BUT ... Sequencing value-add to the business may be the ultimate sequence determination. Taking care of the business may be your job-one. If you can, choose sequence in favor of the business!

Scheduling tools

Scheduling tools, like the ubiquitous MSProject, are a good planning tools for sequencing. You can work in the Gantt-chart mode and sketch out the big picture pretty rapidly, setting up key milestones as schedule goals. You need not use the precedence mode at all.

However, there is a bridge too far: 

If  you plan in too much detail, many of these tools are way too tedious to use for maintenance of the schedule once the project is under way. 

 

As a practical matter there will be "micro-dependencies" that crop up, which are worked in real time; micro-loops for feedback and checking results against the evolving construction baseline, etc. that are way too expensive to schedule, status, and maintain as they change.

Milestone focus

My advice: at the PMO level focus on the major sequences that drive toward value-add milestones.

---

Buy them at any online book retailer!

Balancing project sponsor and project manager conflicts

---

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, the business and the project; but also what's mine -- the project stuff -- and what's yours -- the business stuff. Mine and yours!

First, the left side
On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized, and it need not be all tangible. Sometimes 'good will' -- the accountant's name for the intangible gut feeling that this thing is worth more than book value (market-valued assets) -- counts for a lot. (Think: sponsor commitment, even when the going gets tough)
'Yours' simply means it's resources and commitments owned and given by others to the project. It's the 'your's side of the balance sheet that's somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners).

Then, the right side
On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets of the enterprise). The right side is the project side:

• Estimates and evaluations of the project manager
• Uses for the investment and resources to be entrusted to the project manage -- in effect deliverables and other artifacts, and perhaps some intangibles as well*

All about facts
 And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.

And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

The gap
Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

 In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

Oops! the PM is the ultimate risk manager.

In a real world example, I had this situation:

• We bid a job competitively in a firm fixed price environment. 
• We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
• We won! 
• And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

---

* Yes, indeed! Projects produce intangibles, even good will, but it makes for an accounting of project value all the less objective.

---

Buy them at any online book retailer!

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!