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 ).
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
) 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.
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 ?
Today I have been looking for a function in OpenOffice which I would call ( and know from many programming languages ) ‘substring’ and which would allow me to split a string into chunks using a pre-defined delimiter and then return one or more words from this collection of chunks. Did I explain this well ? If not, here is an example: from a string like ‘+ 6.84%’ I just need the numeric part, the 6.84 so to speak – to then be able to convert that to a number.
Unfortunately such a function is not offered with OpenOffice. Or should I say … fortunately ? Because I actually started to figure out how to write my own functions in OpenOffice using Visual Basic For Applications, aka VBA. And at the end of the day I know how to do this and probably write many more functions in the future.
Here is my substring function in VBA:
Function substring(str As String, start As Integer, optional n As Integer, optional delim As String) As String
If isMissing(n) Then
n = 1
If isMissing(delim) Then
delim = " "
out_str = ""
cnt = 0
Dim arr() as String
arr = Split(str,delim)
For i = 0 to UBound(arr)
If (i+1) >= start Then
If arr(i) <> "" Then
cnt = cnt + 1 ' Ignore empty values
if cnt <= n Then
if cnt = n Then
delim = "" ' no more delimiter needed at the end
out_str = out_str & arr(i) & delim
substring = out_str
As you probably can see it takes a string and a starting position as parameter 1 and 2, the number of words to return and the delimiter to use as optional parameter 3 and 4. Parameter 3 will be 1 as default, parameter 4 a white space, if not specified.
Here is an example how I now can use this function to do my data tweaking together with two of the built-in functions SUBSTITUTE and VALUE to finally achieve what I described above:
would get me 6,84 in numeric format if cell A1 contains ‘+ 6.84%’.
So far, so good. How to get such a function into OpenOffice Calc ?
It starts with navigating to the Macro Organizer: Tools –> Macros –> Organize Macros –> OpenOffice.org Basic
From here I select “My Macros” –> “Standard” –> “Module1” and then click the Edit button. An IDE for VBA opens allowing me to paste in the code I have shown above. Done.
That IDE is quiet useful since it also allows me to do debugging, like setting breakpoints and inspecting the content of variables.
The series of project management lessons learned continues. This lesson is
from the Project Planing Phase of one of my projects.
If running into unresolved over-allocations during resource leveling try the
- Level entire project and clear previous leveling
- Continue leveling unresolved resources only without clearing previous
leveling! It might be necessary to repeat this step several times until all
over-allocations are resolved.
I have tried these things using MS Project, the only project management tool
I know so far supporting automatic resource leveling.
Of course there are situations causing resource over-allocations which can
not be resolved no matter how much you try to move tasks around. One is: a
resource has been assigned to a task with a higher Unit (percentage) than being
available in the time frame available to schedule this task. For example if a
resource is available only on 50 % base throughout the entire duration of the
project any task using that resource more than 50 % will cause an unresolved
What else can cause an unresolved over-allocation ? Any comments are welcome.
Lifehacker started an interesting discussion thread some weeks ago: “What Is the Worst Current Software Trend?”. It is worth to read through all the comments. Let me try to summarize the important points mentioned by at least two or more:
- Bloat, of course. Why do some programs use their own UI rather than the one built into the OS ? Why do some software packages install support for 160 languages I am never going to use ? Why do I need to install another multi-megabyte driver to run my simple three-button mouse ?
- Major re-designs, like the ribbon in MS applications like MS office ( I hate it too and the first thing I did was installing a freeware plug-in to get back the old menus; I got tired to always have to search for basic functions ), the Firefox 4 design change ( I was happy with the way FF 3 worked; why did they try to become Chrome ? ), web pages more and more becoming apps, thus violating the Form-follows-Function principle
- Auto-updating software
- Under-the-cover data collection or other activities like killing other apps
- Expensive licensing ( have to re-pay for new versions coming up again and again ), DRM
- Compatibility issues ( why do I always have to find someone with a MS Office 2007 license to save a document I need in the right format so that I can use it ? )
- Social software integration and feedbacking everywhere
If you think for yourself, what is the worst trend you spot in today’s software ?
Change is everywhere and permanent in our innovation driven world. Change is seen as a vital part of our business and a true sign of success and progress.
“Players change too often” has been a project management lesson learned I blogged about more than 3 years ago where I described how many projects suffer under the permanent change of players. In the discussion thread created by this blog post it became clear that change has pro’s and con’s and that the problem usually is that it simply is not handled right.
To my mind one way to recognize a good restaurant is that when you come back after a long time still the same people are working there. We have such a restaurant in the village where I live and since more than a decade I see the same waiters there when we go there for dinner. They deliver the same excellent service we are used to get there, we know each other and can have some more conversation than just ordering drinks and food. When I see them it gives me as a customer a warm feeling and confidence that this enterprise still works as it was used to be and delivers the same good service. It is a sign to me that people working there are happy with their employer and that the restaurant owner is still happy with them – thus everything is in order with this place.
The long Easter weekend in 2009 with an excellent weather forecast my wife and I used to do some more hiking along the famous Rheinsteig trail between Wiesbaden and Bonn. Yesterday we hiked from Lorch to Assmannshausen and after we arrived there we went to the same restaurant we visit every time we come to this little village located at the river Rhine – which is may be once every second year. It is ideally located in the center of the village with a nice winter garden to sit in and offers great food and drinks – and an excellent and friendly service. Of course prizes are a little higher than somewhere else but their service is worth the extra money.
“This waiter has been working here two years ago when we have been here last time”, my wife remarked while we were having lunch. And she was right – and the idea to this blog post was born.
May be this perception is subjective since you probably easier remember people who have given an excellent service to you than those you want to forget quickly. But since I have made this type of observation at some places I like to visit because of there good service I believe that one symptom of a healthy and successful enterprise is that it is able to retain their staff and to ensure they continue to deliver the same good service over a long period of time.
Today (this blog posting has been originally published in my internal IBM blog more than 4.5 years ago, in February 2006) 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 frightening 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 wrote about here some time ago 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.
* Habe nun, ach! Philosophie, Juristerei und Medizin, Und leider auch Theologie Durchaus studiert, mit heißem Bemühn. Da steh ich nun, ich armer Tor! Und bin so klug als wie zuvor;
Well, that's Philosophy I've read, And Law and Medicine, and I fear Theology, too, from A to Z; Hard studies all, that have cost me dear. And so I sit, poor silly man No wiser now than when I began.
Wow, you can’t win that game, can you ? You can become smarter, but never smart. With every question you answer you get a whole bunch of new ones. With every piece of knowledge you start discovering you also discover tens and hundreds more waiting for you to be discovered.
Goethe’s Faust already said it: “I know that I know nothing!”. The more you learn the more you know how true this is. And since in these fast changing times your learning pace might never be good enough to catch up with new knowledge you are always behind, aren’t you ? A single man never can catch up with knowledge “produced” by millions and billions of people.
What will be your realistic option ? You probably will only consider the few ( one ;-) ) framework you know about and pick it. You won’t have the time nor the resources to dig deeper into knowledge available and start your project smart with the optimal decision and best framework you could get for your project. You will start it in a sub-optimal and semi-smart way, won’t you ? And you and the project will suffer because of this for the remaining duration of the project and longer, for the life time of whatever your project is putting into existence.
While this might sound a bit negative it is the natural way projects go, the way of business and life. Knowledge is changing all the time and there is never such a thing than an absolute true statement or a best answer to a given question. You always start with compromises, weaknesses and problems-. You might fix some of those later on, may be as part of your project, and this will be the root of more change to come. The cycle of change so to speak, and the reason why project managers and engineers and scientists and experts will always be busy with what they do. We will never sit back and say: “Done!”. The day this happens might be the end of everything.
Before we developed our capability to use languages – to talk and listen by using an agreed upon vocabulary - there was probably no way to have some form of complex communication. Before paper and writing had been discovered there was simply one option: talk to someone face-to-face. After that one could decide whether to write a letter or meet someone to talk to probably after a multi day or week travel. And we rarely had the idea to communicate with people on a different continent.
The phone invented more than 100 years ago opened up a third option and a real revolutionary one. Ten years ago many options had been added meanwhile, according to this 10-year-old article: audio tapes, video tapes, CD-ROMs, radio, fax, internet, e-mail, TV, video conferencing. What is meant by “internet” ? Well, remember, that was the Web 1.0 era, where a few could publish their messages through internet sites. Instant messaging and newsgroups are not mentioned as well but I guess have been available already to some extent, may be still too exotic in these days.
While reading through this list I realize how many options have been added meanwhile in the Web 2.0 era: blogs, wikis, photo and video and audio ( podcasts ) sharing sites, profile and social networking sites, bookmark sharing and survey sites, twitter, Q&A tools and collaborative document sharing sites. I believe: we experience a sort of exponential growth in the number of communication options.
This means that we have to invest some of our time in finding the right communication tool for a given purpose. Face-to-face, instant message, e-mail, comment on a profile page, blog post, wiki page, a document sent via e-mail or shared in any other way, a tweet, a phone call, a video conference, a meeting in a virtual world ? And for each option we have to find out: company internal or public ? Within the boundaries of an intranet or going out into the wild wild web ?
Businesses are constantly adding new communication options, but they very rarely take any away. It’s also rare for them to provide any guidance to their employees to help them sort through the options.
Will this actually lead to a smarter society, will this increase the body of knowledge of the human race or a particular community or enterprise, or are we more and more running into confusion how to use all these options right, how to communicate efficiently ? Are we encountering a new Tower of Babel phenomenon ?
Instead of becoming smarter, don’t we spent much time on trying to consolidate all these sources of information and to worry about how to use what communication vehicle efficiently ? Is there any value add in developing tools to feed or integrate multiple communication tools ? Is it good to have multiple social networks which are different ? Isn’t it more good luck than intention to find some useful information ? How much time do we spend each day to learn new communication tools and communicate about communication tools instead of focusing on something more important ? is there anything more important ? Why do we fail to take options away, to consolidate and to reduce complexity ? Is the human race or an enterprise as a collective unit intelligent, are its individuals, and where are we heading with this ? What dominates in our life: competition or collaboration ?
Am I getting too far with my questions ? Definitely yes. I will need to write some more postings to really sort out this brain dump.
The series of lessons learned from my project continues. This lesson is from the Project Planning Phase.
For Qualification/Testing do not model "Fixing" as an extra task. It will be impossible to keep "Testing" and "Fixing" tasks together when scheduling/resource leveling the project. Instead add "fixing" effort and resource to "Testing" task.
This is a problem specific to software development projects or any project requiring some testing. Towards the end of the project software produced is supposed to be tested and debugged if needed.  That means a tester needs to work on running the test cases and a developer has to be available in parallel to remove bugs from the code discovered by the tester.
First I modeled "Testing" and "Fixing" as separate tasks in my MS Project Plan. I thought I might tie them together using a Finish-To-Finish relationship but this of course does not really mean those tasks stay together on the time line after doing a resource leveling.
Instead modeling "Testing/Fixing" as one task in the project plan seem to be a more practical approach. I assigned both resources to this task ( tester 100 % and developer 50 % ). The 50% might be an optimistic assumption and is certainly depending on the quality of the software design and coding. It could be actually 200 % if the developer has to spend twice as much effort on removing bugs than the tester needs to discover them.
 As I am re-publishing my lessons learned from my internal blog here in this new blog I realize how much I always have argued from the point of view of a project manager managing a classic project more or less following the waterfall model. In an Agile or especially Test Driven project testing would occur all the time during any phase of the project.
The series of lessons learned from my projects continues. This lesson is from the Project Initiation Phase.
Be more realistic when writing down a "try for" schedule in the project charter. Schedule after initial project plan completion showed that project duration would be almost 5 quarters of a year instead of 2 – as originally mentioned in the project charter.
I think the same observations regarding optimism before the project starts and some more pessimism ( or realism ) coming up once the project actually is started - as mentioned for lesson #4 already - apply here as well.
A project charter is a document created quiet early in the life cycle of a project, typically even before the project even has been started – including any detailed planning efforts. Thus I actually doubt whether it is wise to even mention a try-for schedule at that time. But of course I know that this might be the first question an executive is going to ask: how long will it take you ?
A project charter is a document to “sell” a project and obtain approval to start it. In that sense it is simply natural that a lot of optimism flows into whatever is written in a project charter.
There is a saying about this ...
Brasington's Ninth Law: A carelessly planned project takes three times longer to complete than expected; a carefully planned one will take only twice as long.
Looks like my project lies somewhere in between.
The series of lessons learned from my projects continues. This lesson is from the Project Initiation Phase.
Be more realistic when doing the business case. In one of my projects the initial business case
showed less than 50 % of the cost compared to the cost plan becoming available after
project planning had been done. It is known that "a project in the
initiation phase could have a rough order of magnitude (ROM) estimate
in the range of -50 to +100%" ( PMBOK 2004, 7.1, page 161 ), however at
least this ROM should be indicated in the business case.
We have to be honest here: when doing a business case usually we are
already convinced about the project goal and objectives and want to get
the project started. So being optimistic at that time is a natural
behavior. As soon as the project is started we start worrying about
and planing the details and while facing all the detailed challenges
coming up our optimism turns a liitle bit into pessimism - or let's say: realism. We start
building contingency into our sizings to deal with all the unknowns and
we try to get a more and more realistic sizing considering really
everything what needs to be done.
This usually will create a sizing after project planing phase
which is higher than what we saw when doing the business case. Actually the ROM mentioned above typically is in the range of 0 to
+100% instead of -50 to +100%. Or did anybody ever see a business case
showing less cost than actually was needed later on ?
No surprise here, I would think. It's sometimes just amazing to write down obvious things.
The series of lessons learned from my projects continues:
Careful requirements gathering, specification and design creates problem that programmer are not fully utilized from beginning of project.
It might not make sense to assign programmers to a project during requirements gathering and design phase. Of course it might make sense to have them joining a requirements workshop so they better know the customer and understand the scope of the project. But what then ? If it takes 4 more weeks to finalize requirements those programmers are hanging around with nothing to do. Either they complain about this or they start coding based on not finalized specifications or they run away to another project.
On one side it is good practice to get the team together at the beginning ( see my lesson # 1 on this project ). On the other side it creates the problem that programmers might not be utilized during the next weeks of the project. This is hard to manage for their manager, for themselves, and the project manager. Hard for their manager because he is having a problem now what work to assign to the programmer during the time he is not needed for the project. Hard for the programmer herself since she has been notified that the project has started, may be got excited about the project and would like to start right away instead of waiting until everything is clearly defined. Hard for the project manager because she likes to avoid having an unhappy functional manager or programmer to deal with.
In our organization we prefer to charge a monthly rate for a pre-defined time frame. DOUs and actual $ transfer are easier to organize like this. This unfortunately is in conflict with the fact that a project plan creates an "unbalanced" utilization for a person over time. In other organizations team members might be charged based on actual claims in some work hour tracking system, but this does not really solve the problem that they would be either under-utilized during the requirement gathering period or would may be start to work on different projects and thus become unavailable when they would be needed for this project.
Of course this problem does not apply to programmers only. It applies to all special skill team members who are not evenly utilized throughout the project duration.
I also realize this problem is related to what I described in my lesson # 2: if you actually did not plan sufficiently for the requirements gathering time frame than this problem becomes worse. But even if you planned for it you have to come up with solutions what to do with your specialists for periods of time when they are not needed. And these periods of time exist if you try to manage your project in an organized way.
For programmers and developers it could mean: use the time for training, use the time to make yourself familiar with the technology going to be used for the project ( valid concern here: what if the high level design and the architecture have not been created yet ? How could they if the requirements have not been gathered completely yet ? ), use the time to try out new technologies and come up with some prototypes.
There is probably no silver bullet to get rid of the problem. If the requirements gathering period takes too long there is a good chance that your developers start doing something else and suddenly are gone. This might be a sweet reason to go Agile: do small iterations, focus on specifying small portions of work load for the next 4 weeks and have the team involved all the time.
As one can easily see: there is not much going on here in my IBM blog for now. Last posting has been 4 month ago. My excuse for now: having 4 blogs is probably too many. Anyhow, I don’t give up yet. I promise to improve and post updates here more frequently.
The series of lessons learned from my projects continues:
Closure on requirements took much longer than expected: 4 weeks vs. 1 week.
Of course its good to have an aggressive plan. I was planning for a 2 day requirements workshop and 3 more days to resolve open items. Finally it took 4 weeks until all open items have been resolved.
This was mainly caused by the customer himself. As more you go into details to really understand the requirements the more questions pop up the customer did not think about before. It then takes time until required information has been gathered and a conclusion is made.
It is certainly wise to spend that time needed to come to a useful set of statements of requirements. Every hour we spend at the beginning of the project to talk about and document requirements carefully should pay back later with a factor of 10 or more - also by reducing number of change requests which easily increase project cost - sometimes only because they have to be investigated and create confusion in the team.
As I am reading what I have written in my IBM internal blog three years ago and putting that into the context of what I know today about Agile Software Development meanwhile I realize that this lesson learned can be seen as a clear symptom of “change prevention mode” in a project managed the classic way. Evangelists of Agile would argue that it is an unrealistic or even undesired goal to reduce change requests in a project. Agile actually encourages change and tries to avoid high initial effort to define and document requirements.
While I like this idea I believe at the beginning of a project the clear decision has to be made whether to run it the classic or an Agile way. It might depend on the customer, the sponsor and organizational policies and the nature of the project what the outcome of this decision will be, but it is important to make it up-front and become aware of the project management method to be used.
When managing the project the classic way I think my lesson learned mentioned above makes sense: effort invested at the beginning to better understand the scope of the project should pay off later on. Sufficient time should be planned to understand who the stakeholder are, to communicate, to brainstorm, to document, to evaluate alternatives, to come to conclusions and decisions. Decisions made early should be cheaper than those made later – if not too late.
Don’t push it too hard and plan sufficient time and contingency. Allow time for ideas to maturate, for questions to be answered, for a common understanding to be achieved, and first of all: for the team ( consisting of customer and IT solution provider folks ) to form.
In May 2005 I started blogging about lessons learned from projects I have managed in my IBM internal blog. Gathering lessons learned during and especially at the end of a project is seen as an important project management activity and simply good practice. And what better tool than a blog can we think of to share those lessons with the team, with other project management professionals and the rest of the world ?
Today I start with a positive lesson I learned ( and I guess that’s a good start; some negative lessons might follow a little later here in my blog ):
Kick Off Meeting facilitated a good project start. Team is collaborating very well.
I have read it hundred of times during preparation of my PMP examination while studying PMBOK 2000 and other material from PMI how important a good kick-off meeting is for a project and especially for team building. From my experience: this is absolutely true. I can only recommend: even for a "virtual team" - try to get the travel approvals and dollars to bring your team members together at least once at the beginning of the project to meet face to face. Let them be a real team at least for one day !
It pays off ! My team collaborated and communicated very well during my project and seemed to be highly motivated. I am sure without a face to face well prepared kick-off meeting with a good agenda it would not have developed like this. The meeting took about 2 hours and I used the time to clearly explain and discuss the scope of our project, customer expectations, my expectations, team member roles.
The face-to-face meeting is one thing. Important as well is to use that kick-off meeting as a clear and visible project start milestone. Everyone participating in that meeting knew exactly afterwards: from now on I belong to that project team and work on that project.
The agenda for that meeting contained
- a welcome/introduction by the customer
- a presentation of the approved project charter
- a discussion about the communication plan ( including analysis of stakeholder information needs )
- a discussion about a team charter
- an explanation of next steps in the project ( requirements workshop, work break down, sizing etc...)
In a complex project or with a large team more time and peace might be needed for coming up with a team charter, thus an extra and may be more private meeting would be recommended here. Also developing a communication plan for a larger project requires more work and thorough analysis than can be accomplished in one single meeting.
Letting the customer and/or sponsor of the project start the kick-off meeting and express their expectations is a nice move. Once he has given his intro its kind of a symbolic act to hand over the project to the project manager and kind of formally announce him or her in front of the team.
Project charter, rough scope of the project, introducing the team and explaining where the project is currently ( e.g. when exactly will it move from planning to execution phase ) and what the next steps are should not be missing on the agenda of a successful project kick-off meeting.