Is AI eating the software world? An essay

---

Daniel Miessler has posted a provocative essay with the attention-grabbing headline: "How AI is Eating the Software World". (*) He subtitles his essay this way:

The future of software is asking smart questions to a mesh of APIs running layered models

Meissler posits three architectures:

1. "Outcomes" which is pretty much conventional software design: Inputs, controls, task or process, and outcomes.
2. "Understanding" which he thinks is the not-too-distant world of generative AI. A progressing stack of data (unorganized and unevaluated), information (organized data), knowledge (integrated information), and understanding (all before applied in context with situational awareness)
3. "SPA" which he has coined for "state" (present situation, but multi-dimensional), "policy" (... "which is your desired state and the set of things you want and don’t want to happen"), and "action" (..."which is the recommendations or actions that can be performed to bring the STATE in line with the POLICY.")

Eventually, the software that runs a project or a business will be defined by a number of APIs that address various layers of multi-dimensional sources of "understanding" but work in a SPA kind of architecture. 

Need something new in the SPA? Define an API, or buy it from someone else. 

Need to offer something to a customer? Give them access to an API that pulls from your company's value-add stack of "understanding". 

Now Miessler readily admits that the current generation of generative AI tools are not ready for business or project prime time because what you get is not predictable or necessarily repeatable (if you run a generative AI query 10 times you are likely to get 10 different answers. That's a no-no for most business or project processes)

Like I said, a provocative essay.

__________________

(*) An essay from 2011 by Marc Andreessen, with a similar title, is this one: "Why Software is Eating the World"

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Remote workers cyber security

---

Is part of your team working from home, or from a remote location?

Here's some common sense guidance from NSA on how to up your game re cyber security from those locations. 

The usual stuff is there, starting with keeping all your mobile and fixed OS's up to date with the latest security patches, but then going on about password security and admin privledges.

Of course, there is everyone's favorite: Don't open links from unknown sources, but I would add: Don't open links you would not expect from a known source. Instead, text the sender to find out if the sender actually sent you the link.

One that you don't see very often caught my eye:

"Schedule frequent device reboots

To minimize the threat of non-persistent malicious code on your personally owned

device, reboot the device periodically. 

Malicious implants have been reported to infect

home routers without persistence. 

At a minimum, you should schedule weekly reboots

of your routing device, smartphones, and computers. Regular reboots help to remove

implants and ensure security. 

For more guidance on better protecting your smartphone,

refer to the “Mobile Device Best Practices” CSI."

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Looking at resumes for your project?

---

Working on your project staffing plan?

Looking at resumes for positions to fill?

That may be "old school"

How so?

Psycho drama

More and more, PMOs are realizing that there's a psychological divide among those suited to remote work and those suited for in-house work. For some, remote work is 'lonely' and for others it's inspiring. And for many others, the story is just the opposite; they need the community of office or in-the-field work.(*)

Resumes can't really capture all that stuff; it's no secret that resumes don't tell the whole story, and indeed may be misleading regarding a good fit to the position. And now, with a chat bot on every laptop, a written resume may be unoriginal, if not outright fake.

New graduates
Many 'new grads' have little beyond college to put on a resume, but there are indicators to look for:

• Average grades, or better shows some prioritization for conventional classwork
• Sports participation may indicate aggressiveness or competitive spirits
• Incubator participation may indicate an entrepreneurial bent
• Work in order to pay for school shows grit and determination (not the easy road, I can assure you from personal experience)

No resume at all?

Now, however, there is a trend to 'no resume at all', or at most a big discount applied to the value of a resume. How is the PMO supposed to work in such an environment?

Some of the answers are in this framework, which should filter out the AI fakes and avatars:

• Personal interviews that tease out not only relevant experience (in effect, an oral resume), but also tease out ideas for innovation, attitudes towards teams and bureaucracy, and preferences for work environment.
• Psychological profiles, starting with the venerable 1940's invention: Myers-Briggs (**), but now there are literally hundreds of profile apps to choose from. 
• Work samples, prototypes, and answers to quizzes or puzzles.
  In the recruiting for the WWII Bletchley Park decryption team, applicants ---- whether lawyer, baker, mathematician, or candlestick maker --- were asked to solve a puzzle in a matter of a few minutes. If you were good a puzzles, you got the job, regardless of resume!

Resume - Psycho standoff

What do you do if you have a good resume candidate with a questionable psycho profile, and another candidate just the opposite: one who really fits the job profile, but for some weakness in their resume?

One PMO went about it this way in a risk management approach:

• What's the cost of making a mistake and choosing wrong, as would be proven over time?
• What's the cost of hiring both and letting the round pegs naturally find the round holes?
• What's the expected value of each choice? 
• Choose according to the best value obtainable for the organization, usually the highest expected value

How about the college degree?

Only about 1/3rd of adults in the U.S. have a college degree. Shortages of applicants has led many hiring officials to reevaluate the the college degree as an entry credential to a job offer. There is a trend in the direction of allowing work experience and track record speak to individual capabilities.

Of course, in the sciences, engineering, physics, mathematics, and statistics, etc., you could be self-taught, but most companies are not there yet, and don't have the requisite means for evaluation of self-taught in lieu of work experience. 

And, there may be licensing issues as well as certification required for accreditation or insurance purposes. But, some of that may be changing.

Office automation

And finally, maybe you hire an avatar and not a person at all. This choice may be getting there faster than you think.

+++++++++++++++++

(*) And those factors are not the only thing: there is the culture divide between remote and office; team dynamics which are quite different from one to the other; and significant differences in the vectors of career paths for the remoters vs the office types. 

(**) Did you know they are a mother-daughter team?

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

A new project role: Prompt Engineer

---

I've mentioned this idea before: a new role coming to projects is that of "prompt engineer".

And so what is the job description?

• Able to write imaginative queries (prompts) in natural language for an AI engine
• Able to understand their flaws, supercharge their strengths and game out complex strategies to turn simple inputs into results that are truly unique (according to one published description)
• Able to work with other humans to refine their queries
• Able to validate responses from the AI engine
• Able to experiment, almost without limit, to discover and refine

Here's the rub: 

Whereas computers execute software code precisely and with consistent repeatability, that's not what you get when you query today's chat engines built on "large language models"(*). In my personal experience, the exact same query, executed multiple times, gets you somewhat different answers every time.

Simon Willison, a British programmer who has studied prompt engineering, is quoted in the Washington Post as saying: “I’ve been a software engineer for 20 years, and it’s always been the same: You write code, and the computer does exactly what you tell it to do. With prompting, you get none of that. The people who built the language models can’t even tell you what it’s going to do.”

And, "prompt injection" may be a prompt engineer's tool to tease out performance, or it's a malicious hacking tool aimed at the AI engine. 

Wikipedia says this: "Prompt injection can be viewed as a code injection attack using adversarial prompt engineering. In 2022, the NCC Group has characterized prompt injection as a new class of vulnerability of AI/ML systems also."

Then there are the art and image creators, built somewhat differently than the large language models.

Prompts with these image engines don't have to be the formal language constructs of the large language models. And indeed, sometimes just a grab-bag of words will get you amazing images. 

The prompt engineer morphs into the prompt artist.

For the prompt artist, there is a business there: Some artists will sell you proprietary prompts for favorite images.

Beyond the normal domain

The Washington Post reports: The role is also finding a new niche in companies beyond the tech industry. Boston Children’s Hospital this month started hiring for an “AI prompt engineer” to help write scripts for analyzing health-care data from research studies and clinical practice. 

The law firm Mishcon de Reya is hiring for a “legal prompt engineer” in London to design prompts that could inform its legal work; applicants are asked to submit screenshots of their dialogue with ChatGPT.

______________________

(*) Large language models: A language model is a probability distribution over sequences of words. Given any sequence of words of length m, a language model assigns a probability to the whole sequence. More simply, a language model predicts the next word, or the next sentence even, from the probability that such as been seen before in the training data. A "large language model" is one that uses a very large data set for training. And the definition of "large" is getting larger with time and experience. 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

New: Risk Management framework for AI

---

The U.S. NIST has issued, after long discussion and drafts reviewed, their risk management framework (RMF) for A.I. You can read it here.

NIST says:

 The AI RMF refers to an AI system as an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions influencing real or virtual environments. AI systems are designed to operate with varying levels of autonomy (Adapted from: OECD Recommendation on AI:2019; ISO/IEC 22989:2022). 

Not everything is new cloth; a lot has been drawn from ISO risk management standards, as well as other Agency risk management guides.

Other opinions

If you want a good overview of A.I. risks as seen by an expert pseudo skeptic, then read Gary Marcus.(*)  He, with co-authors, have written multiple papers and a well respected book entitled: 

"Rebooting AI: Building Artificial Intelligence We Can Trust"

Not surprisingly, Marcus sees great risk in the acceptance of the outcomes of neural-net models that interrogate very large data sets, because, as he says, without context connectivity to symbolic A.I models (the kind you get with symbol algorithms, like that in algebra), there are few ways (as yet) to validate "truth". 

He says the risk of systems like those recently introduced by OpenAI and others is that with these tools the cost of producing nonsense will be driven to nearly zero, making it easy to swamp the internet and social networks with falsehoods for both economic and political gain.

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

(*) Or, start with a podcast or transcript of Marcus' interview with podcaster Ezra Klein which can be found wherever you get your podcasts, or on the New York Times website.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

New job skill: be able to talk to AI

---

Charlie Warzel has posed an interesting thought in an essay about the sundry impacts that may come about with ever more sophisticated AI tools in the workplace:

Talking to AI may be the most important job skill of this century

For the moment, it's about writing or constructing a 'prompt'

Warzel makes this point: "AI evangelists will similarly tell you that generative AI is destined to become the overlay for not only search engines, but also creative work, busywork, memo writing, research, homework, sketching, outlining, storyboarding, and teaching. .... 

If this AI paradigm shift arrives, one vital skill of the 21st century could be effectively talking to machines. And for now, that process involves writing—or, in tech vernacular, engineering—prompts."

New job title
Now you too can become a "prompt engineer"
You don't need math; you don't need computer science. You just need command of natural language.
Wait! Is "prompt engineer" in the resource catalog for your project?

Prompt is the new word to know
And so, let's get familiar with the idea of a "prompt":

• It's your guidance to the AI tool or machine
• It can be quite specific, directive, and structural complex, unlike the simplistic prompts you put in a search engine query window.
• It can also be just a list of words that are 'parameters' for the desired outcome
• It's in natural language, not a software language

As an example, Warzel offers this "prompt" for prompting something like ChatGPT

“Write a five-paragraph book report at a college level with elegant prose that draws on the history of the satirical allegorical novel Animal Farm. Reference Orwell’s ‘Why I Write’ while explaining the author’s stylistic choices in the novel.”(**)

More is better, or at least different

What I've noticed in my use of ChatGPT is that if you run the same prompt multiple times, you often get back different results. I've found that my value-add is to merge the beset ideas from the multiple outputs.

Make or buy?
You don't need to do this stuff yourself. There are now companies selling from on-line sites ready made prompts. And why not? Where there is a need, capitalism moves in!

____________________

(**) I actually did put that 'prompt' into ChatGPT, and I got back -- in a few seconds -- five paragraphs that seem to answer the requirement, though I don't have the background to validate accuracy. 

Such validation is one of the unresolved hazards of such AI chat engines.

 

I did, however, use ChatGPT to write a posting about which I do have the background to validate the answer.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Create Sloppy schedules -- on purpose

---

Be a sloppy scheduler.

Really?

Yes, do that.

Why?

Because sloppy schedules are schedules that are naturally risk averse; they have risk mitigation built in. With slop here and there, things can move around, expand, contract, and react to unforeseen dependencies.

And so what is sloppy?

Sloppy schedules are those with a lot of buffer between the important events (buffer means unscheduled time boxes, and/or deliberate slack built into durations)

You can be sloppy with milestone schedules, or its close cousin "black box schedules".(*) But you can also be sloppy with traditional task oriented network schedules (like the very old PERT method or its close cousin PDM, as supported in MSProject and other similar tools)

Advantages

Consequently, with risk aversion built in, sloppy schedules are more predictable and more strategically stable than tight schedules with do-or-die milestones. You can 'prove' this to yourself by building a histogram of possible schedule outcomes with a randomized simulation. On a small scale, the statistical formulas in Excel are good tools for building a a convincing demo. 

Disadvantage

The biggie, of course, is that your business imperative which is the underlying driver for your project may require a shorter schedule than that obtainable with a sloppy schedule. 

If so, move on to the discussion below about tools.

Tools you have

So, for this dilemma, you have a few tools to work with:

• Reorganize the work, or the work flow, to obtain a shorter timeline. I've written about this technique before.
• Step up the training, tools, and methods for better productivity
• Shift work to other organizations that can work in parallel, thereby shortening serialized work
• Avoid the trap of focusing on the "critical path" rather than the "most important" path. I've written about the trap as well. The latter may be a lot shorter than the former, with little loss of business value.
  
  

______________

(*) Blackbox schedules are those with elements of work encapsulated in black boxes (internal detail unknown or not visible) and then the black boxes strung together in some type of network.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Who needs a bureaucracy?

---

Who needs bureaucracy?

You might, if some of these situations are yours:

• If you don't know your people well enough to trust them
• And, you don't have time or opportunity to get to know them
• And there are consequences beyond just undoing a bad decision they might make, .....

Then the management solution is simplicity itself:

Invent a bureaucracy and assign them to it!

Bureaucracy is the management alternative to person-to-person trust. And, it's the go-to system for rules and boundaries. 

• Rules, regulations, protocols, and cultural doctrine do a lot of the work. No trust required; no fuss, no muss!
• Sometimes, incentives are useful, so don't leave them out.
• If it comes to it, HR probably has some bureaucratic rules for discipline

Now admittedly, bureaucracy cuts against the flat, agile grain which is "the way to do it" for modern managers. 

But, beyond a point, flat is too flat, and agile is too agile.

Let's be realistic:

• Many can not handle complete freedom, 
• Have questionable judgement, 
• Are misaligned to strategic goals and imperatives, and 
• Generally spend time and money without regard to the fact that neither the time nor the money is theirs.

Bring on the bureaucrats!

If you do, you might gain some of these acknowledged advantages:

• Generally efficient with large scale tasks because of predictable work flow and stable organization, buit-in personnel development, and committed capital resources.
• Predictable performance, because the 'way things are done' is very repeatable with central clustering of performance metrics.
• Generally neutral when the workforce is large, reflecting the corporate culture rather than individuals. Thus, diversity is very narrow centered on the corporate culture
• Accountability and durability is usually built-in with rule, protocols, and doctrine that are hard to budge

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

If you had it, could you spend it in a month?

---

Here's the challenge: On your project, if you had it in hand could you spend $1M in a month?

Take a minute and think about it.

Actually, take a minute and estimate the possibilities.

Does money solve all the problems?

Consider::

If it's just a workforce issue (marching army costs), then:

• If you've got 100 people with an annual payroll of $15-20M, then yes, it's possible, even likely
• If you've got 20 people with an annual payroll of $3-5M, then maybe, with overtime and some material charges.

But, if you need new physics, then money, even if you have it, may not be spendable.

So, can you spend it, or not?

Got your answer?

Good!

Then here's another challenge: If you can spend $1M in a month, can you do a $1M project in a month? Are they one and the same thing?

Probably not.

Consider:

• It's hard to get a crowd of people up and moving coherently to start and finish something in a month (that $1M may disappear into "start-up" inefficiencies)
• It's not too hard to get 20 people moving, but you might have to really work on motivation if you think you're going to spend $1M on people, but there may be tools, training, facilities, etc that will absorb funds.

So, having thought about it, maybe if you really need your 100-person team, 2 months and $2M is a better thing to have;

And, if you only need your 20-person team, even with overtime, you will be hard pressed to spend as much as $1M

What does all this mean?

To know whether you can spend $1M in a month, you've got to make some estimates (gasp! that dreaded word), if only on the back of the nearest envelope.

Perhaps a bit crude and rude, but at least the 'breadbox' is somewhat defined

But we do it all the time; most of us are decent estimators for those events and activities for which we have experience. Never let it be said that  we are not making estimates nearly every minute of the day:

• How long to get to the computer (home or office)
• How long for that meeting
• How much time to spend on email
• How much to spend on a car, hotel, or even a cruise
• On, and on, estimating!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Make it a 'turn-key'

---

You may say -- you may have heard -- "make a 'turn-key' project".

Fair enough.

What does that mean? 

Actually, there are a few things built into that expression:

• You're throwing off risk by pushing scope and cost to someone else, presumably with a proven track record of expertise and performance.
• You probably mean 'fixed price' for a 'fixed scope' of work. There's no 'bring me a rock' uncertainty; you know exactly what rock you want, and 'they' understand and commit to deliver it.
  
  
• "Call me when its done". You expect them to handle their work like a black box; the internal details are unknown to you, or even if not, you've given up all executive supervision.
• They carry the insurance. Liability, property damage, workman's compensation, OSHA penalties, and the like are all on them. Of course, there's no free lunch, so the cost of those insurance plans are built into the price you pay for the 'turn-key'.
  
  
• Cash flow is largely their problem, though you make be asked for a down payment, and you may be asked for progress (aka, earned value) payments. As cash flow is their problem, so is credit with lower tier suppliers, financiers, and the like.
• Capital investment for special tools and facilities, and expense for special training (and these day, recruitment and retention) are all on them. These financial details will come back to you, proportionately, as part of their overhead figured into their fixed price for the job.
  
  

That all sounds swell as a way to offload issues onto others. But, at the end of the day, you as PM for the overall project still are accountable to your project sponsors. No relief on that score!

Here are a few of the risks to you should be aware of:

• Contractors have biased interests also. The contractor may prioritize some part of the project to serve their interests more so than yours. So, don't be blind to that possibility
• Fixed price is not always a fixed price. Any small change in scope or schedule can be leveraged to the advantage of the contractor for them to 'get well' from a poorly estimated base contract.
  
  
• Scarcity provides leverage: If they've got it and you need it, and there is a scarcity of supply, your contractor is at an advantage. 
• Cash talks: Cost of capital is often no small matter to a contractor. The cash customer is always favored; the customer with a short invoice-to-payment cycle is favored. When you need a contractor for a turn-key, cash talks.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

"Rules for Metrics"

---

"Management 3.0" has a blurb they call "12 Rules for Metrics"

There are a few of these I find unique and interesting, repeated here, more or less:

• "Measure for a purpose": Without using those words exactly, I have written on this topic many times. Don't ask for metrics and measurements unless you have a plan for using the data productively to advance the project
  
  
• "Shrink the unknown": This is a play on you 'can't measure everything'. Their advice: find peripheral metrics that add up to a better knowledge of that which is not directly measurable.
  
  
• "Set imprecise targets": A modern version of advice developed in post-World War II quality movements of the day, this idea is that precise targets become the tactical objective to the detriment of progress on the strategic purpose of the project.
  
  Editorial: innovation may be stifled if there is too much focus on the nearby tactical objective, to wit: be agile!
  
  
• "Don't connect metrics to rewards": Another piece of advice from the distant past which opines that rewards should be directed toward strategic outcomes.
  
  Anecdote: when incentives were placed on finding errors in code, then what occasionally happened is that coding was more near-term sloppy, knowing that putting the quality in last would be financially rewarding.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

ChatGPT on the risk matrix

---

I asked ChatGPT for an assessment of the limitations and hazards of using the conventional risk matrix -- of impact vs probability in a matrix format -- in project management.

In a 'not too bad' response, ChatGPT responded this way (unedited, except for text formatting):

The risk matrix is a commonly used tool in project risk management, but it has several potential limitations, including:

1.     Over-simplification: A risk matrix can reduce complex risk factors into simple numeric values and colors, which can lead to oversimplification of the actual risk.

2.     Lack of consistency: Different people or organizations may use different criteria to assign numeric values to risks, leading to inconsistencies in risk assessment.

3.     False sense of precision: The use of numbers and colors in a risk matrix can give a false sense of precision and accuracy, even though the underlying risk assessment may be subjective and based on limited information.

4.     Lack of context: The risk matrix does not provide enough context or information about the risks being assessed, making it difficult to understand the underlying causes and potential impacts of risks.

5.     Limited scope: The risk matrix only considers risks that have been identified and may not take into account unknown or emerging risks.

6.     Over-reliance: Risk matrices are often used as the sole tool for risk assessment and management, leading to oversimplification of complex risks.

7.     Limited detail: Risk matrices provide limited information about individual risks and often do not include mitigation strategies.

8.     Qualitative vs Quantitative: The use of qualitative information to assign risk scores in a matrix can lead to subjective interpretations and inconsistencies between users.

9.     Inflexibility: Risk matrices are static, making it difficult to reflect changes in risk as a project progresses.

10.  False sense of security: The use of color-coding and other visual aids can create a false sense of security about the level of risk present in a project.

11.  Lack of integration: Risk matrices are often used in isolation, without being integrated into the overall risk management process.

12.  Culture and politics: The way risks are perceived and prioritized can be influenced by organizational culture and political considerations.

Not mentioned: Random number arithmetic. 

To that fairly complete list I would add that if the impact and probabilities are given numerically, regardless of their calibration or built-in biases, the numbers should be understood to be 'random numbers' drawn from (usually unknown) statistical distributions. 

'Random numbers' ordinary arithmetic between them is invalid. Only statistical processing of their distributions is technically possible. And that is often a 'bridge too far'.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Delivering value (a question of utility)

---

Presumably, at the outset of the project, either in the chartering process or some budget process, "they" have made the equation between project cost and value to the enterprise. 

And so, a bargain is struck: For the money (and other resource commitments), there are to be deliverables commensurate with that investment. That's the value proposition, at least at the outset.

Fair enough.

Actually, when you think about it, at some level this bargain can be modeled as a 'black box':

• There are inputs in the form of invested resources and raw materials
• There are (or should be) mechanisms for control and inspection from outside the 'box'
• The outputs are defined or specified
• The 'transfer function' from input to output has (or should have) a time dimension, aka schedule.
• For outsiders, there is no certain knowledge about how it all works inside, but somehow it does.

And off we go!

But then comes the more vexing part:

• At the outset, the utility of the first dollars spent is likely very high. You spend and the project gets started; inertia is overcome; innovation occurs; morale is usually high; and there's time to course correct around obstacles
  
  In other words, the marginal value of the early dollars is likely very high, perhaps greater than par. In spite of setup or startup costs, you get a lot out for every additional dollar in. Utility bends the resources to the advantage of the project.
  
  
• Near the end, the utility of resources bends the other way. The marginal value of one more dollar spent in pursuit of a deliverable is likely less than par. The money goes into fixing quality issues (rework or rejected outcomes); paying off risk premiums, bonuses, or penalties; tidying up the documentation; and paying for the transfer to production or operations.

But arguments may begin:

• Should we really spend that last low-utility dollar? Is it needed more on 'the bottom line'?
• What's the opportunity cost of the last dollar?
• Are there alternatives of lower cost which could be applied to end the project (smooth landing)?  

There are no prescriptive answers

The arguments are all context sensitive

The point is: situational awareness. These debates are coming to a project near you.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Rookie mistakes in Risk Management

---

First comes the planning

You've followed all the standard protocols for setting up your risk management program.

You've put slack in your cost estimates, and you've put slack-buffers in your schedule plan.

All good.

Risks have been listed, prioritized, and the minor ones to be 'unmanaged' set aside (minimize distractions)

Otherwise, mitigation planning has been done.

All good.

Now comes execution

There are a lot of ways to screw up risk management. No news there, but ,,,,,

Rookies sometimes do these things, but, of course, you won't:

• Rookies ask for, or accept, single-point estimates from team leaders, work package managers, or analysts. This is a big mistake!
  
  Estimates should be given as a range of possibilities. No one works with single-point precision, and no one works without control limits, even in tried-and-true production regimes.
  
  And you should recognize that 'far-future' estimates are almost always biased optimistically, whereas near-term estimates tend to be neutral or pessimistic.
  
  Why so? First, "the future will take care of itself; there is always time to get out of trouble". And second, near-term, "we have all the information and "this" is what is going to happen; there is little time to correct matters".
  
  
• Rookies sometimes consume the slack before it's time. What happens is that rookies fall into the trap of "latest start execution" when it comes to schedule; and, in cost management, rookies often put tight controls on last rather than first, or early on. Then, when they need slack, it's already been consumed. Oh crap
  
  Experience and wisdom always argue for using slack last, hopefully not worse than 'just in time'

• Rookies fall for the "1%" doctrine. In the so-called "1% doctrine", a very remote but very high impact event or outcome has to be considered as a 'near certainty' because of this risk matrix math: "very very small X very very large = approximately "l" (*).  Or, said another way: "zero X infinity = unity (or 1 or 100%)". 
  
  Accepting that doctrine leads rookies to spend enormously to prevent the apocalypse event. But actually, 'nearly 0' is a better approximation than 'nearly unity' (in arithmetic, 0 times any finite number is 0)
  
  What about the 'infinity' argument? Well, actually 'zero x infinity' is at best matter of 'limit theory' for one thing. And that's not easy stuff. But actually, anything times infinity is 'indeterminate' and thus not a workable result for the PMO. (**)
  
  Put the math aside. Isn't this about risk-managing a 'black swan' event you can actually imagine? Perhaps, but that doesn't change the conclusion that 'nearly 0' is the best value approximation.

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

(*) In probability statements, "1" is understood to be all possibilities, or a confidence of 100%

(**) But more specifically, general laws of mathematics are not applicable to equations with infinity. It's commonly understood that if you multiply any number with 0, you get 0, but if you multiply "infinity" with 0, you get an indeterminate form, because infinity itself is not determined yet. Our science currently has 7 indeterminate forms; infinity is one of them. 

Of course, the good news is that we've advanced beyond the ancient Romans who have no Roman numeral for zero. It was not considered a number by them.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Managing schedule: who's in charge?

---

I written this before: "The critical path (CP) and the most important path (MIP) are different more often than you might think."

• We all know the definition of the CP: the longest path from project inception to project ending. 
• The MIP is the path, long or short, to the most significant value-producing project outcome. This might be the actual project ending, but more often it is not. Sometimes a small item, required but not critical to success hangs out as the CP. 

Two protocols

The standard protocol for resourcing a project is to provide the CP with all the resources necessary -- and in the right sequence -- in order to prevent a slip-to-the-right of the end milestone. In this wisdom, all other requirements are subordinate to the needs of the CP.

But a protocol centered on value-production would not necessarily fall in line with subordination to the CP. Indeed, the 'value managers' will argue that their needs are superior and primary. (*)

Management needed here

Thus the question is begged: who makes all these decisions about resources assigned to the schedule, and whether or not the schedule is to be managed with CP or MIP protocols?

And, who manages the buffers, and who manages the constraints (roadblocks)?

 

The 'standard answer': The buck stops with the PM, of course. 

Well, not exactly! Not all the time.

The user group, the sponsor, the business team all have a influence on the MIP vs the CP choice.

Influence: yes, but that's strategy thinking. Tactically, and ultimately, the PM is the decider.
 

Confound it!

So you've got your strategy: MIP or CP; and you've got your tactics about buffers and sequence. But, sometimes there is a confounding factor (**), described this way: 

You've got a job to do; the protocol decision has been made. From that point, you've sequenced and scheduled it, taking into account the resources made available to you.

But, in the middle of your schedule 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 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!

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

(*) I wrote a couple of books on this topic: Managing Projects for Value

(**) An influence that is in the background of two or more plans or events that correlates or connects between them

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Leadership by link and buffer

---

"Link and Buffer" is a leadership concept for a leader positioned between a governing board, to whom they must link the project, and a project team which must be buffered from the whims and biases of the board.

Fair enough

But it's not that easy.

In the "link and buffer" space live various skills:

• Vision and practicality: to the board, the project leader talks strategically about outcomes and risks; and about the strategic direction of the project. But, to the team, the leader talks practically about getting on with business. All the tactical moves are effectively smoothed and buffered into a strategic concept which the board can grasp
  
  
• Tempers and angst: When there's trouble, tempers fly. Buffering is a way to decouple. The board's angst does not directly impinge on the project if properly decoupled by the project leader.
  
  
• Personality translation: Few on the project team will know or understand intimately the personalities on the board. Taking the personality out of the direction and recasting instructions into a formula and format familiar to the project team is part and parcel of the buffering.
  
  
• Culture translation: In a global setting, the board may be culturally removed or distant from the project team. Who can work in both cultures? That of the board, and that of the project team? This is not only a linkage task but a translation task to ensure sensitivities are not trampled.

Examples of "link and buffer" abound in military history. Perhaps the relationship between Admiral Ernest King and Admiral Chester Nimitz is most telling. King was in Washington during WW II and was Nimitz superior in the Navy chain of command. Nimitz was in command of the Pacific Ocean Area from his HQ in Hawaii.  

 

King was responsible for a two ocean Navy in a world war; Nimitz more limited. Nimitz was the link and buffer from the tactical fighting admirals at sea, and the strategic war leaders in Washington.  No small matter!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

When mystery is actually progress

---

Got a mystery in your project?

Can't figure out what's happening, or

Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!

Stuff happens; don't deny; it's yours to figure out why

Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:

• There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
• There are missing particles in the Standard Model of particle physics; where are they?
• Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
• Why does your bridge collapse after you built it with a lot of steel?
• Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)

 So, there are a lot of examples. What do you do about it?

• Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....
  
  
• Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')
  
  
• Get out of the frame and look from a different vantage point. That's what Einstein did.
  
  
• Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.
  
  
• Change direction and do something entirely different (not retreat; just advance in a different direction)
  

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Why do they call it a 'black box'?

---

Why do they call it a black box? Maybe it should be just opaque. Either way, it's a system engineering idea:

• Encapsulate a function, 
• Make it opaque and invisible to outsiders
• Feed it inputs and external controls, biases, and offsets (in other words, the 'interfaces')
• Look for and utilize the prescribed outcomes
• Voila! You've got a 'black box'!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box interfaces with your project or system? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The Four Maths of the PMO

---

Math may not be your favorite thing in the PMO, but hear me out.

There are four 'systems' of math you are probably using without thinking too much about them.

So, if that's so, why think about them now?

• Somebody may use the terminology around you, so informed is better than ignorant
• Communicating with your administrator, analyst, or systems person may be more informed
• You may want to learn more about one or the other, so a look-up of terms is handy

Here's a quick read on the four:

1. Arithmetic and linear algebra: Arithmetic is the add-subtract-multiply-divide thing you have been doing all you life; linear algebra is just using arithmetic in a systematic and rules-based way -- in other words, formulas -- to find some values you might not have but need  (that conveniently lie along straight lines (thus, 'linear')
   
   This is really useful stuff for adding up costs, figuring out schedules durations, and solving for resource unknowns, not to mention (gasp!) working forecast with earned value formulas
   
   
2. Exponentials: See my post on this topic. Exponentials form the world of non-linearity (no straight line). Exponentials are seen in the project office explaining  the non-linear "utility" of the project's value proposition, escalations in communications complexity, discounts for future risks, discounted cash flow (DCF) methods, and other useful stuff
   
   
3. Statistics: Statistics, and its close cousin 'probability', let us deal with uncertainty in project affairs. In this domain, we find 'random numbers': that is, numbers that are a bit uncertain because of incomplete knowledge or because of random effects (for which more knowledge doesn't help).
   
   We can't do arithmetic directly on 'random numbers' because we don't have certain knowledge of what to add or subtract from one random effect to the next. Thus, simulations of statistical effects are the best way to handle such requirements. The 'Monte Carlo' simulation that is built-in to many scheduling apps and some cost and finance apps is an example of handling statistical effects on schedule numbers with simulation.
   
   Keep this idea of 'no arithmetic with random numbers' in mind when people come to you with a risk matrix that purports to multiply random numbers for uncertainty and impact. No can do!
   
   
4. And then there's calculus! You say: 'I can skip this; we don't use calculus in our PMO.' Actually, you do! Calculus is the math of 'change'. And there are always change and changing effects in the PMO.
   
   One powerful idea from calculus is that we can add up the individual effects of change, usually a lot small effects, and we call this process 'integration'. Even more handy, we can specify the integration limits to include only those effects in which we are interested. 
   
   Here's an example of something you probably know about: The so-called "S" curve of accumulating probability. This curve is very handy for assessing confidence limits in risk management. It is actually an integration result straight out of calculus. Small increments of probability from a "bell curve" are integrated to form the S-curve. In other words, if we 'integrate' the "bell curve", the result is the "S" curve!
   
   Of course, the ideas work in reverse: Given the "S" curve, we can 'differentiate' it into the "bell curve" which then provides visualization of central clustering, and visualization of the outliers on the tails where events happen infrequently. 
   
   The secret to understanding derivatives is that they are always ratios: "something per something". If the "per something" part is time, then usually the ratio is a velocity or an acceleration; otherwise it's a density, as in 'parts per million'. The bell curve, being a derivative of cumulative probability, expresses a 'probability density'. 
   
   But maybe you are working in Agile methods and are concerned for 'velocity' and perhaps even the need for 'acceleration' of the evolving product base. Agile product velocity is the "first derivative" of a unchanging base; 'acceleration' is the first derivative of velocity and the second derivative of the original position.

Got it all?

Now you are the PMO math person!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile and the sailor's analogy

---

The presentation -- in the link below -- that I gave to PMI some years ago that makes an analogy between sailing a boat and Agile methods is still relevant, and probably will remain so.

Why?

Because a sailing "project" is has much in common with an Agile project:

• Tactics overlay a strategic goal, though there are broadly stated limitations and rules
• Small teams have to work together, or else someone goes overboard
• There's a lot of local autonomy
• Risk is managed locally
• The environment is pretty flat, managerially, but the leader is clearly recognized
• Team success trumps individual success; teamwork is rewarded, particularly in overcoming adversity
• The goal is set by others, but it's obvious to all observers
• The value proposition is clear and present

Have a look:

Click here for a slideshare

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Your project runs on exponentials!

---

When you read stuff like this, you have to wonder: what's this all about?!

The greatest shortcoming of the human race is our inability to understand the exponential function
- Albert A. Bartlett, The Essential Exponential! For the Future of Our Planet

Sounds profound! 

And so it is. Exponentials are the way we bend the project around the corner, or move out quickly. Linear straight-line stuff becomes curved.

Think of it: 

• The future does not have to repeat the past; 
• We can accelerate from where we are now; and 
• Phenomena can -- and will -- die off or slip quietly to an asymptotic finish

What is it?

Technically, an exponent is a number that tells you how many times another number, called the 'base', is multiplied by itself. For example, 2 exp 4 tells us to multiply 2 (the base) by itself 4 times, yielding the number 16. The exponent is sometimes referred to as 'the power'. We might say, '2 to the power of 4'.

Fair enough.

Functionally, it's the multiplying-by-itself thing that bends the curve and creates acceleration in values. In linear arithmetic, the first four products are 2, 4, 6, 8. But in exponentials, the first four products are 2, 4, 8, 16 ; clearly the exponential expression is not linear.

It's common to say: "That's increasing (or decreasing) exponentially". 

What that means is that 'as you move away from the present point, things accelerate quickly'.

Now, for the math inclined or curious, see the footnote at the end of this post.

Consider project communications:
The number of ways that N people (or systems or interfaces) can communicate is N*(N - 1), which for large N is approximately N x N, or N-squared (an exponential, N with exponent of 2).  

This the heart of the argument -- made famous by Dr Fred Brooks --  that adding more staff to a late project may make it even later, because ....  Because communications become exponentially more complex, and thus less reliable and predictable, as you add staff.

Consider project finance:
The present value of future business benefits of a project are discounted, exponentially, by the expected risk.

Financiers think of risk in terms of the 'rate of return' they demand in order to agree to commit capital to a risky project.

And, this rate of return, "r", is compounded over time. Compounding means that [1 + r] exponentially decreases with the number of compounding periods. The future value is "discounted" to a present value by that decreasing factor.

Consider risk management:

The idea that risk inversely compounds exponentially with time, and thereby discounts the value of future decisions and outcomes is commonly held concept in risk management. 

Other types of risk are subject to exponential effects. For example, the density of probable failures in the future is inversely and exponentially related to a present value of the failure rate. 

Consider the so-called "bell curve"

The 'bell curve' shows us the effects of natural clustering of random outcomes or observations around the mean value.
The actual formula for the curve is non-linear to be sure, and usually we just look up values we are interested in, which for the most part delineate confidence intervals.

But at the core of the bell curve formula's is an exponential expression which is all about how far from the mean is the confidence interval and the point of observation or measurement, i.e: 'distance'-from-the-mean squared strongly influences the confidence intervals of the 'bell curve'.

Consider schedules at the milestone

There is a 'shift-right' tendency at milestones when two or more tasks have to finish together. If the probability of each finishing is 0.9, then the probability of the milestone finishing on time is 0.9 exp N, where N is the number of tasks finishing together. That is a much lower probability of success than any of the contributing tasks.

Consider the random arrival rate of independent actors (events)
Again, the probability distribution of random arrivals is an exponential, and an important concept in certain elements of risk management (Earthquake prediction, to name one, but other types of failures as well). 

Consider 'utility'

All but the simplest concepts of utility are non-linear, and many ideas of utility can be explained or represented with exponentials.

-----------------
If you look up Bartlett's book, you'll find most of the chapters are available free in pdf format
Shout-out to herdingcats for the quotation

Footnote for the math inclined or curious:

It's common to think of the number '2' as 2 with an exponent of 1 (any number with an exponent of 1 is equal to itself); and the number '1' is 2 with an exponent of 0 (any number with an exponent of 0 is equal to 1). Other examples: The number '4' is 2 with an exponent of 2; the number '5' is 2 with an exponent of about 2.35, but also 5 is the number 10 with an exponent of about 0.7.

And, a negative exponent is mathematically equivalent to division: 1 divided by the exponential. For example, 0.5 is just 2 with -1 as the exponent, usually written as 1/2.

But here's a limitation of exponent math: there is no exponent that will give us exactly the number '0', although we can get pretty close with an arbitrarily large negative exponent. 

Now the "base" doesn't always have to be '2'. If we change the base to 10, the number 2 is now 10 with exponent of approximately 0.3. (somewhat like there is no exponent that gives us exactly the number 0, there is no exponent of 10 that gives us exactly the number 2. This is the reason that financial reports and other resource reports are not computed with exponential math. Such reports require exact numbers, not approximations)

You may have heard the expression that "things are logarithmic". That's another way of expressing the idea of an exponential. The 'logarithm of 2 (in base 10) is equal to 0.3'. That statement is equivalent to saying '10 with exponent of 0.3 is equal to 2'.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Hazards to resourcing the critical path

---

In project management school, the lesson on Critical Path includes this rule:

Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.

Beware this hazard: Resources may be real people:

The problem of applying resources arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. 

Alas! The "resources" are not interchangeable. Mary and John are unique. Consequently, consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Considering Mary and John uniquely

Take a look at the following figure: There are two tasks that are planned in parallel. If not for the unique situation that Mary and John can't be applied to two paths simultaneously, these tasks could be completely simultaneous.

In fact, the critical path could be as short as 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration. But for the assignment of Mary and John pushes Task 2 to the right.

But with only Mary and John as resources, the schedule plan stretches out to 65 as shown.

 Here's an idea:

Reorganize the network logic to take into account unique staffing applied to schedule tasks.

Now the schedule plan is shorter, though not as short as it could be if there were resources other than Mary and John. 

And that is actually the embedded lesson learned: With only Mary and John, the two tasks are no longer independent. 

And with a lack of independence, there is a "co-dependency" that is a phenomenon that has to be scheduled also. Thus, we form the rule that interdependency always stretches the plan!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!