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.

Advertisements

One Response to “Lessons Learned: Players change too often”

  1. Change is not always good « Axel’s Travelog Says:

    […] Lessons Learned: Players change too often […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: