Project Shrink

In my quest to analyze project stakeholders I came across some very interesting observations by Alistair Cockburn in his book Agile Software Development. In the first chapters he doesnt discuss agile, but he is describing characteristics of individuals and groups that, in his opinion, lead to why agile is a good method for certain projects. [...]

There is so much knowledge about software project management available in bookstores, universities, businesses and the internet, if you encounter a problem in your project, chances are the right solution is already invented and waiting for you to find it. Two problems are popping up here: 1) how do you define the problem in your [...]

Most problems in a project occur when the project is actually running. This may seem obvious, but consider the amount of time spent on analyzing the situation and taking measurements to counter potential problems; the majority of this is done at the start of the project. When the project is running on full speed, when [...]

I had some emails from readers who wondered why I coin the term “Project Potion” in my book “Surprise! Now You’re a Software Project Manager”. The origin of the term comes from a blog posting from 18 months ago: I have to work on my self promotion. I am struggling to make some sense of [...]

Here is an interesting point that Lauri Koskela and Greg Howell mention in their article I forgot to mention in my previous posting about the fundamental problems concerning plan-driven methods. The lack of information about how the project plan should actually be performed. For example, the PMBok guide is amazingly brief about this. So, management [...]

For the subject of numbers around software projects Level 4 of the Capability Maturity Model (CMM) is da bomb: software as a Quantitatively Managed process. A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and [...]

One of the subscribers of my newsletter brought one old rule of thumb to my attention (thanks Terry!). I almost forgot this one. It is known as the 1:10:100 Rule: the cost to fix a defect increases exponentially the later in the development lifecycle that it is identified. Photography by Absolutwade. A defect caught in [...]

Most development projects spend effort in creating specifications: functional, technical, detailed, global. Putting the designs in writing takes a lot of work, and it will not be used in the end result; specifications are supporting artifacts. So, the question if specifications are worth the effort is legit. Jeff Sutherland quotes some research in this area [...]

In my previous entry I discussed the underlying theories of plan-driven PM methods (based upon an article from Lauri Koskela and Greg Howell). I ended with the cliffhanger that I would inform you about the problems these theories generate… Tada… on with the show! We have the theory of project, management-as-planning, the dispatch model and [...]

It is amazing how few Project Managers that are trained in a certain method actually know the underlying theories that make up Project Management. Who cares? Whats the use? Well actually, every PM should care. If you know the ideas that are behind a specific method, you will easier learn it, and, more important in [...]