Bloggarkiver

Why do projects fail?

… and how easy is project recovery? Project failure facts and figures are in the eye of the beholder unless the statistics are granulated into a level that explains the exact science behind the numbers. Failure percentages vary from 40 to 80 percent and are, logically and primarily, based on qualitative information gathered through interviews. This percent of failed projects, whether it be 40 or 80, is a tragedy and is an indication that the project management profession as a whole has a lot of work to do in the times to come! But which are the main reasons why projects fail? Through studies of three similar analyses conducted within

Googlehubris

A few weeks ago there was much ado about Google+ and the figures concerning the growth of this service that the CEO of the company, Larry Page, delivered under an earnings conference call on January 19.  After delivering a row of figures that, intentionally or not, were confusing for most of the audience, it is now clear that Google+ had at that time 90 million registered users. The point is precisely the word registered.  Page did´t give concrete figures around the engagement of the users of Google+ and mixed the engagement of all Google services in one big pot.For those like me that have been following Google for a while, this

When Scrum fails

David Andersen used his Meetup talk i Oslo last week to describe a start-up’s journey from Scrum to a more Kanban based way of doing things. I seldom work with start-ups, but David’s talk resonated with my experiences in contexts that have little do do with start-ups. I summarized the insight in a tweet: “The Meetup with @agilemanager yesterday reinforced my belief that Scrum works best when you are in a state that you should avoid being in” I freely admit that as tweets go, this one is pretty cryptic. A lot of people did not understand what I meant. Others stumbled into false logic and thought I was implying

Failure demand in software

A lot of people seem to like John Seddon’s concept of failure demand. Me too. But Seddon mostly talks about service delivery in areas such as call centers and housing repairs. I tend to work with software development organizations. When Seddon mentions IT, it is in the context of how the workflow systems we create end up reducing the quality of service delivery in call centers and housing repairs. After having used a number of different workflow systems over the years I too have come to the conclusion that most of them are counterproductive. But what about software development itself? Can the idea of failure demand be applied to software

When systems(thinkers) collide

When I come across a great thinker that opens my eyes to new ideas I always try to look for errors in their reasoning. The obvious reason to do this is as a safeguard against being carried away by new ideas that are intuitively right but actually wrong. A second reason for this scrutiny is a guiding principle of mine. If I am unable to find anything wrong in someone’s thinking it is a sure sign that I am becoming dogmatic. So when two people I greatly respect started arguing, I saw this as a good thing. Simple logic told me that at least one of them would be wrong

Doing business in Northern Europe

According to Core group’s analysis of the Norwegian IT-software industry, more than 80% of Norwegian software companies are unable to grow beyond a local niche market. We found that most Norwegian software companies lack a global perspective as well as knowledge and capability to grow internationally. There are a number of key factors management should consider before taking an IT-company abroad. We have had a look at current research and interviewed 25 experienced international managers in order to examine some of those factors, specifically country attractiveness. Our findings are documented in the e-book “Doing business in Northern Europe”. There are significant differences in business environment- and market attractiveness between Northern

Service.. as a Service

In the early 1990’s, outsourcing became mainstream. It started with business critical application servers. Businesses didn’t have to have them in their office buildings anymore, but could free up expensive raised floor space and buy a resilient server park from someone else. Then there came desktop outsourcing. You could buy a PC per persona, including an estimated number of help-tickets, printer services and fixes. Then there was application management systems. No need to fix bugs in your applications anymore, since a service level agreement regulated upgrades, bugs and even more functionality. Gradually delivered by resources from other countries. At lower wages. At other shores. Offshoring, rightshoring, smartsourcing. You could pay

Are estimates worthless?

If you take a picture while on vacation, is that picture yours? You are probably thinking: “What a stupid question. Of course it is mine!” But what if a stranger had asked you to take a picture of her with her camera? Is the picture still yours?

5 whys and 3 because

The practice of “5 whys” is a popular lean approach to root cause analysis. It can be overly simplistic in some situations but few people would question the virtue of trying to figure out the real causes of a problem as opposed to just treating the symptoms. You can visualize 5 whys as a timeline where the problem you are trying to solve is (in most cases) a recent event and the sequence of causes and effects that led to this event are points on the timeline behind it. The root cause is often something that is up to 5 points back on the timeline, hence the name…

The second death of agile

The 10 year anniversary of the agile manifesto has just passed. As part of some kind of distributed retrospective, there has been a lot of discussion about what will happen with agile now. I think that agile will be dead in ten years – I just hope it will be a good death. This will actually be the second death of agile, but I need to set some other things in context before describing the first one.