Passion and Project Management

Why do you do what you do? Are you in Project Management because that's what you want to do or is it because it seems like a good career step for what you really want to do next? I'm referring to Software Project Management but it could be any kind of Project Management. I think you can only be really good at something you passionately care about. Many people will see and reward honest passion because they will "feel" that you care. This is about the project and the people in the project, not about you.
I am very interested in people and technique and honestly enjoy working in an environment where I can work with people while I learn something new about the techniques used. These interests allow me to not consider everything I do, to get better at Project Management, as work. It's fun, I enjoy learning and enjoy seeing it work.

Without this personal interest I might lack the energy to continuously learn something new and to adjust to changing environments. To ensure the team and you succeed with your project you will always have to find new solutions or adopt already proven solutions. I see this after doing Projects for 17 years. To keep this interesting and to excel at what you do you need passion.
If you honestly consider Project Management your passion then I'm sure you will succeed. But whatever you passion is don't waste it on something you don't enjoy.

How to get the best out of your Project Team

Just recently I went to a lecture from Marshall Goldsmith. He is an executive coach and normally trains CEO's how to get better in interpersonal relationships.It was interesting but not overwhelming because there are already so many books on self improvement. What was even a little annoying during his lecture were his frequent references (almost boasting) to close relationships with CEO's, Admirals etc. In short all people that are extremely successful. These references made it a little harder for me to relate to what he said because I am not the person he was talking about. Anyway every attendee got his book "What got you here won't get you there" and so I started reading it, a little bit relucantly at first. While I read it I learned that many of the topics he discusses are very true and also applicable to Project Management. Just look at an excerpt of his 20 work habits you need to break to see if you can relate to that

1. Listening without passing judgement
2. Make destructive "little" comments
3. Telling other people they are wrong with sentences like "no ...", "but ..." or "however ...."
4. Telling the world how smart we are
5. Speaking when angry
6. Negativity
7. Withholding information
8. Failing to give proper recognition
9. Claiming credit that we don't deserve
10. Not listening

I found that many of the work habits above interfere negatively with my projects. The list sounds simple to change but let's consider this. Isn't it simple to say you will lose weight when you exercise and eat better? It is simple to say but it is not easy to do. So how can you break these habits?
His proposal on how we can change for the better is simple to understand but not easy to do.

1. Ask for feedback
1. Stop asking for feedback and then expressing your opinion
2. Learn how to solicit feedback - Ask "How can I do better". This asks for advice rather than criticism and you focus on the future instead of obsessing with the past
3. Make a list of people's casual remarks about you
2. Apologizing
3. Telling everyone that you will change, advertise it
4. Listening
1. Ask yourself, "Is it worth it?" before you respond (especially when you are angry)
2. Don't interrupt
3. Don't finish other person's sentences
4. Don't say I knew that
5. Don't even agree with the other person (even if he praises you, just say, "Thank you")
6. Don't use the words "no", "but" and "however"
7. Don't be distracted. Don't let your eyes or attention wander elsewhere while the other person is talking
8. Eliminate any striving to impress the other person with how smart or funny you are.
5. Thanking

I considered the book very helpful for my projects and personal development and therefore wanted to share this with you. If the above sounds true to you then get his book and read the above high level summary in more detail. If we actually improve just one or two things consistently I'm sure we will see a positive impact. I'm going to try. How about you?

Building a good Project Team

There are many different ingredients that make up a good project team. I want to focus on one for this blog post and that is to not pass judgment. Let me clarify, I think it is good to offer an opinion during normal business discussions because it allows people to agree or disagree with you. But it is not helpful when people are critiqued with your answer especially when you asked for feedback. Let’s look at an example: You are sitting in a Project Meeting with your Project Sponsor and some Key Members of the Project Team and look at different idea’s how to resolve a specific project issue. After different Team Members present their solution idea’s the Project Sponsor tells the first person (Person A) “That is a great idea”. Then he tells the next person (Person B),“Well, that might work” and he doesn’t comment the third person’s (Person C) proposal at all.

You can bet that everyone in that meeting has made a mental note of that Project Sponsors rating. He judged the peoples response with his answers. This in turn will determine the dynamics for this group going forward. Most likely everyone in that group, except Person A, will become more careful when they respond the next time, especially when this happens repeatedly. That is because nobody likes to be critiqued. To get the best out of yourself and the Project Team it would help to take on a more neutral attitude because it encourages more feedback from everyone. You listen to all the proposals without commenting them. Keep in mind that you don’t have to agree with the person and/or proposal. All you do is keep your thoughts to yourself and hear the person out.

The advantage of this approach is that you don’t take sides and you don’t judge people. This will encourage and nurture open Team discussions, which in turn leads to more productive teams that are more motivated. As a positive side effect you will also spend less time in arguments who is right and who is wrong and why. Again, you can disagree but you don’t say it because it doesn’t help the team. You don’t need to have a “everybody loves everyone” attitude in your project, which is not even desirable but you want to create a climate in which everyone can make their maximum contribution.

This way the Project Manager/SCRUM Master creates and supports an open and trusted environment where everyone is welcome to contribute. Try it and see how it works for your project.

Change Management in Mergers & Acquisitions

I’m currently reading “Switch – How to change things when change is hard” from Chip + Dan Heath. It is a very inspiring book. The reason I bring this up in this blog is that the concepts presented in this book also apply to Mergers & Acquisitions. After having seen the tough challenges related to Mergers & Acquisitions myself I think it is very important to keep these points in mind to get to a better M&A experience. As a first step we should recognize that (M&A related) change happens on two levels.
1. Intellectual Level
    Examples:
    a. Extended product or service offering through M&A
    b. Coverage of new markets

2. Emotional Level
    Examples:
    a. What does this change mean to me?
    b. How different are the cultures of the two companies? Which culture will prevail?

For the “Intellectual” Change they recommend
- Find the bright spots
   Instead of just looking at the challenges (e.g. different IT systems need
   to be aligned, processes need to revised etc.) look at what is getting
   better because of the M&A.
- Script the critical moves
  That is a big one because to script all the critical moves is the challenge.
  You need to make decisions based on limited data and knowledge.
  Analysis is important but it is equally important to not fall into the
  Analysis-Paralysis trap.
- Point to the destination
  The M&A Lead should be able to define clearly what is needed
   by when. Again, easier said than done but it is necessary to translate
   the big picture into specific steps/behaviors in order to be successful.

For the “Emotional” Change they recommend
- Find the feeling
   As suggested by John Kotter and Dan Cohen the change sequence for
   big changes like M&A’s should be SEE-FEEL- CHANGE instead
   of ANALYZE-THINK-CHANGE. You have to create an  
   environment where people want the M&A to succeed and where
   they are buying into this effort BEFORE  you start analyzing.
- Shrink the change
   In a M&A situation it is easy to be overwhelmed by the changes.
   To make this easier to digest and get more buy in from everyone involved
    it is necessary to make the changes smaller and more achievable.
- Grow your people
  Make sure this is not just a saying, live up to it. Focus on the people that
  want to stay in the new company and buy into the M&A. Find out why
  they want to stay and then apply this knowledge to improve the situation
  for those who are struggling. There will be challenges ahead but there will
  also be new opportunities. Make sure this is understood early on.

The third change component is to shape a path to the desired change.
This has the items
- Tweak the environment
- Build Habits
- Rally the Herd

If you truly understand these concepts and can apply them in a real M&A situation you should have a considerably better M&A experience. It still won’t be smooth but better.
Get the book to see many detailed examples and to get some inspiration how and what you can apply to your next M&A situation (or any other change situation).

Who should lead your software implemenation project: A technical expert or a project management expert?

I suggest an experienced project manager/SCRUM Master that has good technical background knowledge. Maybe someone who had development experience before they switched to Project Management. The key here is not that this person has up-to-date development skills but that they know how a software development team works in general.
If the person has very deep development skills it will most likely be a hinderance because they will tend to tell the team "how to do" things. This in turn will most likely be a challenge for the software development team because they don't like to be micro-managed.
The person should have solid project management skills (traditional and/or agile) and should like to work with people. In addition to that Leadership skills (e.g. communication, delegation), team spirit and a honest passion for Project Management are important.

The most challenging part of every software development project or standard software (e.g. SAP, Siebel) deployment project is to gather all requirements in the correct priority. In order to understand the requirements correctly Industry experience is important. Depending on the complexity of your Industry this is not the most critical part but the learning curve can take considerable time and hence the desire to have someone with industry experience.

For many technical experts the leadership skills are the most challenging part. They tend to try to do things faster and for less money. In the end there are many bumps and many lessons learned. This drags down the team morale and hence should be prevented.

The conclusion here is that technical experts might become good project leaders when they get the time and experience to get the additional project management skills. Do you have the time, money and desire to invest in this?