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

Something to laugh: my favorite comic strip of the week – about 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 …

Something to learn: my favorite tip of the week – about 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.

Something to discover: my favorite bookmark of the week – about 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 license – about 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 week – about leadership

If you’re a leader, you don’t push wet spaghetti, you pull it. ~ Bill Mauldin ~ 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 ).

My favorites for week 35, 2010

Something to laugh: my favorite comic strip of the week – about defending a castle. Or: project management in the good old times

Being a project manager many hundred years ago probably wasn’t much easier than it is today. Think for instance about the project of defending a castle. For such a project it was real critical to meet the dead lines, as nicely shown in the Herman comic strip.

Something to watch: my favorite video clip of the week – about multiple computer

I think there is a world market for maybe five computers ~ Thomas Watson, chairman of IBM, 1943 ~ Look at this quote Thomas Watson, chairman of IBM, made in 1943. OK, that’s long ago. Nowadays there are actually 7 computers in my household, not to count any mobile devices, which I actually don’t use except a mobile phone. Some day we will probably ask ourselves: what do we do with all these computers ? Do we really need so many ? The guy here in this video gives you one idea what you can do with so many computers. Just give him a few seconds…

Something to enjoy: my favorite photo  on flickr under a Common Creative license – about NASA

The Goddard Photo and Video Blog publishs a few interesting shots every day, like the one from Hurricane Earl, as seen on September 1, 2010. NASA joined the Commons on Flickr on August 30th with three iconic sets spanning the US space agency’s 50+ year history. Their Commons account will feature photos from across the agency’s many locations and centers, chronicling the history of space and lunar missions, and the people and places of the organization. One of their photos you can see below on the right. "NASA Satellite Captures Hurricane Earl on September 1, 2010" by NASA Goddard Space Flight Center. "Apollo 11 Launched Via Saturn V Rocket" by NASA on The Commons.

My favorites for week 33, 2010

Something to laugh: my favorite comic strip of the week – about next generations

This “Moderately Confused” comic strip reminds me of a day a few years ago when friends visited our house and had promised their kids that I would show them my turn table player. With big eyes they watched how I played one of those gramophone records on this strange device – strange for them of course. Man, I felt old that day.

Something to watch: my favorite video clip of the week – about people under water

Can people walk, talk and breath under water ? Apparently they can – as long as this is no real water as in this Amazing Japanese Fake Pool.

Something to learn: my favorite tip of the week – about “undo” in firefox

Hit Undo in Firefox’s Address Bar to Browse Your Recent History is a tip published by Lifehacker beginning of this week: Hit the undo shortcut (Ctrl+z/Cmd+z) in Firefox’s address bar to move through your recent history via keyboard and find tabs you’ve closed—sort of like a lightweight version of the Undo Closed Tab feature. And: You can re-open closed tabs in browsers like Firefox, Chrome, and Opera by hitting the Ctrl+Shift+T shortcut (or Cmd+Shift+T on Mac) … !

Something to enjoy: my favorite photo  on flickr under a Common Creative license – about the smallest monkey of the world

"Pigmy marmoset" by Tambako The Jaguar. “This is is a pygmy marmoset, which is the smallest monkey of the world. They come from Brazil …” writes Tambako the Jaguar in the description to this photo. He has an awesome collection of animal photos in his flickr photo stream.

Something to talk about: my favorite quote of the week – about decisions made by groups of people

A committee can make a decision that is dumber than any of its members. ~ David Coblitz ~ What is said here about a committee might hold true as well for teams or any other type of group of people. As a project manager I should believe in the power of teams, but frankly speaking I actually buy this quote. Often teams come up with a bad decision, because that decision is not derived from true thinking, intelligence and honesty, it is derived from politics and power struggle. >> Where there are people there are politics << is a quote from a PM education class about taking control of an existing project I participated in more than one year ago. My father used to give me the following advice: “Stay away from the opinion and behavior of the majority”.

My favorites for week 32, 2010

Something to laugh: my favorite comic strip of the week – about golf

I didn’t know we played golf already B.C. According to Wikipedia this started in the 15th century. Anyway, this little comic clip is a nice example of a complicated solution which usually looks more interesting than the simple way to success. But only if it works. If it doesn’t it suddenly might look pretty stupid. Something to keep in mind next time when designing a solution for a customer.

Something to discover: my favorite bookmark of the week – about unsucking corporate language

A nice recommendation from Lifehacker this morning: “Unsuck It Translates Awful Corporate Speak into Plain English”. How do you like this one: “Accelerated Emergence of High Maturity Behaviors” ? If you need a translation, visit http://unsuck-it.com/. I was wondering whether “Low Hanging Fruits” are in there as well, one of my favorites. Of course they are ! How is “learning” expressed in corporate speak ? “Knowledge Acquisition”. “Sharing information” ? Check it out yourself.

Something to enjoy: my favorite photo  on flickr under a Common Creative license – about Stonehenge and London

"Stonehenge" by Marcel Germain. Here is a nice shot of a famous place from MarcelGermain from Barcelona: “Stonehenge”. Just today he came up with another awesome photo: “A postcard from London II”. "A postcard from London II" by Marcel Germain.

Something to talk about: my favorite quote of the week – about fear and knowledge

Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less. ~ Marie Curie, French (Polish-born) chemist & physicist (1867 – 1934) ~ I don’t necessarily agree to the first part of the quote, but definitely to the second part. Usually we fear the unknown, and as the unknown becomes better known to us fear usually goes away. Like when you join a new project: at the beginning you might be full of fear and uncertainty. As soon as you get more into it and start knowing more and more about it you know how to put your hands around it and how to deal with it. Even if you realize you ended up in a troubled project, as soon as you know this and where the trouble is you have means to address this and thus move your fear aside. The fear becomes a challenge then, may be even an exciting one.

Lessons Learned: Players change too often

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.

The never ending journey through knowledge …

It’s amazing, isn’t it ? I read “Ajax: A Beginner’s Guide” by Steven Holzner and learned basics about Javascript and Ajax, and I learned that there are many Javascript frameworks out there making it easier to use these technologies – one of it is Dojo, a quiet popular one. I read  “Learning Dojo” by Peter Svensson and through this book I learn about alternate Javascript frameworks like e.g. JQuery, another popular one. Since also some people argue this to be better than Dojo ( certainly others argue the other way around ) I become curious and now started reading “Beginning JavaScript and CSS Development with jQuery” by Richard York. Among the first things I learn from this book is that there are other Javascript frameworks out there: base2, Yahoo UI, Prototype, SproutCore.

* 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.

~ –Faust, lines 354-59. ~

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.

Suppose it would be your job to recommend the best Javascript framework for a given project ( and let us assume for now and for the sake of simplicity this would be a well defined project with well established requirements ): how would you do this ? Learn about all available Javascript frameworks and come up with a decision on your own ? Hardly possible. Learning about all these Javascript frameworks actually wouldn’t be sufficient, you would have to be an expert for all those through having actually used all those for at least a few projects. Not realistic – your project would never start.

Your other option would be to find experts for all these Javascript frameworks, make them familiar with your project, put them all together and see with what decision they would come up with. If any. Hardly possible either. A little bit more realistic may be, but still almost impossible. It starts with the hurdle that you never would find all those experts nor get them all together for your project. If you would overcome this problem most likely you would see each of your experts fight for his favorite framework without getting to any decision. If a decision would be made it is most probably not made based on objective judgment, it is most likely a result of group dynamics and politics.

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.

Some thoughts on Agile: The Triple Constraints

In traditional project management every project manager learns about the triple constraints: scope, time, cost. When it comes to plan a project first of all it is the job of the project manager to align all three factors to form a triangle. Everything other than a triangle would not be a project in the pure sense of project management philosophy. For example when you have a well defined scope but no idea when you will be finished you don’t have a project. Or the other way around: you know exactly when you will finish but you have not specified exactly what to deliver by then.

How does a project not look like …

Or if the duration for the given scope is simply too short, enforced e.g. through some political power, you don’t have a project.

These are project management fundamentals so to speak.

It means as a project manager you need to have the degree of freedom and power to adjust at least one of the factors to form that triangle. If you don’t you better stay away from that project – this is my philosophy.

Maintaining that triangle shape of a project also is important when planning is over and you enter execution phase. You might have done a good job during planning phase to define your project well, but when you fail to manage change your triangle very quickly might turn into some other shape indicating a messed up project. Most common example: you keep adding changes to your scope without adjusting at least one of the other two factors: cost and duration. Many well planned projects fail because of improper or basically non-existent change management.

If a project gets into trouble, which is most likely the factor to be adjusted ? Budget ? Most probably not. You know how hard it is to get extra money, do you ? In contradiction you’d rather expect your budget to be cut while the project is running in times of a financial crisis or when permanent cost cuts strike your enterprise. Time line ? Not possible for many projects, but reasonable for some projects. Scope ? This is probably the factor you most likely try to adjust when you are in trouble with your project. Depending on what contract you have with your customer this might not be easy as well and requires a lot of arguing.

Now, what is the approach in Agile projects ? Do Agile projects have to worry about the Triple Constraints as well ? Of course they do. But how do Agile projects deal with that, especially when they get into trouble ?

First of all Agile Projects focus on a fixed time line – within an iteration. An iteration by definition is stable and time-boxed, which means: duration is defined and identical for every single iteration, and the iteration ends at the end of the time box. This is a solid rule in Agile.

But what about the entire project which consists of many iterations ? Do we know exactly from the beginning how many iterations we will do until we are finished ? Good question, no clear answer from my side yet. Due to the nature of Agile projects to actually encourage change I can easily imagine that the time line of an entire project is rather flexible.

What about the scope, also within an iteration ? I think this is the factor also in an Agile project which needs to be flexible while time line is not ( time-boxed ! )  – within an iteration ! If at the end of an iteration some items from the backlog have not been started they are moved to a different iteration – not necessarily the next one. If items have been started but not finished they might be re-defined and split into a finished part and an un-started part to more easily and clearly keep track on accomplished deliverables and to-be-done ones.

Nevertheless, this approach shows that the physics of the Triple Constraints also apply to Agile projects and also in an Agile project you have to have the freedom to adjust at least one of the factors when you get into trouble, when things go unexpected: scope it is in Agile projects. Within an iteration. How the Triple Constraints are applied to the entire project might require some different thinking. This to me is the major mystery in Agile projects.

Visualizing the critical path in MS Project

We can view the critical path in a project management schedule as what I would call the "bottleneck" of the project: it is the series of activities which determines the possibly earliest completion of the project. That means that activities on the critical path can not be delayed without jeopardizing the project end date; those activities have zero float. That means on the other side that activities not being on the critical path do have some float: these activities can be delayed to some extent without jeopardizing the project end date. This "some extent" would be the float of those activities indicating how many days those activities could move to the right without any major impact on the project end date.
Thus it becomes obvious that a project manager needs to really have the critical path on his radar screen. Activities on the critical path require highest attention since any delay here means a delay of the entire project. For that reason it is a good idea to somehow visualize the critical path in our MS Project plan !
MS Project allows to do this: you can show bars of activities on the critical path in a different color and you can highlight the task names and task information in another color ( red is the chosen default ). Here is the recipe how to do this and I also have prepared a little screen cast to demo this:

1. Use the gannt chart wizard (Menu: Format -> Gantt Chart Wizard) in MS Project to specify that bars of critical tasks will be shown in red color.  Simply select the "critical path" radio button and proceed through the remaining dialogs by just confirming the defaults, then hit "Format It!" and "Exit Wizard".
2. Next use the "Text Styles" dialog box to specify that text for critical tasks should be displayed in red color: select "Critical tasks" from the drop down "Item To Change", then select "Red"   from the color drop down, click OK to finish.

After this has been done you end up with a gantt chart like this:

In our little example here we now easily can  figure out where the critical path is: specifying and design activities are on the critical path as well as integration testing, as probably expected. All SAP related activities are on the critical path as well, while we do have some float ( or slack ) for the GUI and database related activities.
How much slack we have can be seen in the "Start Slack" column: there is not too much "space to breath" for the GUI related tasks, but lots of float for the database related tasks.

My favorite flickr CC photo of the week: about a maze of mirrors

"Maze of Mirrors" by laanba.

Somehow I love this photo because of the message it delivers. Laurie writes in her description of the photo: “As I was wandering around near the Alamo I came across a place called "The Mirror Maze." You KNOW I had to go in.
Here is an example from the maze. I know it looks like it is a straight hallway, but you couldn’t walk more than one or two of those triangle wedges before you ran into a mirror. You had to wear gloves so you wouldn’t get the mirror dirty. It was so much fun.”

I found this to be a nice analogy with project management or life in general. You create your plan and think you can travel along the timeline as you planned it and convert your gantt chart into reality. But then all the unknowns get into your way and start messing up the path you intended to follow. You can create plans, but you can not see the future. The future you see ahead of you is simply your assumption how it will be, an illusion.