Risk and hope

What science tells us is not that you are guaranteed to die because of smoking. It tells us about an increased risk to get a disease or die because of smoking.
When you deal with risk you also deal with hope. What is true for the average person hasn’t have to be true for a single individual like you.

Why do scientists who know about the risk of smoking smoke ? Especially scientists are probably good in dealing with risks and probabilities.

If you are an optimistic person anyway you always would say: yes, I see the risk, but I will be on the lucky side.

Is that the reason we don’t do risk management in our projects ? Because we prefer to hope than to plan accordingly ? Hoping definitely is cheaper.
It’s kind of gambling. When it comes to smoking, it is kind of gambling  with your life.
I personally wouldn’t do this. I always try to minimize risks, when I can. Well … not always. Otherwise I wouldn’t have done some glacier crossing and climbing on rocky mountains during my last vacation. Well, at least we hired a mountain guide to do so, so we took some risk, but then worked on minimizing it.

That picture doesn’t show me, but our mountain guide. Anyway, I had to go the same way.
You actually always take risks. Your entire life is risky, more or less. Even if you stay at home. Most people die there.
But it is easy for me when it comes to smoking: I never figured out what people like about this and never had any interest in smoking. Except may be a water pipe once or twice a year after a diner in my garden.


Kanban in project management

Yesterday I consumed another of the 1-hour-replays of a project management education session I have to go through in order to gain my PMI re-certification in 2016 ( 60 hours of education are required to get re-certified ).

"" by Jim Downing.

This was about the use of Kanban in project management and I found this quiet remarkable.
Kanban – originally invented for manufacturing processes and based on the "pull" principle – can also nicely be used in project management and I guess works best for agile projects. "Pull" principle here means that team members ( analogy to manufacturing operations ) pull work into their working queue from the predecessor rather than getting work pushed into it. That way, and by implementing some rules like Work In Process limits, the project team ( analogy to manufacturing line ) can be better balanced. The "bottleneck" controls how much work can be done overall while avoiding unnecessary Work In Progress queue’s created somewhere else which are usually causing costly non-value-add overhead and the risk of producing too many defective or out-dated work products.
The wikipedia article ( link posted above ) about Kanban in project management has a nice example of a dashboard visualizing user stories and where they are in the project flow. With such a dashboard ( can be a physical white board for a collocated team, or a piece of software supporting collaboration of remote teams, like Apollo Agile PM or KanbanFlow ) it is easy to keep track of the project and see where resources ( aka people ) are missing and what the status of particular user stories is. Swim lanes can be used to keep track of user stories by feature, or to introduce high priority of fire lanes. Also besides user stories defects can be tracked as well – may be using a different color like red of the Kanban cards.

The Servant Leader

Yesterday I consumed one of the 1-hour-replays of a project management education session I have to go through in order to gain my PMI re-certification in 2016 ( 60 hours of education are required to get re-certified ).
It was about the concept of the "Servant Leader" and I found that concept quiet astonishing. Many think of a leader as the one who has people working for him in order to accomplish a mission. According to the nice quote by Dwight Eisenhower:

"Leadership is the art of getting someone else to do something you want done because he wants to do it."

The concept of the "Servant Leader" actually changes the point of view: leadership as a service, so to speak. The leader servers the team to accomplish something. She enables and empowers the team to get the job done. He identifies barriers and moves those away. He coaches and educates and ensures things are moving into the right direction.
Brilliant concept, in my opinion. My current team lead is actually doing a quiet good job with this.
How about you ? Have you ever met a Servant Leader ?

"Go slow now so you can go faster later"

Currently I am listening to a replay of a presentation about Project Risk Management by Frank Saladis having this quote on one of its slides: "Go slow now so you can go faster later". It reminds me of another quote I once heard from one of my mountain guides when going on some hiking tour: "The one who goes slow goes far."
Doing project management right means to have sort of a slow start since you need to do some planning and preparation upfront before you actually start execution of the project and creating the deliverables customers of your project asked for.
This means that for some period of time you do not work directly on those deliverables, you more work on plans and documents and processes and setting things up for the project. This exactly is the reason why projects are not managed well in an environment lead by people who do not understand the value of project management. When they see you doing your planning and all that stuff they quickly get real nervous and impatient and come up with questions like: "when will you start writing code for me ?"
A project manager needs to deal with that impatience, otherwise he or she won’t be able to do the job as project manager at all and what was supposed to be a project quickly turns into an adventure.
There is another nice saying about project management. There are two ways to do a project: plan and execute, or: execute, fail, plan and execute.

About Work Breakdown Structures …

WBS in Project Management stands for "Work Breakdown Structure". This professional sounding term simply describes what should be common sense when planning a project: think about what needs to be done !
I have been reading a statement by a project manager recently saying that deliverables are more important than activities. And: beware of too much detail when planing and micro-management.
While I would agree that deliverables are more important than "how" you create those (a fundamential statement in the Agile Manifesto: "Working software over comprehensive documentation") I also would say that a project manager actually needs to worry about the "How" – at least to some extent. The art of project planning of course always is to choose the right level of detail.
A WBS itself actually focuses on the "how": that’s why it is called W ( "Work" ) Breakdown Structure. A WBS should describe the tasks and activities to accomplish something. I also agree: beware of too much detail ! But this is true as well: beware of too less detail. I simply have seen too many projects starting where almost nothing has been planned.
To describe deliverables ( and that’s probably the first thing you do in an early phase of the project planning when you identify the components to build ) a P ("Product" ) Breakdown Structure (PBS) should be used. Once you know the components you might want to go into some detail to describe the tasks needed to create those components ( deliverables ). Deliverables of course also can be features of components ( thus a level deeper in the PBS ).
PBS and WBS can be combined: you would have components and features on the higher levels and tasks defined with a reasonable amount of detail on lower levels.
If later on you have transformed your overall WBS to a gantt chart this would give you the benefit to see the progress for components and features in a high level status report.
Mindmapping by the way is a great technique to initially create a PBS and then add the WBS – hopefully with involvement of as many team members as possible.

Lessons Learned: Players change too often

Originally posted in my company blog on February 2006:

Today I had the opportunity to read a lessons learned document about a customer project I have been involved with as a business analyst last year. The project has been closed and overall has not been very successful in terms of customer satisfaction and future engagement. Our project manager did a great job in documenting all these lessons and he obviously did not hesitate to name all the root causes.
It was frightning for me to see how many of these lessons had something to do with people changing or leaving: key players supporting the project changed, critical skill went away, people retired and have not been replaced.
Our business environment is very dynamic if not to say chaotic nowadays and suffering under an extreme cost savings attitude. This is no news for anybody and it does not help us crying about it. But we should face the impacts. And the impact is that is hurts our business and our capabilities to reach our goals dramatically, not to talk about the quality of our deliverables.
Yesterday I had to review another project and I saw similar symptoms like I have them with my own project: teams do not stabilize, people are going in and out permanently. Why ? Because we are constraint on resources and need to fill gaps at some place by opening gaps somewhere else. This also leads to the necessity of "multi-tasking" for all of us, a topic I discussed with several folks here recently and from which I believe it reduces our productivity as well. There is almost no way today to build a team and get it settled and increase its productivity. From high level management point of view replacing a programmer (or any other type of expert) in a project does not seem to be a big deal. A programmer is a programmer and writes that many lines of code per day. Period. But in reality, somewhere down there where projects actually take place you see that each programmer is an individual with own ideas, own working and communication style, own skills and relationships to others and exchanging a programmer in a project team usually has a real big impact. There is a very true saying about project management: "Adding man power to a late project makes it later". This is true because of the time needed by the newcomer to become familiar with the project and all information associated with it, because of all the extra communication effort and because of the effort of other team members to get him on board.

My favorites for week 43, 2010

Big GrinSomething to laugh: my favorite comic strip of the weekabout project plans

Project plans should not be “sold”, they should be discussed. I remember when I had to “sell” my first project plan to my customer. I came up with an end date far later then he had been hoping for and when I threw that on the wall we right away have been in the middle of the discussion how to handle that and finally came up with a working compromise and thus project plan ( we reduced the scope a bit and moved a few items not critical for the magical target date of my customer to later period of time ). As I said: project plans should not be sold, they should be discussed and crafted to create a solid plan instead of a promise full of false hopes. Thanks, Dilbert, for bringing that up …


ApplauseSomething to learn: my favorite tip of the weekabout changing directories in linux

You probably knew that just typing “cd” into a linux command prompt takes you to your home directory. But like me you probably did not know that typing in “cd –“ takes you back to the directory where you have been before. Now you know, thanks to Lifehacker and/or reading my blog.

Cool Something to discover: my favorite bookmark of the weekabout HTTP 404 Error Pages
HTTP 404 Error Pages are annoying, everyone certainly hates it to bump into those. In case you have no idea what I am talking about: HTTP (Return Code) 404 stands for “Page not found”. I noticed that the older the bookmarks are I try to re-use from my collection of bookmarks in Lotus Connections Bookmarks or delicious the better are my chances to bump into a HTTP 404 page. This is certainly a symptom of knowledge loss, don’t you think ? A world wide Alzheimer of internet-based human beings, so to speak. Modern documents are hypertext documents, that means they are based on links to other documents. Over time they become more and more fragmentary. We end up with tons of documents becoming incomplete and often almost unusable. Our old way to document our knowledge actually had been much more reliable, if you think about books, which last at least for a hundred years, or crafting words into stone, which were lasting for many centuries.
Nothing is more frustrating if you thought you finally found what you have been searching for and then bump into one of those ordinary HTTP 404 Error Messages. Some web server designer have thought about that dilemma and probably have not been able to fix it, but at least came up with a way to make it a bit easier for the user to accept the dilemma. A nicely designed HTTP 404 Page can get you some comfort while facing that problem, right ? Here is a collection of nice HTTP 404 Pages which might make your day and probably make you stay on that particular web server a bit longer, even it failed initially to get you the information you have been looking for.

  Something to enjoy: my favorite photo  on flickr under a Common Creative licenseabout Homer Simpson and Copyright

"Homer" by Thomas Hawk.

Since I posted a screen shot featuring Homer Simpson above this one from Thomas Hawk might be a good fit here for this blog posting.

At this point I start wondering how licensing and copyright works if someone takes a photo of lets say a painting, a logo, a photo from another photographer, or a merchandising product, and publishes this under a Creative Commons license for instance, thus allowing to share this material. If there is a copyright on the object he or she photographed, which now is the valid license to consider ?

I am glad I am no lawyer in these days. Currently I am involved in preparation work to license a piece of software we have developed to a customer. One part of it is determining the Country Of Origin, which requires to identify and assess all the components used to craft this software. We have probably a dozen or more open source components in there plus a few more which are either commercial somehow or have an undetermined status. This – I can tell you – is a real bureaucratic nightmare !

Something to talk about: my favorite quote of the weekabout leadership

If you’re a leader, you don’t push wet spaghetti, you pull it.

I’d say: “If you are a leader you don’t push wet spaghetti, you delegate how to move spaghetti around”. And leave it up to your underlings how to do it best.  Or do you suck at delegating ? Then this Lifehacker article might help: “Why I Suck at Delegating (and You Might, Too)”. And don’t micro-mange ! If they want to push the spaghetti, let them push it ! “Delegate Effectively by Skipping the How-To Session” ( another Lifehacker article this is ).