Will you be hiring a "AI Digital Agent"?

---

Digital agents are here big time. At the 2025 Davos Economic Forum, the big guys from the industry opined on digital agents. Paraphrasing a bit, here's some of what was said:

• SalesForce.com won't be hiring (net headcount) human coders in 2025. SalesForce is rapidly expanding digital agents in their workforce. They way they talk about them it's almost like they are a digital human. The usual and familiar factors are in play: accurate outcomes from assigned tasks; 24/7 work "shifts"; no fatigue; no family/work balance issues, and so forth.
  
  
• WorkDay.com comes at it a bit differently. They are one of the industry leaders providing humans for all manner of business tasks and projects. They say that they are working now with providing digital agents, though it's a very small part of their business. But, in 10 years time, they predict a much different business where providing digital agents, as though they were humans, fully "trained" and ready for "integration" into the client workforce and workflow will be a big part of their business.  

So how does this work, exactly? 

How is this for a narrative?

You, as project manager, write a "job description" for the digital agent, specifying perhaps an API for your work product. The agent presumably knows how to use your tools so that the agent work product is compatible with the human work product. 

The agent presumably has some kind of "settings" that are configurable such that it (*) can internalize milestones and scope, and understand points of integration with other objects. Presumably the agent can work in multiple environments, such as development, integration and test, beta, and final release.

And what if humans fall behind, or less likely: speed ahead? Can the digital agent adjust? And what if the human product has bugs (never happens!)? Can the agent work around them, or does the agent just go in and fix the bugs as a matter or routine scope?

And are there heterogeneous agent environments, where the agents come from different suppliers? Or is it required that all agents on on project be homogeneous: that is all, of one "brand" or "architecture"?

And finally, how does the agent acquire the culture of the human organization such that its product reflects accurately the business, particularly customer facing apps, like the fast-food drive-in order-taker agent?

Over time, all this will sort itself out, but for now, we are on the cusp of a radical change in the workforce typically thought of as the white collar force. 

The business case

And finally there's the business plan or business case: Hiring and training a new graduate is expensive; hiring someone with experience is even more expensive. 

• What does a comparable agent cost? 
• Over 5 years, what's the cost of the human vs the agent? 
• Over 5 years, what's the value of the outcome from each? 
• Is there an RoI argument that is pan-enterprise and larger than the project expense statement?
• I imagine there are lots of finance and business managers going over this as we write.

________________

(*) Is "it" the pronoun for agents? I can foresee "she" and "he", like ships are "she", etc.

---

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

Layoff in the middle of a project?

---

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!

Management v Engineer

---

A balloonist was lost. 

He descended to just 30' above the ground where he spotted a lady below

"Can you tell me where I am?" he called out.

She responded: "Your altitude is 30' above ground; your latitude is 28.538 north; your longitude is 81.378 west" 

The balloonist said: "You must be an engineer!"

She responded: "Yes, how did you know?"

He said: "You have given me facts, but no information that is useful for me. You haven't helped me at all, and I'm still lost!"

She responded: "You must be in management!"

He said: "Yes, how did you know?"

She responded: "You have all the facts, but still you say you're lost and can not help yourself. You have positioned yourself above me, and me below you, only now you say it's my fault!"

Anonymous

---

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

Being in the workforce

---

I cannot express to you how much you need to become all of these if you want to be employed / employable going forward.

• Thinker / Creator
• Product Manager
• Developer (AI Augmented, of course)
• Sales / Marketing expert (AI Augmented, of course)

These are all merging. It’s all one thing.
It’s just called being in the workforce.
You have to be able to come up with ideas, implement them, and then get them to market. Full stop.
This is the work side of Human 3.0.

Daniel Miessler

---

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

Emergent methodologies

---

The influence of A.I. on project methodologies and process steps is yet to be defined, practised widely, and understood in the context of what most of think of when we think of project methods and processes, skills, risks, and predictable and planned outcomes .

And so, we are told to brace for emergent outcomes, not entirely predictable at the outset. And we are told to adapt our leadership and management skills to this reality (or reality in-waiting)

With that all in mind, I asked chatGPT to opine on emergent methods. Here is what it gave me back:

In the context of project management, "emergence" or "emergent methods" refers to the phenomenon where complex and unpredictable outcomes arise from the interactions and dynamics of various elements within a project. Instead of relying solely on predetermined plans and rigid processes, emergent methods embrace adaptability, flexibility, and the ability to respond to changing circumstances.

Traditionally, project management has followed a linear or sequential approach, where all tasks and dependencies are predetermined in a detailed project plan. However, this approach can be limiting when faced with uncertain and dynamic environments. Emergent methods offer an alternative perspective by acknowledging that projects are often complex, and the future is uncertain.

In emergent methods, project managers adopt a more iterative and adaptive approach, focusing on continuous learning and improvement throughout the project lifecycle. Rather than trying to predict and control every aspect of the project from the outset, emergent methods encourage exploration, experimentation, and the ability to adjust the project's direction based on real-time feedback and insights.

Key characteristics of emergent methods in project management include:

Iterative Planning: Instead of creating a rigid and detailed plan at the beginning of the project, emergent methods emphasize iterative planning. This involves developing a broad roadmap and refining it in smaller increments as the project progresses and new information becomes available.

Continuous Learning and Adaptation: Emergent methods embrace the concept of learning as you go. Project teams gather feedback and data throughout the project's execution, allowing them to adapt their strategies and make informed decisions based on evolving conditions and requirements.

Flexibility and Agility: Emergent methods prioritize flexibility and agility to respond to changing circumstances. This may involve adjusting project scope, reallocating resources, or modifying project objectives based on emerging needs or unforeseen challenges.

Empowered Teams and Collaboration: Emergent methods emphasize empowering project teams to make decisions and encouraging collaboration. By promoting open communication and fostering a culture of trust, teams can respond effectively to emerging issues and capitalize on opportunities.

Embracing Uncertainty: Unlike traditional project management approaches that attempt to eliminate uncertainty, emergent methods recognize that uncertainty is inherent in complex projects. Instead of resisting it, these methods embrace uncertainty and focus on building resilience and adaptive capacity.

Emergent Leadership: In emergent methods, project managers adopt a leadership style that is more facilitative and empowering. They create an environment where team members can contribute their expertise and collectively make decisions to address emergent challenges.

By adopting emergent methods, project managers can better navigate complex and unpredictable projects, promote innovation and creativity, and increase the chances of project success in dynamic environments. However, it's important to note that emergent methods are not suitable for all projects and may require a shift in mindset and organizational culture to be effectively implemented.

---

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

Sinking or sunk?

---

Let's keep the basics in front of us:

• Projects are transformative processes packaged together
• Inputs (cash, people, buildings and tools, overhead like training) are transformed into deliverables that don't remotely look and feel like the inputs
• Deliverables are much more valuable than the sum of the inputs

Too often, the focus of the 'business' is on the inputs being consumed, like cash-flow and resources consumed, whereas the more experienced among us keep an eye on input/output efficiency.

And what do we mean by I/O efficiency?

We mean how well input consumption corresponds to its planned value, and how well the corresponding outputs conform to (planned) expectations, when each is sampled--measured--observed in the same time period.

What about sinking and sunk?

Once the project grabs input and consumes it, that input is "sunk", and can't be changed or refunded

Most of us are familiar with the first law of 'sunk' resources: 'Don't use the sunk resource to make a decision about a sinking project". 

Those focused on the sunk resources are focused on inputs rather than outcomes; are focused on the rearview mirror rather than the windshield, and may not understand the opportunity for adjustments.

That is: the future of your project--if it has one--should stand on its own merits re how resources will be used in the future, not so much how they were used in the past.

Why this first law?

Because at the moment you are challenged--even a self-challenge--to justify your future by citing the past, that is the time to root cause analyze the efficiencies. Depending on the analysis, you will have an opportunity to make decisions to alter the likely future efficiencies, and you have the opportunity to 're-baseline'

The future may not "wash-rinse-repeat" what has already been sunk.

---

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

System Integrator -- Owner Rep roles

---

In the government domain, the government often contracts for an SI -- system integrator -- whose scope of work is to be an independent evaluator of program plans and progress, an expert adviser to the program executive for risk management and value engineering, and a voice in the project office not beholden to the prime contractor(s), system architect(s), or other implementers. 

In large programs, the SI may work simultaneously with multiple prime contractors, overseeing their coordination, communications, consistency in approach, integration of scope, and guarding for "white space" gaps. The SI may even evaluate the integrated program for 'chaos' ... the unintended outcomes of an integrated 'whole'. 

In some limited situations, the SI may even develop an interface that seems tagged to white space.

In the commercial domain, a similar scope and role is often given to an "owner's representative". 

Necessary or Nice to Have?

Your first thought may be: Another scope of work .... do I really need this for project success? If I don't engage with a service provider for this scope, is this something I am going to have to learn how to do myself, and then allocate my resources to the task? Or, can I get by without it?

Quick answer: It's work that has to be done ... to some level of scope ... so either the PEO or PMO does it with in-house resources, or the PEO/PMO engages an SI who is expert in the scope and presumably not learning on the job on your nickel.

And, by the way, if you do engage with an independent SI, then cooperation with the SI on the part of your architect, prime contractor, and perhaps other stakeholders has to be made part of the Statement of Work (SoW) with those parties. Question worth asking: Does that cooperation come at a cost, monetized or functional?

What's the ROI on the SI engagement

So, whether you are a government program office or a business unit with a large capital project, what's the value-add of having an SI or owner's rep on the scene? Is there a monetized ROI to the cost of a SI, or is the advantage with a DIY model (do it yourself)?  

In many respects, it's the insurance model: High impact with low probability, to take a square from the risk matrix. Thus, a low expected value, but nonetheless the impact is judged unaffordable. 

The usual risk management doctrine is this: You've got a big (big!) project with a lot of moving parts (different contractors doing different stuff). Get yourself an SI! (At a cost which is usually a small multiple of the expected value, if you think of it in terms of insurance)

SI Scope

The SI is on alert for these 'black swan' impacts that could derail the program, extend the schedule, impact performance, or cost big bucks for rework. 

The SI comes on the job early, typically from Day-1, working down the project definition side of the "V" chart (see chart below)

The SI is an advisor to the PEO or PMO regarding threats to the cost, scope, schedule, or quality. If there are value engineering proposals to be fit into the program, the SI is usually the first to evaluate and advise about their applicability.

The SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

The SI is an independent technical reviewer for the PMO of the progress toward technical and functional performance. The SI may provide much of the data for earned-value analysis.

The SI can be an independent trouble-shooter, but mostly the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

The SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

The SI may be independent integration tester and evaluator, typically moving up the "V" from verification to validation

In a tough situation, the SI may be your new best friend!

What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

---

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