Blowing hot and cold on project management

blowAn outstanding overview of project management.

“A possible “meta” approach of the project management field—the unit of analysis—respectful of the various perspectives in existence, while providing an integrative ontological and epistemological framework.”

Conclusion should also be noted: ”
‘Complexity, ambiguity and uncertainty,’ ‘integrative epistemological approach,’
modeling and its underlying bases (N vs. S-Learning, Praxeology), ‘Acting, Knowing and Learning.’ and Theory of Convention seem to form a robust theoretical background to the development and content of any framework aimed at addressing the challenge of value creation in complex, ambiguous, and uncertain environments and situations.”

Complexity has to be recognized and accommodated.

Bredillet, Christophe (2010) Blowing hot and cold on project management.
Project Management Journal, 41(3), pp. 4-20.

http://dx.doi.org/10.1002/pmj.20179

Risk management and project uncertainty

uncertaintyHow can You manage risk if You are not certain? You can’t. But You can focus on uncertainty [1].

Developed further [2], ” in dynamic, uncertain environments, agents must be able to effectively manage their plans during execution” and “learning cannot be planned for in advance”.  A table summarizes the three possible approaches

learning.jpg

“Unk” for unknown

“The right combination of instructionism, learning, and selectionism depends on the urgency of the project[…]Precise rules of when to use which approach are currently unknown. ”

[1] Transforming project risk management into project uncertainty management, Ward and Chapman in the International Journal of Project Management
Volume 21, Issue 2, February 2003
https://doi.org/10.1016/S0263-7863(01)00080-1

[2] On Uncertainty, Ambiguity, and Complexity in Project Management
Michael T. Pich, Christoph H. Loch, Arnoud De Meyer https://doi.org/10.1287/mnsc.48.8.1008.163

Pareto principle in project management

crapAh, the Pareto principle. We know that 80 percent of effort is wasted, as 20 percent of it produces 80 percent of results. Or, simply, 80 percent of everything is crap.

How do we identify the good stuff?

A paper titled Finding Pareto Optimal Front for the Multi-Mode Time, Cost Quality Trade off in Project Scheduling has some interesting math that deserves further examination.

I’m going to look at it when I have the time to enact the math with puppets.  I’ve gotten rusty with formulas and need to write out words instead of looking at the Greek alphabet.

https://panel.waset.org/publication/Finding-Pareto-Optimal-Front-for-the-Multi–Mode-Time,-Cost-Quality-Trade-off-in-Project-Scheduling/9985

Prediction of project outcome – statistics

Prediction of project outcome: The application of statistical methods to earned value management and earned schedule performance indexes https://doi.org/10.1016/j.ijproman.2008.02.009

A widely cited paper outlining an improved Earned Value Management prediction of outcome. Heavy on math, but a good start is to play with the excel file provided by the researchers online http://www.earnedschedule.com/Calculator.shtml

And there’s even a video.

youtube.com/watch?v=Z98FRgyKbNM

 

Halloween special – project failures

Just in time for Halloween, some wonderful project failures through the ages

check+engine

  1. City of New York Time Keeping System, 10x over budget, from 60 million to 600 million.  Fraud suspected. Incompetence clear.
  2. The NHS’ Civilian IT Project. Electronic records for patients, for the whole of UK, rolled out at large scale instead of targeted pilots.
  3. Denver International Airport’s Automated Baggage System 2 billion due to unrealistic hard deadline, underscoping and bad definition of done.
  4. US military Expeditionary Combat Support System. A billion USD, rounded to about two or something insignificant like that.
  5. Thanks to Sweden’s somewhat higher government transparency, we are aware of the failures in IT projects in dental insurance, patent filing and police case management – the royal trifecta, with a cost of about a billion USD total.

 

We might as well stop looking for individual “reasons” for failure. Nepotism, lack of self-awareness, refusal to inspect and adapt and outsourcing are the root cause. But really, no surprises. More than half IT projects fail.

https://www.cio.com/article/3068502/more-than-half-of-it-projects-still-failing.html

Sources

  1. https://cityroom.blogs.nytimes.com/2012/03/14/company-in-citytime-payroll-scandal-to-pay-500-million/?hp
  2. The allways tasty wikipedia IT failures list https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

Influential books on project management -mythical man month

estimate-deadlineGood cooking fakes time. If you are made to wait, it is to
serve you better, and to please you.
MENU OF RESTAURANT ANTOINE. NEW ORLEANS

Quote from

The Mythical Man Month by Frederick Brooks

https://archive.org/details/mythicalmanmonth00fred

Delay is the most wide problem in IT. There are multiple causes.
In 1975, this  book was one of the first to postulate that You cannot “solve an IT problem” 10x faster by throwing 10x more developers at it.

An interesting reaction to the problems presented in the MMM is Atomic design (in interfaces), which gave us React, among other things

https://hackernoon.com/react-and-the-mythical-man-month-5ac12ba91f34

A shorter paper,  No Silver Bullet, is a good way to start with the MMM

No Silver Bullet – Essence and Accident in Software Engineering

https://ieeexplore.ieee.org/document/1663532

Downloadable without registration here: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.315

Successful managers according to Google

Some interesting  if somewhat bland conclusions from the Google manager development program. Great managers have the following traits:

1. They’re good coaches.

2. They empower their team and don’t micro-manage.

3. They express interest in their team members’ success and personal well-being.

4. They productive and results-oriented.

5. They’re good communicators and they listen to the team.

6. They help employees with career development.

7. They have a clear vision and strategy for the team.

8. They have key technical skills that help them advise the team.

 

A cute public facade presented. Note that talking to some Google refugees, I have heard top managers often don’t show support to reporting managers when the project does not deliver metrics from an early start. Quantification culture has some draw-backs. Does it work for google? Some recent employee outrages over sexism and nepotism compensation for “star” figures will have to further translate to major exodus before we can be sure.

See the source article for some ( general as well ) alarm signs for managers.

Source:

https://www.inc.com/marcel-schwantes/the-8-biggest-things-that-google-managers-do-to-su.html

Product based IT

An article in CIO Making the shift to product-based IT

https://www.cio.com/article/3332030/making-the-shift-to-product-based-it.html

Interesting that this is another way of doing agile without calling it agile and without it being agile, i.e. without reaping the totality benefits of Scrum. Some points:

Finding highly skilled product managers is another sticking point. “Product managers have to understand the tech side and the market they’re in,” Rowsell-Jones says. Because of this, product managers typically come from the business side.

A person from the business side does not understand the tech side. In Scrum, this is dealt with the Product Owner being the market expert, prioritizing features developed, while the development team owns the technical aspects, estimation and implementation.

When the DevOps team needs to work at a frenzied pace week in, week out, it gets to become really demanding,” Rowsell-Jones says.“CIOs must keep them fresh, motivated, and take them in and out.”

Scrum postulates that You lose velocity every time You change team members. The goal is not to take people in and out. It’s to have sustainable development, indefinitely.

Interestingly enough, the necessity of mandate, i.e being empowered from the start to lead the project, own the project, and prioritize features, comes up late in the article.

A project sponsor, in PMI parlance, is vital. Someone in the org has to give You the power to make the decisions on two of the three – Time, Budget, Scope ( Features / Quality )

Overall, an incomplete implementation of Scrum presented as news.