Category Archives: project management

Halloween special – project failures

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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.