Wednesday, September 27, 2023

"Practicals" and not so practical



Have you noticed this?
Have you noticed that some people seem firmly planted and comfortable with their surroundings, but there are others that can't operate a hammer or a screwdriver?

Have you noticed that on many projects there is a unofficial segregation of the workforce something like this (*):
  • The "practicals" who live and work and think in the physical world (whether in the office, or not)
  • The "virtuals" who live and work and think in the remote, virtual, and digital space (even if they go into the office)
Join things up: Leverage the differences and make it an "And":
In the best of all cases, the win-win is to leverage the conjunction of 'practicals' and 'virtuals' as a reinforcing join of culture, skills, and interests. 

Architecture is a good place to start. How could you build a new "anything" without both working together: Design, analysis, construction? 

Have you ever looked closely at a sweeping fly-over highway bridge, as a good example? 
  • How do they get those massive iron beams to gently curve over hundreds of feet and join seamlessly with the next? 
  • How do they get the concrete columns to have just the right arc to give the roadway above the right degree of bank on the curves? 
  • How would the CAD ever match up with the 'physicals' who drive the rivets and build the molds if they didn't work together ... rather than apart.

Practicals Versus Virtuals
'Versus' doesn't buy you anything
Instead of the joy of a 'reinforcing join', the opposite may be a dis-attraction, rejection, or tension between strangers from two spaces: physical and virtual.

In systems terms, there may be little or no throughput, poor gain on resources committed, and outright hostility. Obviously, there is nothing to be gained by being at loggerheads about the differences in experience, attitude, and values. Those who can type should also be able to use a screwdriver; but it works the other way around also. 

But, in fact, the cultural divide can be a chasm: pay, promotion, recognition, status, security to name a few of the HR issues, but also respect, arrogance, and elitism that unwittingly divide rather than unite, to say nothing about herd loyalty and commitment to win-loss.

If there were an answer ...
If there were an answer for this, other than self-awareness and walk-in-their-shoes exercises, I would put it down in the next paragraph

But, there is no next paragraph .....

++++++++++++++
(*) Credit to Ross Douthat for the idea of 'practicals' and 'virtuals'


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

Saturday, September 23, 2023

Wait! You're letting my people go?



Well, talk about cratering a schedule and resource plan!
Layoffs in the middle of a project will do it for you.

But wait!
There may be a silver lining here:
  • Communication complexity in and among project participants decreases as the square of participants. That could be a winner

  • You may be able to select the departees. That's tough in any circumstance, but it's also an opportunity to prune the lesser performers.

  • Some say that if you want to speed up a project, especially software, reduce the number of people involved (the corollary is more often cited: adding people to a team may actually slow it down)

  • There's an opportunity to rebaseline: All the variances-to-date are collected and stored with the expiring baseline. A new plan according to the new resource availability becomes a new baseline. Unfavorable circumstances can perhaps be sidestepped.
Of course, there are downsides:
  • If your customer is external, they may not relent on any requirements. You're stuck trying to make five pounds fit in a three pound bag.

  • There may be penalties written in your project contract if you miss a milestone, or overrun a budget. That just adds to the fiscal pain that probably was the triggering factor for layoffs.
Did you see this layoff thing coming?
  • On the project balance sheet, you are the risk manager at the end of the day. So, suck it up!

  • And there's the anti-fragile thing: build in redundancy, schedule and budget buffers, and outright alternatives from the git-go. And, if you didn't do those things in the first baseline, you've got a second bite at the apple with the recovery baseline.


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

Tuesday, September 19, 2023

I've got a plan: nobody cares



It's so damn frustrating!
You spend a lot of time planning, coordinating, evaluating ....
And then it's D-Day, circumstances intervene, and nobody follows the plan 😮 
(Well, they follow bits and pieces, but the plan as such is almost unrecognizable)

That's a few sentences to say what we all know:
No plan survives the first touch with reality
So, if this is all too obvious, what is it you do?
  • The first thing is to have a communication plan in hand before the execution begins so you can touch everyone you need to reliably and quickly. And this part of the plan should be bullet proof
  • The second thing is to know in advance where all the decision makers are going to be and how they are to be reached; and what authorities they have.

  • The third thing is to have supervision or tactical deciders in place where the work is being done to make the minute-to-minute decisions that might save the day. In other words, some decentralization of authority
  • Another thing is to have redundancy built in, as well as time or cost buffers, to be able to override, or fill-in the low spots. In other words, a plan with no margin is really not viable from the git go. 

  • If "it" fails this time, know when you are going to try again. Obviously, "failure" has to be obvious, measurable, without ambiguity, etc.
  • And if "it" fails, have a lessons-learned exercise ready to go.
     
  • The principle of "calculated risk" should be built-in: "When all matters are considered and weighted by value, the benefit of taking a risk should be (at least) strategically beneficial, even if not tactically beneficial (the battle was lost, but the engagement won the war)



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

Friday, September 15, 2023

Data: Rule #1



The first rule of data:
  • Don't ask for data if you don't know what you are going to do with it
Or, said another way (same rule)
  • Don't ask for data which you can not use or act upon
 And, your reaction might be: Of course!

But, alas, in too many PMOs there are too many incidents of reports, data accumulation, measurements, etc which are the progeny of PMO doctrine. But the reality is: There actually is no plan for what to do with all this stuff that comes in. 

Sometimes, a data collection is just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job. 

But sometimes, there is a "feeling" that if such data is not coming in and available that somehow you're failing as a manager. Afterall, one view of management is to measure, evaluate, and act. If you're not doing the first step, how can you be managing effectively? Ergo: measure everything! Somehow, the good 'stuff' will then rise to the top. (I submit "hope" and "somehow" are not actually good planning tools)

The test:
 If someone says they need data, the first questions are: 
  • What are you going to do with the data?
  • How does the data add value to what is to be done
  • Is the data quality consistent with the intended use or application, and 
  • Is there a plan to effectuate that value-add (in other words, can you put the data into action)?
And how much data?
Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

And information?
Well, the usual definition is that information is data, perhaps multiple data, integrated with context, and interpreted for the current situation.

So, the rule can be extended: If there are not means to process data into information, is the data necessary to be collected?

Bottom line: To state the obvious: always test a request for data collection for value-add before spending resources!

______________
(*) Statistical significance: The observed behavior in the data is unlikely to be just a random outcome; the data is predictability attributed to something specific which can be described statistically.


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

Monday, September 11, 2023

The language of "Cost"



How many ways are there to say "Cost"?
Certainly, more than one!

When "they" ask: 'How do YOU manage cost?", your answer is: 'It's complicated' because there are so many varieties of 'cost'.

Project managers certainly have at least this list:
  • Estimated cost (of course, an estimate has to be made in the context of a plan: scope and schedule and resource plans)
  • Baseline cost (estimated cost at the beginning of a planned period)
  • Re-baseline (Sunk cost, plus a "new" estimate for the ensuing period)
  • Cost variance (the difference or departure of actual cost from the baseline)

  • Planned value (baseline cost input to the project, over time, allocated to planned functional or feature achievement)
  • Earned value (as a proportion of Planned Value actually completed)
  • Cost performance Index (as a 'cost efficiency' measure of how well cost input earns value)

  • Actual cost (measured at a point in time, regardless of achievement)
  • Sunk cost (aka actual cost incurred)
  • Direct cost (costs attributed to this project, and this project only)
  • Indirect or overhead cost (common costs shared across many projects, proportionally)

  • Labor cost (a component of direct cost; does not include overhead labor)
  • Standard cost (used by service organizations and Time & Materials proposals to 'fix' or standardize the "labor cost by category" to a single dollar figure within a range of costs for that labor category. *)
  • Material and contracted services cost

  • Throughput cost (only that part of direct cost required to actually construct value outcomes; often used in combination with Standard Cost)
  • Construction cost (aka Throughput cost, but sometimes also total of direct costs)

  • Incentive cost (paid as direct payments to individuals and contractors for specific performance achievements)
Finance, accounting, and business management have a few more:
  • General and Administrative cost (G&A), mostly for "top-level headquarters" expenses
  • Marginal cost (cost of one more item that does not require more of 'something else' to enable)
  • Cost margin (difference between cost of sales and revenue associated with those costs)

  • Discounted cost (cost after a reserve for risk, usually calculated over time)
  • Depreciated cost (cost accumulated over time, as different from cost in the moment)
  • Cost of sales (direct cost to generate sales)

  • Activity Based Costing [ABC] Overhead costs allocated to specific activity, plus direct costs of the activity.
---------------------------------
(*) Standard Cost: As an example, for Labor Category 1, the salaries may range from $1 to $10, but the Standard Cost for this category may be $7 because most in this category have salaries toward the upper end. Standard Cost is not necessarily an arithmetic average within the category; it is a weighted average



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

Thursday, September 7, 2023

Risk management mistakes for the beginner



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!

Monday, September 4, 2023

Teams: White space and slack



One of the big differences between a team and a group is cohesiveness around the goal:
There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness
Inevitably, keeping the team together to promote cohesiveness raises the question: 
How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?
In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace
That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
Running cost of teams
One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost
Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)



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

Thursday, August 31, 2023

Stochastic Parrot for PMs?


One meme making the rounds is the "Stochastic Parrot" caricature of 'large language models' (LLMs) that underpin all the AI chat and query systems we're experiencing. 
  • "Stochastic" meaning something randomly determined; having a random probability distribution or pattern that may be analyzed statistically but may not be predicted precisely.

    Stochastic processes or events are different frohm a truly random phenomenom insofar as something truly random will have no predictable pattern or statistically viable distribution of outcomes. 

    "White noise" is stochastic; it's probability distribution is "uniform". A blip here and there is random; there is no pattern of outcomes that can be fit to a probability distribution.

  • "Parrot" suggesting that was the LLM is doing is just repeating back what others have said
And so you put those ideas together, and you get the characterization of an LLM as a parrot of ideas that are statistically combined in the most probable configuration. And, you wouldn't be far off with that idea. 

What about the PM application?
PMs are happy with a stochastic parrot outcome of statistically relevant ideas and data from a vast history database. From the very beginning, PMs have been encouraged to keep history; to keep records; and to apply the lessons of history to the next project. And so a LLM becomes a tool for just that purpose. 

As an example here's a "stochastic parrot" taken from ChatGPT 3.5 on the risk matrix, a common tool in project management.

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.





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

Monday, August 28, 2023

AI Threat model Framework


Somewhat very akin to the conventional "use case" structure that many are familar with, and borrowing the power of a conversational narrative from Agile methods, and sundry psychology systems, Daniel Miessler posits a threat model framework which he says is a target for for policy makers, but I say it's a target for any PMO working in software services. You can read it here.

In his framework, Miessler has these components:
  • The ACTOR, which can be an individual, an enterprise, or a system
  • The TECHNIQUE, which is the method or process, like hacking, will cause harm.
  • The HARM, which is the functional outcome of the harm, like 'misinformation'.
  • The IMPACT, which is what happens when the 'harm' reaches its target. One example might be financial loss. 
As PMs we're familair with frameworks and how to apply them. Miessler writes that the objective of his framework is to talk about the AI threat in a converational way that will draw in policymakers. He says this: 
What I propose here is that we find a way to speak about these problems in a clear, conversational way.

Threat Modeling is a great way to do this. It’s a way of taking many different attacks, and possibilities, and possible negative outcomes, and turning them into clear language that people understand.





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

Friday, August 25, 2023

Kano: Utility at work



"Customer value", aka "the value proposition", is complicated. 
Books fill the shelves on those topics. 
  • What do 'early adopters' value?
  • How does age come into play?
  • Is economic willingness different from economic capability in the value equation?
  • How do culture and relationships figure in the proposition?

All good questions, to be sure. 

But the missing quality is "UTILILTY", specifically "marginal utility." Marginal utility is the added satisfaction a user (customer, or consumer) gets from having one more unit of a product or service. 

Marginal utility separates the "willing" from the "capable", given the capacity to spend. The whole idea of working on the margin begs images of value plots that could be anywhere from linear (the last unit is just as valuable and desired as the next unit) to various shapes of non-linear (the last and next units' values are different)

One might ask: is there a way to map all this stuff so that a picture emerges? Yes. Kano Analysis may help see the bigger picture.

What is Kano analysis?
Kano analysis is a product feature/function evaluation tool that gives visualization to relative merit over time as trends change. The usual presentation is a four-sector grid with trend lines that connect the sectors. 

The grids are defined by the horizontal and vertical scales. Don't take the word 'scale' too seriously; for the most part the scales are non-calibrated, but informed, opinion:
  • Vertical: customer attitude, feeling of satisfaction, or other elements of value appeal.'
  • Horizontal: some quality (or metric) of the feature/function that's important to the customer.

 
Trends and Utility
The trends plot the utility of changing customer satisfaction (vertical) as a function of product functionality (horizontal). These plots vary from linear to nearly exponentially non-linear.  And, the utility of satisfaction need not maintain only one direction; direction can change, trending up or down, as customer/user attitudes change.

 
Developers use the Kano board with sticky notes to show how feature/function in the form of stories or narratives might play out over time.


 And, we take the trouble to do this because:
  • There's only so much investment dollars available; the dollars need to be applied to the best value of the project.
    Presumably that's the "ah-hah!" feature, but the "more is better" is there to keep up with competition; and, some stuff just has to be there because it's commonly expected or need by regulation.
  • Trends may influence sequencing of iterations and deliveries. Too late, and decay has set in and the market's been missed.
  • The horizontal axis may be transparent to the customer/user, but may not be transparent to regulators, support systems, and others concerned with the "ilities". Thus, not only don't forget about it, but actually set aside resources for these 'indifferent' features and functions.
How far ahead of the trend can you be and not be too far ahead? Just a rhetorical question to close this out.



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

Tuesday, August 22, 2023

The tale of the tails


Your data analyst comes to you with tales of the tails:
  • Yikes! Our tails are fat!
  • Wow! Our tails are thin.
What's that about?
If you're into big words, it's about the "kurtosis" of the data, a measure of the distribution of data around the mean or average of a bell-like distribution of probabilities. More or less kurtosis means more or less data, respectively, in the tails of the bell-like distribution.

It's about risk and stability
If you don't care about the big words, but you do care about risk management and volatility or predictability that could affect your project, then here's what that is about:
  • Fat Tails: If there's more data in the tails, farther from the mean, then there is correspondingly less data clustered around the mean. Interpret fat tails as meaning there are more frequent outliers and more non-average happenings, meaning more volatility and less predictability than a normal "bell curve" of data points.  

  • Thin tails: Really, just the opposite of the fat tails situation. Thin tails means less data in the tails, and the outliers, such as they are, are many fewer. There is a concentration around the mean that is more prominent than the usual bell curve.

    Interpretation: more stability and predictability than even the steady-Eddie bell curve, because most happenings are clustered around a predictable norm. 
Is there an objective metric?
Actually, yes. From math that you don't want to even know about, a normal "bell curve" has a kurtosis of "3". Fat tail distributions have a figure greater than 3; thin tail distributions, less than 3. Note: some analysts normalize everything to "0" +/-, rather than "3" +/-.

Excel formula:
As luck would have it, there is a formula in Excel for figuring the kurtosis of a data set. "KURT" is the formula, and you just show it your data set, and Excel does all the work! But as a PM interested in risk to your project, you just need to know from your analyst: fat, thin, or normal.



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

Saturday, August 19, 2023

Balancing Expectations: Sponsor and PM



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.


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

Wednesday, August 16, 2023

Threats, vulnerabilities, and Risks



Daniel Messiler has an interesting essay about threats, vulnerabilities, and risks that is worth a quick read.

He summarizes this way:
  •  A Threat is a negative scenario you want to avoid; damage or loss of an asset; a danger
  • A Threat Actor (person, entity, organization, is the agent that makes a Threat happen; threats and threat actors are cause-effect related.

  • A Vulnerability is a weakness that can be exploited in order to attack you; vulnerabilities may enable threats. Security weaknesses in data and communication systems are a common vulnerability.

  • A Risk is a negative scenario you want to avoid, combined with its probability and its impact. Risk and threat the same? No, because a threat is deterministic whereas a risk is probabilistic. 

    The difference between a Threat and a Risk is that a Threat is a negative event by itself, where a Risk is the negative event combined with its probability and its impact



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

Sunday, August 13, 2023

Stability! It's a good thing



Stability!
It counts for a lot.
It implies -- for behaviors and management decisions -- predictability, reliability, under-control (but not risk-free, of course), coherent narrative, steady-state goals, and a strategy that is understandable to those who have the job of implementing it.

Perhaps you are aware, as many are, that stability requires feedback to effect error correction and trap excesses and blind alleys. 
Ah yes!
We know about feedback.
Open loop systems -- those with outcome but no feedback -- are prone to many uncontrolled and unexpected responses. Who can predict what a stimulus will do to a system that has no feedback? Actually, that's a really tricky task.

So, what about feedback? 
What's to know?
  • Timing is everything! Getting the feedback "phased" in time such that it has a correcting effect rather than a destructive effect is vital. The former is generally called "negative feedback" for its corrective nature; the latter is generally called "positive feedback" for its reinforcing rather than corrective nature. And, when its too late, it's generally called ineffective.

  • Amplitude, or strength, or quantity is next: It has to be enough, but not too much. Tricky that! Experimentation and experience are about the only way to handle this one.
What could possibly go wrong?
Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management
Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

I should mention:
The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]



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

Thursday, August 10, 2023

Starve it, or stretch it: Critical Path



/>In project management school, the lesson on Critical Path includes Rule #2:
Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.
But, of course, Rule #2 follows from Rule #1

Rule #1, if you haven't guessed is:
Create a schedule network so that the critical path is revealed.

But here's an issue: If you're only working with major milestones, then there are no network of dependencies, so there is no opportunity to apply something like Rule #1. It follows that there can be no Rule #2, and so no insight to schedule starvation. Yikes! 

No starvation, but a longer path?
Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Alas! The "parts" are not interchangeable. Mary and John are unique. Consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Staffing and Schedule intersection
The intersection of the staffing plan with the schedule plan sometime brings up results that are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

Take a look at the following figure for Rule #2: There are two tasks that are planned in parallel. If not for the resource requirements, these tasks would be independent, and if independent the critical path would be 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration.


You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50 days, not 65 as shown.

Let's violate Rule #2 and invent Rule #3: Reorganize the network logic to take into account unique staffing applied to schedule tasks.

 
Using Rule #3, staffing does not actually start on what was the critical path, a violation of Rule #2. 
 
But the advantage of Rule #3 is that the overall schedule is shorter nonetheless. In this case, the critical path is only 55 days.
 
There is still inter-dependence among tasks. But a new critical path using Rule #3 more optimally incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.


Here's the main idea to take away: 
Any lack of independence among tasks will stretch the path upon which those tasks are scheduled




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

Monday, August 7, 2023

Fake Video inteviews



There is a growing threat that the person to whom you are video conferencing is really a deep fake. For projects, this threat arises in recruiting strangers remotely by video call, but also in other situations when the 'familiar face' is really fake. (But I know that person! How could the image I'm seeing be fake?)

Here is a report of new research by NSA and UC Berkley about a new tool -- 'monitor illumination' -- that can 'fake the fakes' in a way that gives better assurance that the fake is detected.

So, maybe you are talking with an avatar ....

Kyle Barr has a report on gismodo.com with this headline:
FBI Says People Are Using Deepfakes to Apply to Remote Jobs

So, what is Barr reporting that the FBI is saying?

According to the FBI’s announcement, more companies have been reporting people applying to jobs using video, images, or recordings that are manipulated to look and sound like somebody else.

These fakers are also using personal identifiable information from other people—stolen identities—to apply to jobs at IT, programming, database, and software firms.

The report noted that many of these open positions had access to sensitive customer or employee data, as well as financial and proprietary company info, implying the imposters could have a desire to steal sensitive information as well as a bent to cash a fraudulent paycheck.

These applicants were apparently using voice spoofing techniques during online interviews where lip movement did not match what’s being said during video calls, according to the announcement. Apparently, the jig was up in some of these cases when the interviewee coughed or sneezed, which wasn’t picked up by the video spoofing software.

And, somewhat related insofar as fake references and supporting documention, the report includes this timely warning: "The FBI was among several federal agencies to recently warn companies of individuals working for the North Korean government applying to remote positions in IT or other tech jobs"

Bottom line: with remote interviews, some caution advised!


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

Friday, August 4, 2023

Manage Idleness to your advantage



>One of the big differences between a team and a group is cohesiveness around the goal:
There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness
Inevitably, keeping the team together to promote cohesiveness raises the question: 
How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?
In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace
That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
Running cost of teams
One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost
Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)


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

Tuesday, August 1, 2023

Cost estimates when you just don't know


It's not unusual. 
You're asked to estimate your work, and really: you just don't know.
It comes up a lot in the AGILE space, where many hold that "estimate" and "agile" don't belong in the same sentence, let alone the same project. 

We're supposed to accept "emergence" at whatever cost. That doesn't bode well in the enterprise context. Those guys in the C-suite want something more bounded.

There are methodologies for handling the "just don't know" issue.

Allowances: The first way to handle this comes right out of the construction industry wherein a customer is given an allowance of funds for "emergent" need. Allowances provide flexibility to trade feature, function, and fit among disparate components. Pay a little more for component "A" and accept less for component "B", all within the allowance.

Allowances can work in the intangible space also, where we find many software projects with not-so-clear ways forward. What we call "first impression" requirements that don't have history and precedent to fall back on. It comes down to "Do what you can to get me something working for this allowance". 

Time and Materials .. T&M: This is everyone's standby. Just start working and see where it takes you. T&M has been around almost since the industrial revolution took off. It's best applied to research rather than development, where the target is so elusive that I might NOT know it when I see it. 

Cost reimbursable: A bit more constrained than T&M, and perhaps a contractor's version of allowances, the total scope is within an overall budget (cost envelope), but the project proceeds by increments, reimbursing the cost at each increment. If there's not reasonable progress, the project is redirected or even canceled. 

Some put the cost reimbursable method squarely in the "earned value" camp. Earned value: Show me the value you're producing, and I'll pay you accordingly. From your performance-to-date, taking into account improvements you can apply, forecast the outcome. Are you still within the budget envelope?

Incentives and Penalties: Cost is saved, or avoided, with productivity boosts. Almost every manager thinks in terms of incentives because these days almost every manager is personally on some kind of incentive-driven pay plan. Of course, one can also think in terms of penalties. 

But the utility of the marginal compensation comes into play when evaluating how to stimulate productive work. Everyone has a set-point in mind when it comes to their comp. 
  • Penalize people below their set-point and morale suffers big time, often out of all proportion to the penalty. It's hard to get productivity pumped on the basis of penalties.
  • Bonus people above their set-point enhances morale, but the utility fades quickly, so it doesn't take huge sums to get a boost in productivity.


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

Friday, July 28, 2023

Regression to the Strategy


Regression -- as a process -- is an analytical look back through past events (that relate to one another) to find or calculate a smooth path or relationship that more or less represents an optimum way through the events (or dots, or data). 
Optimum in this situation means that the "best" regression path is that path for which the distance or divergence from the regression path to any particular event is as minimum as possible. 




Regression as strategy

One interpretation of the regression path that is useful for project managers is that the regression path is the overall strategic path, and the events or dots or points off the path are the tactical outcomes in the moment. 

The tactical outcomes pull on the strategic path to go this way and that way; thus, the overall strategic outcome is dependent on the tactical outcomes .... but we would expect that consequence. 

Other stuff that matters

One more event: Regression analysis can provide valuable insights, such as determining the strength and direction of the direction the strategy might take with one more event pulling this way or that way. 

In the image above, if the big dot in the upper right is the desired strategic outcome, then some adjustments to tactics are going to be required to bend the trend line to the desired target position. 

This situation is the project management challenge: how to use the insight from regression analysis to fashion a path to the target.

A bit about forecasting:  Technically the regression line is not valid outside the observed events. Thus: be wary of any projected outcome based exclusively on historical performance. This is the bane of earned value calculations which project linearly based on historical performance.

That all said, consider these ideas: 

Patterns and Trends: Regression analysis can identify patterns, trends, and relationships in historical data. These patterns can provide insights into future behavior , assuming that the underlying conditions and relationships remain stable. In projects, that assumption is always being tested.

Sensitivity Analysis: Regression analysis allows for sensitivity analysis, which involves examining how changes in the tactics impact the strategy. Sensitivity analysis is also another name for "efficiency" analysis wherein you look for how efficient resources are being used, and what is the marginal value of the next increment of resource.

Some caution, repeated: It's important to note that regression analysis relies on certain assumptions and limitations. Extrapolating relationships beyond the range of observed data or assuming that historical patterns will continue unchanged in the future can introduce uncertainties and errors. Therefore, when using regression analysis for future predictions, it is crucial to consider the limitations and exercise caution while interpreting the results.

Bottom line: Yes, it is possible to conceptualize the optimum path in regression analysis as a strategic outcome and the push-and-pull drivers as tactical inputs. This analogy can be helpful in understanding how regression analysis relates to strategic and tactical decision-making.




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

Tuesday, July 25, 2023

Cost and Schedule, but Cost before Schedule?


Cost, schedule, scope, and quality. 
Everyone in this business has a familiarity with those four parameters
Everyone knows that even if they are fixed on paper in the project plan, they are fluid in practice.
How fluid? And who manages the fluidity?

The answer to the second part is easiest to say: You do the managing, meaning you as PM or PEO.
And to the first part, there's always cost and schedule, but in the crunch, if you're a business or a government guy or NGO spending the taxpayer's or donor's money, cost always comes before schedule.

Meaning what?
  • Meaning that money is more precious than time; it's a matter of scarcity that determines value.
  • Meaning that more forgiveness is granted for lateness than for cost overruns.
  • Meaning that the political and business sensitivities to money are always greater than they are for time. This is a form of 'utility' bias. Losing money is agonizing, often out of proportion to the factual loss; not so much with time.
Until it's not
Ooops! There are time-sensitive projects to be sure where you'll peay any price to make the milestone. Sometimes lives depend on timeliness; sometimes, there is a business deadline that simply expires at midnight. In this event, you flip the utility curve around and pay the price 😟



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

Saturday, July 22, 2023

Shall, will, and may


You shall ...
I will ....
You or I may .....

Heard these phrases before?
What to make of them?

Actually, if you're sitting in the PMO reading a contract or other legal document handed to you by your contract's administrator, or you're on the other side helping to write an RFP , then these words are important.
  • "Shall" should be understood to be directive without discretion to act otherwise. Take 'shall' to be a synonym of 'must'. Usually, the context is that 'you' tell 'them' that they 'shall' do something.

  • "Will" is the other side of the table. When I impose a 'shall' on you, I often give myself a corresponding task. In that event, "I will" do something in the same context that I impose on you a "shall". "I will" should be taken as a commitment, just as "You shall" should be taken as a directive.

  • And then comes "may". A task constructed with a 'may' is discretionary on you and I. We may do it; we may not
All clear? You may close this posting.


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

Wednesday, July 19, 2023

"Command Presence"


I once had a colleague, who I admired greatly, be demoted from a vice-president position for lack of "command presence" (his telling of the reason)

And, so what is "command presence" and is it something to strive for? Can it be learned? Can it be taught?

Here's a few ideas on the topic:

It's about personal qualities and behaviors
Command presence refers to a set of qualities and behaviors that encompasses the ability to project confidence, assertiveness, and control over a situation, as well as to inspire respect, trust, and obedience from others.

Perhaps the phrase brings up an image of a military leader. Rightly so. But it's evident wherever leadership and the ability to influence others are important.

Is it "command and control" dressed up to be more palatable? It can be, but it shouldn't be. Command presence can be felt effectively in horizontal organizations as well as more vertical structures.
Judge for yourself as you read on:

You've got it when you've got:

Confidence: In a project situation, individuals with command presence exude a sense of self-assuredness and belief in their abilities, bordering on arrogance. They display confidence in their decision-making, communication, and problem-solving skills, which if directed toward objectives understood by all,  helps to instill trust and reassurance in others.

Calmness under pressure: Command presence involves the ability to remain composed and level-headed in challenging and stressful situations. 

Assertiveness: Command presence requires individuals to assert their authority and communicate their expectations clearly and firmly. 
Saying "no to power" is often part of the job jar. So is picking your moments to say 'yes'.

Individuals make decisions decisively, without hesitation, and are not easily swayed by external pressures. Of course, that can be borderline stubbornness, but one can be assertive and still be convinced by new evidence (Bayesian thinking) 

Physical and vocal presence: This is not about the big-guy small-guy syndrome. And it's not about being the verbal bully in the room. Be aware of your non-verbal cues which play a significant role in command presence. Maintain an upright but casual posture without being rigid, maintain eye contact, and use strong and confident body language. Speak with a clear and authoritative voice, commanding attention and conveying a sense of purpose.

Knowledge and expertise: Leaders with command presence possess a high level of knowledge, skill, and experience in their field. But, at the same time, they are respected for their respect of others who have the expertise in the moment.

Respect and empathy: While command presence requires a certain level of assertiveness, it is important for leaders to also demonstrate respect and empathy towards their subordinates. By showing understanding and consideration for others' perspectives, leaders can foster a positive environment and build stronger relationships.

Can it be learned? Can it be taught?
Yes, and yes
Developing command presence is a lifelong journey.
It's a learning exercise that involves honing one's communication skills, emotional intelligence, self-confidence, and expertise. 



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

Sunday, July 16, 2023

Building the Appian Way


As a project, the Appian Way was monumental for its time: Phase I, built in only one year .... 312 BCE ... the paved road (originally, a military road) cuts through the Alban hills and the coastal Pontine marshes to connect Rome to far southeast Brindisi.

But think about this: the Project Executive Officer, PEO, one Appius Claudius Caecus, did not have a couple of tools at his disposal that we so routinely use that they are not even noticeable:
  • There was no "0" in the Roman system of math. "Nothing" was not a number. Roman numerals are/were for counting and positioning (ranking, or ordering), but not for measuring. Today, we say that Roman numerals are "cardinal" numbers, meaning numbers that are for counting.

    How did Caecus calculate his project variances? Was zero-variance not a possibility, given no '0" in the system?

    However, to build a road, you've got to be able to measure things. So, when it came to measuring and dealing with quantities, the Romans relied on a separate system known as the Roman system of measurement. This system was based on various units and standards, such as the foot (pes), the inch (uncia), the palm (palmus), and the cubit (cubitus), among others. These units were used for measuring length, weight, capacity, and other quantities.  

  • There were no fractions in their system of mathematics, even though a pseudo-system of fractions existed in ancient Egypt. Maybe if Marc Antony has been around three centuries earlier, he could have brought fractions home.

  • And, there were no negative numbers. This concept is almost middle-ages in its origin. Not until the 16th century did negative numbers really come into general mathematics. 

    Does this mean that Planned Value - Earned Value (*) was always positive? That if circumstances were such that at some point EV were greater than PV, a negative number to be sure, that Caecus could only describe that he was ahead of plan, but couldn't calculate it?

  • And, of course, there was no concept of random effects and probability.
    Those effects were left to the Gods. (See my review of the book on risk management entitled "Against the Gods")
They did it
So, somehow, the Romans built a magnificent road, parts of which survive today, without a "0", without fractions (formally at least. One can imagine half a cubit, even if they can't formally express the idea), and without negative numbers. 

I wonder if I could run a PMO without these tools? Doubtful! And, my PMO would also have random numbers and systems of probability which also did not come along until about the 18th century.

_____________
(*) PV - EV is a variance, calculated at a specific point in time, that indicates positive or negative schedule variance. You've either earned what you've planned at the right time, or you've not. Some caution, however: this formula is only valid for only the duration of the baseline timeline of the project; it's not valid thereafter. Example: It's invalid to be a year late beyond the baseline delivering all the EV, and then declare that PV - EV is 0, thus no schedule variance!



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

Wednesday, July 12, 2023

Working on a proposal? Some ideas ....



Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal, augmented and paraphrased with my spin on it.
 
You (better: your value-add)
If you've been solicited by "them" to present a proposal, then "they" already know a good deal about "you". Your (very short summary) narrative should reinforce what they already know about your value-add to their need.

But for an unsolicited proposal, "you" need an opening narrative to introduce and present your value as though you were addressing a stranger. In other words: "Why me?"

Think of this opening narrative as your "elevator speech" ... 30 seconds to set an "anchor" and make yourself "available". Typically, a headline to grab attention and then cover letter or some other means to establish your credibility - in effect, your bona fides.

You're working two biases: "Availability bias" There's value in the fact that you're here and now, so no need to look further. And "anchor bias", your "ah hah!" value hooks them on your offer.

And, in many instances, "you" may be a partnership of literally "you" and others that make up your "team" or partnership. Such makes the introduction and "why me" statement all the more complex, but perhaps all the more compelling.

Them
"Them" are your customer. What they want to know is ... What's in it for them? It's your value-add from their point of view. 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 (sans boilerplate)
Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

But focus may be a tricky thing: "They" may want a product, or a service, or product + services. They may want the product, a data package about the product for support purposes, training on operations and maintenance, a warranty, or service-after-sale. 

How does their sense value apportion among all these needs? In a competitive situation, "they" will usually signal their priorities through a list of evaluation criteria for selecting the winner. These criteria should give you guidance about where does the main focus needs to be. 

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

Can you answer this question? Do they go for "best value" or "lowest cost"? If you're not the low-cost provider, then your job is to convince them that your price premium brings unpriced value.

But, if you are addressing government offices, non-profit NGOs, self-help and self-improvement, and other opportunities not oriented to financial gain, then look to the other elements of the "balanced scorecard"(*), the customer's mission and strategic objectives, and of course the evaluation criteria for where you can add value.

Emotions
All that hard evidence gives them a reason to make the decision to accept your proposal. But it may not motivate them to do so. For that, you need to tap into their emotions and biases.

Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... 
Exploit the biases of "availability" and "anchoring" to your idea.

Clayton's opinion: 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. .

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 unless they've asked for 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'.

One thing: If they have provided a proposal outline to follow, page limits, drawing or illustration or image specifications, and overall format, then don't experiment. Make it easy for them to think highly of you for making it easy for them because they can directly use your proposal materials. There is almost nothing worse than making them reformat or search for content when they told you explicitly what to do

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(s) you know to be your "Red Team". You invested all that time. Now add a little more investment, to avoid throwing it all away!

What does a "Red Team" do?
  • Working from your perspective, they are editors, fact checkers, and readers for both content and flow
  • Working from your customer's perspective, they are challengers to your solution, and they are challengers to whether you've checked all the boxes and met all the requirements of a specified format.
_______________

(*) Balanced Scorecard for a business: Financial, Customer Needs, Operations and Operations Efficiency, and Organizational learning and development



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