The bane of big projects

---

In the beginning, "people" are told: "It's too soon to know where we are in this project"

After the beginning, "people" are told: "It's too late to stop the project; there's too much sunk; we have to keep going"

---

Sampling the data

And so the bane of big projects comes down to poor sampling technique: 

Either the early details are not predictive because the early "efficiencies" of cost per unit of value earned have too little history to be useful as a long-term predictor; or you've accepted the first idea for too long, thereby failing to update efficiency predictions until the late details are too late to pull the plug on a bad bet.

Sunk cost decisions:

It's easy to write this, and far less easy to execute, but never make a decision about the future based on the sunk cost of the past. You can't do anything about recovering the actual expenditure, but you do have free will -- politics aside -- regarding more spending or not. 

History has value

On the other had, sunk cost has a history, and if you are good at what you do, you will use that history to inform your decisions about the opportunity of the future

---

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

More about proposals

---

Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal:

What are the elements of a perfect proposal? Here are 12.

 

You

No one wants to hear all about you. See the next subtitle. That's who your audience wants to hear about... themselves. But (and it's a big 'but') they do need to know enough about you to know you are worth paying attention to. So, for a cold proposal, this means using the introduction or cover letter or some other means to establish your credibility - what my dad used to call your bona fides.

Them

This is what they want to know... What's in it for them? Show how you have their best interests in mind with this proposal. You understand their needs and desires and know how to satisfy them better than any alternative solution can.

Focus

Keep your focus on the specific situation. Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

Value

How will your proposal deliver and maximise value to them? The vast majority of business decisions revolve around the capacity to either make money or save money.

Benefits

But there can be other benefits too. Describe the non-financial value your proposal offers - and what this means to them. This, of course, means you need to take time to understand them and their requirements and priorities. 

Emotions

All that hard evidence gives them a reason to make the decision to accept your proposal. But it won't motivate them to do so. For that, you need to tap into their emotions. Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... Emotions drive decisions: reasons justify them.

How

So, you also need to show how your proposal will solve their problem, deliver their joy, or enhance their reputation. Make the link between what they want and what you are proposing as clear, simple, and short as you can. A 15-step sequence from the cause (your proposal) to the effect (their outcome) won't cut it. 

Process

Next they need to know what will happen if (when) they say yes. What will you do, what will they do, and how long would it all take? For confidence that your is the right choice, they need to see a plan that clearly works.

Context

This section lets them understand how your proposal fits into your life and theirs - your business and their own. This shows that you and they are compatible and is the equivalent of the more traditional (cheesy) 'how we are different to the competition'. Of course this differentiates you. It shows how this proposal is right for them and for you.

Business

Don't go all techy on a technical proposal. Remember who you are speaking to. If your audience is a business person or a group of businesspeople, focus on the business. If your audience is software engineers, focus on the business of software engineering: not the hardware. What is their business? That's how to frame your proposal.

Structure

I get it. You have a lot of ideas to get down. But, before you start, develop a structure that makes it compelling for them to follow. If they asked six questions in a sequence, then a great structure is to answer those six questions... in the same sequence. Make it easy for them to say 'yes'.

Quality

Finally remember Mark Anthony's advice: 'The evil that men do lives on. The good is oft' interred with their bones'. People remember your mistakes and easily forget all the good stuff. Make sure you check the quality of your proposal, not once, not twice... Better still, get the pickiest, most pedantic person you know to do it for you. You invested all that time. Now add a little more investment, to avoid throwing it all away!

---

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

Fear not!

---

Is this the worst news possible in project management?

All the money has been spent, and nothing has been delivered ... nothing has been earned!

Yikes! What happened to get the project to this point?

Did you fear the data?

• Were you fearful of the data, unwilling to measure or unwilling to believe the measurements of value attainment?
• Or worse yet, you actually don't know how to measure value attainment.
• Or even more worse, you kill the messenger who has the data!

What value is to be attained?

And by the way, it's damn hard to measure increment value attainment if, at the outset, you have no idea of the value to be attained. (the so-called emergent project .... feed in money and hope! something useful comes out)

And here is another fear: Fearful of making and estimate because, actually, you have no idea of what its going to take to do the project. And fearful that as resource expenditures pile up that there is nothing to show for it.

Most often, that occurs when you've made no estimate of the value requirement ... project outputs ... and the corresponding inputs required for such outputs.

So, how to be anti-fearful?

• A priori estimates are a must
• Metrics that represent attainment are a must
• Data transparency is a must (don't kill the messenger or hide the message under a project rock)
• Aggressive reaction to metric data is a must
• Pro-active look-ahead where possible. 

Einstein, AI, and the PMO

---

Consider this observation from Daniel Miessler:

AI is not competing with Einstein and Tolstoy..... AI is competing with:

• The task not being done at all
• It being done poorly
• It being done inconsistently
• It being done slowly
• It costing too much

---

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

Numbers are the PMO's best friend

---

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. 

---

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

PMO co-pilot

---

It seems that every PM framework and tool set now has a co-pilot app fired up by a generative AI engine of some kind. And, it's not just our domain: MS Windows, various cloud services, and others all now have the requisite co-pilot.

In a few words, generative AI has arrived big time in project management for many of the same reasons it's arrived elsewhere:

• Speedy results, if there is enough training data. And not just speedy, but incredibly fast by most standards of creativity
• Deep dive data driven, not just a surface look. Stuff you may not have known was there is, in fact, there.
• Multi-variate processing; if you have enough richness in the data, then generative AI can consider huge numbers of parameters when synthesizing or optimizing a result.

All three of those are big-time influencers in the PM world. Speed (with accuracy) may monetize right to the bottom line. Not only from labor savings, but from opportunity capture and exploitation only available from acting fast.

The big query+

PMOs have had data warehouse capability (big data storage, and complex retrieval query engines) for many years (decades, really). But this is very different because the query engine is not some SQL-based application, but is really a neural-network inquistor that is manifestly more powerful in it's ability to consider scope (data + parameters + alternatives), and synthesize outcomes that nowhere existed in the data warehouse. (Obviously a strength and weakness: truly innovative, but how do you validate an outcome that nowhere else existed?)

And so the query power, if you want to think in data warehouse terms, brings on a big shift in division of labor; some jobs will be demoted or disappear and others will be created out of whole cloth .. to wit: prompt engineer.

Assisted Brainstorming

As a practical matter, a simple way to start using a co-pilot in the PMO is to use the AI engine (co-pilot) for assisted brainstorming. It's really really useful in that task. Give it prompt; evaluate the answer; and then prompt again to expand or explain. And on it goes. In just a few minutes you may have litterally pages of ideas to drive project ideas. 

All things considered

The big deal for project management is the amazing scope -- that is, the number of influencing parameters -- that can be cranked into schedule optimization, cost estimation, and risk management. 

• For schedules, you've got schedule logic, but then parameters for risk elements, resources, immendiately past productivity (cost and schedule efficiencies) and environment (tools, support systems, virtual connectivity, even the weather). There could be literally multi-thousands of optimizations evaluated, given the broad scope of parameters.
  
  
• Resource parameters could include various talent-indicator parameters, sensitivity to teams and direction, track record re problem solving, drive and initiative assessments, etc. In some ways, a "big brother" input to scheduling which your 'boss' already has in their mind's eye. (This begs the question: how does these parameters get regulated and validated from an HR perspective?)
  
  
• Cost history can be "adjusted" to current parameters to make history more relevant to the instant situation.
  
  
• Risk management can be made more calibrated and therefore more quantitative, putting less emphasis on qualitative opinions and hunches. All manner of risk tools which are parameter driven can be made more robust and more relevant faster.
  
  
• For monte carlo simulations, and similar simulation and statistical considerations, like optimizing Bayes 'guesses', a generative AI tool can create infinitely more data points, data patterns, and trends which are then evaluated for their statistical properties with monte carlo techniques.
  
  

And then there's the paperwork

Every PMO is backed up by reports, with data entry coming from all points, and multiple readers who want not only executive summaries, decision trees, and red-green indicators, but also full-length explanations and backup.

At some point, it's a matter of a prompt for which then a product pops out!  All on schedule; all produced, validated, and distributed without intervention.  This may be a good thing to have.

---

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

NSA AI Security Center

---

General Nakasone, the Director, NSA, has announced the formation of the NSA AI Security Center in a speech at the National Press Club, as reported on the Security Week website:

Army Gen. Paul Nakasone said the center would be incorporated into the NSA’s Cybersecurity Collaboration Center, where it works with private industry and international partners to harden the U.S. defense-industrial base against threats from adversaries led by China and Russia.

“We maintain an advantage in AI in the United States today. That AI advantage should not be taken for granted,” Nakasone said at the National Press Club, emphasizing the threat from Beijing in particular.

DIRNSA went on to say it would become “NSA’s focal point for leveraging foreign intelligence insights, contributing to the development of best practices guidelines, principles, evaluation, methodology and risk frameworks” for both AI security and the goal of promoting the secure development and adoption of AI within “our national security systems and our defense industrial base.”

He said it would work closely with U.S. industry, national labs, academia and the Department of Defense as well as international partners.

---

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

Enterprise Agile

---

Applying agile methodology in your software project? Good!

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

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 small 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? It comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners and/or private investors (if privately held), or owners and public 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 funds you can dip into at your leisure and convenience. Enterprises don't work that way.

With enterprises comes rules and accountability

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 that a few 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, and how does that "doing" add value to the enterprise?
2. Schedule: when can you likely produce results? (No single point estimates, of course. It takes a range!)urc
3. Resources: how much do you need, and when do you need it? In other words, the resource ramp (up, but then inevitably down) We're speaking about cash flow, and resource allocations.

I can't do this!

You can't handle the narrative?

You can't describe what you need? (Or you stubbornly cling to the No Estimates paradigm?)

You can't connect the dots: value, resources, scope? 

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. The cover photo is below

---

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

Setting up the strategy

---

Consider this military wit, and put it in the context of a PMO.  

"There is an old—and misleading—bit of conventional military wisdom which holds that “amateurs study tactics, while professionals study logistics.”

The truth is that amateurs study only tactics or logistics, while professionals study both simultaneously.

The most brilliant tactics ever devised are pointless when the supplies needed to execute them do not exist, while all the supplies in the world are useless when a commanding officer has no idea how to effectively employ them."

Quote from "Field Marshal: The Life and Death of Erwin Rommel"

by Daniel Allen Butler

Are you the professional or the amateur?

Consider what are "logistics" in the project domain:

• Supplies and materials, of course
• Utilities, communications, and facilities (you gotta sit somewhere)
• Tools and training
• Supporting activity from Finance and Accounting (they have the money!) 
• Supporting activity from purchasing, inventory management, and receiving (they have the goods!)
• Supporting activities from the various "ilities"

If you can get that wagon train all connected and working for you, then of course there is the small matter of strategy:

• How strategic are you? Anything less than a year probably qualifies as tactics. Anything over three years and you should build in some tolerance for some business instability.
• What is the lay-line to your strategic goal, and of course, what is your goal?
• How much deviation from the lay-line can you tolerate for agile tactics (zig and zag along the lay-line)
• Can you be strategic on some elements of the 'balanced scorecard' and simultaneously tactical on others(*)?

Got all of the above together? 

Good. Now(!) you can entertain tactical moves, knowing the support is there.

_________________________

(*) Balanced scorecard: Finance, Customer, Product, and Operating Efficiency