Blog about Project management and Leadership from a senior PM

Go Live

noreply@blogger.com (The PM) — Tue, 10 Oct 2006 18:00:00 +0000

We did it! I’m so pleased right now… Pleased, satisfied and a bit proud!

After over one year of hard work, stress, deadlines, milestones, test, planning and follow up we went live with the system the other day. The project had a service-window from 2200 hrs to 0500 hrs to perform the migration to the new hardware and a newer version of the software. If we weren’t ready with the migration until 0230 we had to rollback everything and go back to the old hardware and software. Even though we encountered some unexpected issues during the night we managed to keep to our checklists and timeplan. We were ready at 0200 hrs and all of us drew a sigh of relief. The operations on site started as usual at 0500 hrs without any impact and the users (250 users) did not even notice that we had changed a lot of things for the during the night. We all were very satisfied with our work.

The impact if we had failed was a loss of ~$200 000/day and a lot of bad publicity if we had failed with the migration and also failed with a possible rollback. It would not have been fun to communicate such a thing. The pressure was there but all of us manage to keep it together and solve the issues that we found directly.

There are a number of things that you should think of when you should Go Live with a new system;

* Preparations are important
The success of your Go Live is often directly dependent on very good preparations. Think of a team of doctors and nurses that will perform an operation. All of the team-members are aware of their role and responsibility well before the operation. The same goes for a Go Live in your project. All resources involved must be aware about the role, responsibility and what is expected from them before you enter the Go Live phase. What do you do if something goes wrong? All of the resources in an team of surgeons and nurses knows what to do if anything goes wrong with the patient. I do not recommend you to start thinking about a backup-plan when something goes wrong during a Go Live, this must have been defined way before you do the Go Live. It is also important that all involved resources are aware about the total plan and how important his/her part is. All need to see and understand the total plan for the Go Live.

* Stick to the plan.
Do not deviate from the plan if you not absolutely must. All involved parties know the plan and you will swim into deep and dark water if you need to deviate from the plan during a Go Live. The need of detailed co-ordination will dramatically increase if you need to introduce new steps during the Go Live-phase. Try to avoid this and stick to the plan as far as you can.

* Slack in the plan
Have slack in the Go Live-plan! Issues will often arise and you need time to fix them. You will often run into unexpected issues that must be solved directly and you need to plan for it.

* Verification- and decision-points
Plan for verification-points in the middle of the Go Live-process if possible. In conjunction with these you also need to plan for decision-points were you decide if you are good to continue or if you need to abort and perform a rollback.

* Correct resources
Make sure that you have the correct resources for the Go Live. Who can solve difficult issues directly if needed? Who do you trust? Who will cope with working under pressure? Also make sure that you have backups for all the most important roles during the Go Live.

* You can not prepare for everything.
If something can go wrong, things will go wrong. Plan for problems and make sure that you have the correct resources in the room to solve upcoming issues. This is also a physiological game, if all the resources knows that the project is well prepared and have the correct resources they will also perform better under pressure.

* Identify the risk and mitigate them
You often have the possibility identify quite many risks before the Go Live. This is a great opportunity to increase the possibility of a successful Go Live for your project. . If you work actively with the risk’s you will soon notice that the probability and impact of the risk’s decreases and in that way the possibility of a successful Go Live increases.

I wish you all a great day in your project management life.

/ThePM

project management go live plannig leadership system

Certified PM’s…or not?

noreply@blogger.com (The PM) — Tue, 26 Sep 2006 17:43:00 +0000

I often come across post’s regarding pros and con’s for PM certification. I place my self among those who say that we should have certifications for Project Managers. It is just during the recent years that I feel that the profession of Project Management. has become more and more accepted. Almost anybody can say that they are a project manager, but of all those who claim the title Project Manager I strongly believe that there are not many who actually can tell what knowledge and experience a PM should have. To be a successful PM you need to have both some theoretical knowledge but you also need the experience. To manage a project can often be challenging in many ways and you need to have done the mistakes and learned from them to become a good PM that knows what he or she talks about. Yes, you can of course be a great PM without certification but the certification is a receipt on that you are able to deliver according to a certain standard. I work in an internal IT-department and we are unfortunately not certifying our PM’s, which is a pity but the sad fact. But we buy a large amount of consultancy-services and I must say that it feels good to see a CV of a PM that says PMI-certified. . Then I know that I will get a PM that has the experience and knowledge to do a good job.
What do the rest of all of you PM’s think?

project management pmi certificaton pmp consultant

Receiving Feedback

noreply@blogger.com (The PM) — Sun, 24 Sep 2006 18:12:00 +0000

Why is feedback so important? There are many answers to that question but the most important answer must be that you are able to receive valuable information about what You need to improve and in that way also develop your self.
Giving feedback can sometime be difficult but receiving feedback can also be difficult, but in another way. To receive feedback is about communication, but you need to stay focused and quiet. When the person who gives feedback talks, you need to stay quiet and listen and use your body language to confirm that you are listening and follow his or hers feedback. To receive feedback can often trigger a need for you to explain or defend your self. More than often will your perception of the feedback differ from the person who gives the feedback. Try to stay quiet until the giving-person is finished and then you are able to ask questions to clarify the feedback.

Your body language should signal that you are interested and open to receive information. In other words, do not lean backwards into the chair with your arms crossed. That is not a good way of saying that you are willing to receive feedback.
Remember that feedback, or constructive criticism, is a way for you to learn, grow and improve your performance.

How well you receive the feedback can be divided into five different stages;

1. Denial. You hardly listen to the person who gives the feedback and interrupt with saying: “This does not concern me” This is a very immature way of receiving feedback. If you, as a giver of the feedback, meet this kind of person you have to work slowly and have a lot of patience.

2. Defence. You immediately start to defend your self. “No, this was not the way it was.” Or you blame somebody else.

3. Explanation. You start to explain your behaviours. A person in this stage often listen a bit more before interrupting the feedback.

4. Understanding. You listen to the person who gives feedback and really try to understand what the other person says. This is were you and your team should be to have a fair chance of develop as a team and individuals.

5. Change. You listen, ask questions, try to understand and also change your behaviours. It is your own choice to change.

Remember that to give and receive feedback is a vital competence for you as a project manager. Try it, try it often and improve your ability to give and receive Feedback. It will excel your self as a project manager.

project management communication leadership feedback develop

Key succes factors

noreply@blogger.com (The PM) — Mon, 18 Sep 2006 18:38:00 +0000

In the infrastructure-project we have another 3 weeks before we go into production. We still have one major test to pass but I'm confident that we both will make a good test and a successful Go Live in a couple of weeks. All the men and women who have worked to hard realy desirves to have the Go Live on time with a successful result. We are all working hard to make this happen and some of us put in extra hours these weeks just to reach our goal. It is a satisfying feeling to see all work for eachother to reach the goal.

During the last projectmeeting we held a small workshop in which we discussed Why we have been successul so far. The team agreed upon a number of reason and some of them are;

* Good planning
We planned the project in detail from the start and we have followed the plan. Ok, small changes have ofcourse been made, that is natural, but in overall we have followed the plan. This have made all involved project-members and stakeholder to always know what we have done and what is yet to be done. It is also easy to prioritise correctly when you have a solid plan to prioritise after.

* Constant and Clear prioritisation
During this year we have always worked with prioritisation over time. If there are conflicts between activities all projectmembers should always know what is prioritised.

* Simplicity
Even though we have a complicated project we have tried to keep things as simple as possible. We have not had the luxury of making fancy and hightech solution...just solve our challenges in the best possible way and according to the timeplan.

* Communication
Not knowing what is happening in the project is not good. I have written a weekly information-letter which has been sent to all projectmembers and all major stakeholders. It is painstaking sometimes but worth every penny of it.

I'll come back to these factors after we have delivered but please have them in mind when you are running your projects...

project management communication prioritisation planning leadership

Giving Feedback

noreply@blogger.com (The PM) — Tue, 29 Aug 2006 17:57:00 +0000

To form a medium project-team into a high performance team that are highly motivated to meet the objectives of the project you need to work actively with Feedback. The main objective with feedback, as I see it, is to help other collegues/coworkers to develop them selves and in that way also perform better. You will also increase your possibilities to deliver on time, on budget and with the correct scope and quality. In a well performing team you are able to both give and receive feedback in a mature way.
Example of feedback are when you tell a projectmember that he/she has performed well or when you need to correct any bad behaviour that coworker has.

There are some things to think about when you give feedback:
• Give the feedback directly to the person or the team. Do not let the receiver of the feedback get the information from somebody else.
• The receiver should be able to control the feedback with other. You need to stand fast with the feedback even though it some time can be tough.
• You should give the feedback, not “we” or “somebody” else. You need to be able to say “I think that you…etc…”
• If the receiver of the feedback would like the feedback it is more likely that the person will accept and learn from the feedback. Do not force the feedback onto someone, if possible.
• If you need to give constructive negative feedback you also need to prepare your self. Come to such meeting well prepared and you will have a better result of the meeting.
• Describe the behaviour that the person has and what kind effect that the behaviour has on you.
• Do not give too much feedback at once. The receiver is just able to take a certain amount at once.
• Be careful with the timing of the feedback. You can not give the feedback too long after the behaviour was shown. The feedback must be given in the nearby future from the time when the event took place.
• Ask the receiver of the feedback to confirm that he/she has understood the feedback.
• Give feedback about behaviours that the receiver is able to correct and to something about.
• Make sure that both of you have the correct amount of time that is necessary for the feedback.

You will only be really good a giving feedback if you practice on it. Everyday, both at work and at home.

ThePM

project management leadership feedback communication

Resource problem

noreply@blogger.com (The PM) — Wed, 23 Aug 2006 20:05:00 +0000

We only have 7 more weeks to go in the infrastructure-project until Go Live. We are so far on plan but we have still three major tests’ to complete before the Go Live. The team is starting to feel the pressure and I think that some of my key project members are tired and soon fed up with the project. I although need them to stay sharp the last seven weeks. To be honest I’m also a bit tired and I want it badly to be the Go Live-week. That will be a lot of fun but, well…7 long weeks until than.

I still have problems with one of the resources and I will have yet another meeting with his line manager during the week. We both agree that we partly need to replace him but that will introduce another risk for us. We still need him and we need him sharp, motivated and alert…not the opposite. I can only cross my fingers and hope that he will not be too uncommitted for the remaining time of the project. I will prioritise him try to get him to feel needed in the project. Because he really is. Well…enough about that.

Another thing is that I will have a new line manager my self. That will be my 8th line manager in 5 years… how about that for continuity…

ThePM

Resource estimation template

noreply@blogger.com (The PM) — Fri, 18 Aug 2006 16:38:00 +0000

To do the budget is not the funniest thing I know but it is necessary. To do the financial follow up and forecasting of the project is even more tedious, but that is also necessary.

You need always to stay in control of your project. I use a small but quite efficient template to simplify this process. This template is useful if you know how much time each person/role in the project will spend over time. I usually work with longer projects and therefore the time format is set to months but you can of course change this to weeks or even days if that would suit your projects needs better.

I would although like to stress the importance of having valid number to put into the template. You need to do the basic work first of breaking the activities down into work packages into a Work Breakdown Structure (WBS). When you know how much resources you need, first than are you ready to use this template.

You are most welcome to change or update the template if you would like too. I would appreciate to see how an even better template so please send the new updated template to me…

I think the template is pretty “self-explainable” but please e-mail me if any questions.

Resource estimation template

BR ThePM

Top mgt buy-in

noreply@blogger.com (The PM) — Thu, 10 Aug 2006 18:20:00 +0000

Back from a three week long, and a much needed, vacation. Just before I left for vacation we had an interesting meeting with the CEO of the supplier for the 3rd party package-project. In March 2006 we increased the budget for the project and also informed the supplier that they were entiteled to use up to 7 resources instead of 2,5 before. This has unfortunately not happened due to the fact that we only spoke to the CTO and not the CEO. Ok, the CTO is a partner of the company and it should have been enough but it wasn’t…

The supplier had only utiliesed ~45% of the authorized resources during 10 weeks and this has proven to blow the timeplan for the project. The CEO was not aware about that the supplier had the right to use up to 7 resources and in that sence missed out on some good business for the company. I couldn’t belive when I heared this…

So, what are the lessons learned from this small ”misshapp”?

• Always secure that you have top management ”buy-in”
• Demand specified time-reports from the supplier

I have a feeling that I will have an interesting autumn…

/ThePM

What is a Methodology?

noreply@blogger.com (The PM) — Mon, 10 Jul 2006 17:10:00 +0000

To run an efficient project you need a Methodology. Yes, you can of course run a project without the support from a methodology. but I can almost guarantee that you will not accomplish what you plan to do on time, within budget with the correct scope and quality. You need a process that will support you and your work that lies ahead of you. A project management methodologyshould not be confused with a production-model such as RUP or similar. The production model is something that you utilize within the project management methodology.

There are a number of different methodologies out on the market but many of them are more or less the same but with different terminology. Different words but more or less the same meaning. There are names like Tollgate, Checkpoint, DecisionPoint, etc… but they are the same.

A fairly basic but efficient methodology. could look something like the picture below.

Each letter represents a CheckPoint (CP) in which you need your steering committee to make one or many decisions to be able to proceed in the project.

A: Project is initialized and you start the preparations. You have the mandate to spend a certain budget up until CP C.
B: The preparations continues according to plan or the SC chooses to abort or revise the budget up to CP C
C: Preparations are finished. The frame of the project is defined and the requirements are agreed upon.
D: The execution of the projects starts. The project commits it self to deliver within a certain budget, scope, time and quality.
E: Execution continues as planned or changes are done to the scope, budget or timeline for the project.
F: The project delivers. Full delivery or part-delivery.
G: The project hand over the result to the receiving organization.
H: The project is closed.

Next step will be an example of how to use the methodology in real life.

Good luck!

ThePM

Resource-issue

noreply@blogger.com (The PM) — Mon, 03 Jul 2006 17:46:00 +0000

I'm back from businesstrips and in general an enormous heavy workload. We have just passed an important milestone in the Infrastructure-project that has taken more or less all my avialable time. But we did it! 6 months of hard work paid of and it all came together in the end. But it was a close call.

One resource in the project is not performing well. He has the correct technical skills but lacks structure, commitment and desire to deliver on time. On top of this he also has major communicationproblems. It has gone so far that the other project- members do not trust him any more. He often says one thing but does an entirely other thing. This is unacceptable and he needs to be replaced by another resource.

It is frustrating that he time after time does the same misstakes and yes he has received feedback about his bad performance but it has not helped.

If you ever encounter this kind of problem you need to try to sort the problem out right away. Correct the bad behaviour at once and coach the resource in the right direction. If this fails after a couple of times you need to start to think of replacing him/her.

Remember...to deliver is what matters!

ThePM

What does a PM do

noreply@blogger.com (The PM) — Thu, 08 Jun 2006 05:25:00 +0000

A colleague of mine and my self came to discuss what a project manager
actually does during a day. It turned out to be and interesting
discussion?

I work in a large IT-organisation but it is fairly matured when it comes
to project and all the co-workers are used to that we have a large
number of simultaneously ongoing projects. There are not many at work
who questions the being or not being of a project manager, which is
good. But I have learned that there is many other who have a different
situation and that the role a project manager often is questioned; ?what
do you actually do, do you have the mandate to decide this, I?m not
reporting to you, etc?? This is for me strange and is just a sign of an
immature organization that do not see the benefits of running projects.
All roles in an organization has it?s own challenges and can be more or
less demanding but I can not think of a more complex and demanding role
than a project manager.

So? What does a PM do?

We lead, manage, follow up, make new plans, escalate, coach and many
other things. Yes, we do all those things but what we do more than
anything is to communicate. That is, for me, the primary task for us. We
can produce all the plans in the world if we not are able to communicate
them in a proper way. I often say to my fiancée (which is not in the
IT-industry) that I?m in a lot of meetings, talk in the phone or write
emails. That is for me about communication and communication is not at
all an easy thing to do. At the same time say to a coworker that he
needs to shape up and also keep his motivation is a trick? But
nevertheless is communication our most important mean for an PM to be
able to deliver.
I write a weekly information mail to all project members and key
stakelholders in the project. This has turned out to be very good and it
is worth the hour it takes to write.

Remember to communicate! But also think about that quantity is
not always better than quality.

Recommended books about the topic;

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Third Edition, Paperback

BR ThePM

Goals and vision

noreply@blogger.com (The PM) — Sat, 03 Jun 2006 11:22:00 +0000

Wow…what a week!
I started the week by flying abroad just over the day, which meant an extremely long day. Then we had a steering committee meeting on Wednesday in the 3rd party project. We have top managers in that steering committee so it is a bad place and time to “screw up”. My self and my colleague did a good SC-meeting, but we could have been better prepared. Need to improve until next meeting in August! The IT-organisation is delivering a service to the business-organisation for this service and we have the system in production for 10 countries. The project is proceeding to plan for coming countries and the maintenance-teams needs to secure the daily production. Our IT-organisation has the 1st and 2nd line support and the supplier of the system has the 3rd line-support. So, to be able to secure high service-level to our business there are four different entities that needs to collaborate; The Project, The Maintenance-team, Operations and the Supplier. The true, but sad, fact is that this is not working at all today. The service-level is low and the business is fed up with all the problems regarding downtime and bad performance. One of the IT managers in the SC asked me what I thought we should do about this and I was not prepared for this question even though I knew that the topic was going to be discussed. I thought about this issue later on and came to the conclusion that common objectives, goals and vision is crucial when different teams should work together. This is especially important when it comes to larger projects or programs. Continue to repeat the vision and goals for the project over the time in the project. People tend to forget.

BR ThePM

Thoughts about the week...

noreply@blogger.com (The PM) — Thu, 25 May 2006 14:57:00 +0000

The end has come of another working week.

This week has been quite ok due to the fact that the infrastructure-project is running ok. In the 3rd party project we have all kinds of problems, from performance-problems to problems in our processes. As an internal IT-department our only “customer” is our business organisation and the objective of the IT-organisation is to provide excellent service to the business-organisation. Well…we have a long way to go before we can deliver a good enough service regarding the 3rd party project. One of the main issues to be able to deliver a high quality service to the business is that we have a project as well as a line organisation (maintenance) that need to co-operate towards the business as well as the supplier. The system is in production in ten countries in Europe which means that the project is delivering new countries in the same time that when have countries in production, with major problems. The project and the line organisation are not always agreeing on what is most important and that makes the life a bit difficult. We had a crises-meeting about these issues during the week and it is clear that we have a hard time to deliver as ONE IT-company. The project had one view, the maintenance another, it-operations had a third. I had not called the meeting but it ended with me at the whiteboard calling the shots anyhow. I got so irritated with some of the people in the room when they not managed to see the full picture. The meeting ended anyhow with some sort of consensus about the way forward…now we just need to explain to the business why we are not able to implement any change requests or fix any incidents (except prio 1) during the next 4 weeks. It will be an interesting steering committee meeting next Wednesday.

The story will continue…

Regards ThePM

More about planning

noreply@blogger.com (The PM) — Sun, 21 May 2006 18:04:00 +0000

One of the cornerstones in good project management is to get the team to strive together towards a well define goal which everybody in the team understands. All activities are of course divided between the members of the project and all individuals need to be aware about which responsibilities he or she has. This is only possible via thorough planning.

For, personal- as well as a project manager-reasons, it always feel better to have solid plan to follow instead of wondering around in the darkness trying to find your way forward. With a proper planning you are able to always be one step ahead of the project team and in that we manage and lead them in a better way.

The project team and my self sat down and tried to figure out what we should do when we initiated the infrastructure-project. These meetings resulted in three important artefacts;

1. WBS-chart. Work Breakdown Structure-chart which is a chart that shows the breakdown of the activities.

2. Networkdiagrams, which are diagrams that shows the relative flow of the activities. You are also possible to easily identify the critical line.

3. An excelsheet in which I can track the progress of each activity and also see how much time that remains for each activity.

These three artifacts together with the Project Definition have proven to be the most important documents for me when it comes to steering and follow up in the project. I would also like to advice you to involve the project team, or at least key-resources, in the planning. You will then get the buy-in from them and they will feel more committed to deliver according to the project-plan and time-plan. Due to the fact that we took the time in the beginning of the project to do the planning in a good way we also have the project under control, we minimize the risk of misunderstandings, and I’m possible to be proactive in my management.

How you choose to structure your project and the work conducted inside the project is dependent on which kind of project you run and what you intend to deliver. It is a difference if you intend to build a house or if you are developing a software.

Some of you might think that you don’t need to secure a thorough planning…and maybe you are right and maybe, just maybe, you will come out on top with a successful project.
But…dear friends…in many of the cases will you not manage to deliver on time, with correct budget, with the scope and quality that your steering committee require of you.

The other project (3rd Party Project)that I’m involved in is a sad story in many ways. When myself and my colleague took over the project in February 2006 we only received a high level plan in a powerpoint-slide. A that point we had no choice but to deliver a part of the project due to legal issues in one European-country, but when that was done we froze the project to be able to lay the foundations once again. We are currently sorting out many issue in the project and we are securing a solid plan, which feel promising. One of the reasons that the 3rd-party product-project is in a bad shape is due to lack of plan and planning.

Please, do not step into that trap…SECURE A GOOD PLAN!

Please let me know if I can help you in any way.

Regards, ThePM

Need of planning

noreply@blogger.com (The PM) — Thu, 18 May 2006 18:55:00 +0000

My life at the office is currently divided in to two parts. One part is the planned and structured day in which most of the things run fairly smoothly. The other part is chaos. The Infrastructure-project is running very good and is on track. The 3rd Party-project is just a mess. (see the introduction for a presentation of the two
projects)

My self and a collegue of mine took over the 3rd party-project in Februry 2006 and it has been a constant battle ever since. The 3rd party-project started in 2003 and, as far as I know, it has been badly managed from day one. The project and all we who are working in it are currently paying the price for the bad project management up until February 2006.
Myself and the other project manager in the 3rd party-project are now working as firefighters, politicians and a bit as project managers. We as project managers are constantly putting out fires and are way too deep into operational questions.

My dear friends, it all comes down to Planning, planning, planning and more planning. The plan is nothing, the planning is everything. I think it was Winston Churchill who said it and it is so dead on correct when it comes to project management. The big difference (at least one of them) between my two projects is that in the infrastructure-project I had the possibility to make the planning in the beginning of the project in a good way. We have ever since the start had a good and structured project. All the resources know what they should do, when, how, what to deliver, etc... With a good planning you will also be able to do solid forecasts and keep the critical line in the project under close control. Without proper planning you will need to relay un luck...and that never works!

This is not rocket sience in any way...

But you will need a lot of hard work to "save" a badly managed project that has been wrongly executed from day one.

My advice for the day is to take the time in the beginning of your projects to do it right from the start!

So...as usual, please let me know if I can do anything for you.

BR ThePM

The SC-meeting

noreply@blogger.com (The PM) — Mon, 15 May 2006 18:36:00 +0000

Monday and back at work after a nice and relaxing weekend. This week is interesting in more than one way. In the infrastructure-project we have fairly extensive performance-test and the steering committee meeting. In the other project (The “3rd party packaged”-project) we will send out a RFI (Request For Information) to a number of companies in the North America.

I had the Steering Committee meeting today Monday and I’m satisfied with the meeting and also with outcome of the meeting. I were in no need of any major decision from the meeting today so the character of the meeting was more of reporting-character. The progress in the Infrastructure-project is good and according to plan so there where no major issues to resolve either.

There are also a couple of things that You as a Pm needs to think about when it comes to SC-meetings.

Most important are;
* Come prepared to the meetings.
What do you need from the SC-meeting? Think about that and prepare accordingly. Have backup slides ready. It is always impressive to say be able to answer a unprepared question with a prepared slide.

* Always tell the truth
Do NOT, and I repeat, Do Not lie in the SC-meeting. The truth will always catch up with you. And, that my dear friends, will not be pleasant.

* Give the decision-makers options
The people who should take the decisions need alternatives. Try to present at least two alternatives for each needed decision, 3 is even better…if possible.

* Remember the saying: “money talk, bullshit walks…”
Money is in 9/10 times a great argument that in most cases will back your case up if you present it in a good way. “I would like to do like this because we save $ x, etc…”

Another advice is to use the same structure in the presentation every time. That will make the audience to recognize the format and the will more comfortable. A good structure that almost always work is;
- Current situation
Describe the current situation in the project.
- Complications
What kind of problems do we have…with alternatives and suggested solutions.
- Way forward
Present how the project will continue and what the next steps are until the next SC-meeting.

Please let me know if you have any comments or let me know if I can help you in any way.

/ThePM

Thoughts about a steering committee

noreply@blogger.com (The PM) — Tue, 09 May 2006 05:43:00 +0000

Back from a great long weekend and ready to get up in the saddle again. I only had 34 unread mails which needs to be concidered as good after two days vacation.

I have a steering committee meeting on Monday next week which means that much of my time this week will be spend on preparations for the steering committee (SC) for the “Infrastructure-project”. We have SC-meeting approximately every second month in this project. The project is not in need of any major decision from the SC this time so it will hopefully be a short meeting to report progress and brief them about the way forward. To be honest I must say that the SC for the “Infrastructure-project” is pretty weak. The SC should be steering me but it is more or less the other way… They have the correct roles in the line-organization and are actually the correct SC but…yeah…they are bit weak.

There are a number of things that I think is important for a SC;

* They must be decisive and have the mandate to make decisions.
If not, you will have an interesting time ahead of you. The decision-making progress in the project will be painstaking slow and should be treated as a risk.

* They must follow up on the project manager.
The SC needs to follow up the work of the project manager to be able to take the responsibility for the project. Remember that it is often experienced coworkers, linemanagers or other important stakeholders that is members of a SC. Use their vast amount of experience.

* They must be interested in the project and have time to spend in the project.
How should the otherwise know what is happening in the project…

* They must come prepared to all meetings.
Do not be afraid of postponing a SC-meeting if they not have prepared them selves. Little or no use will come out of such meeting.

* The must support the project manager and the project
They should always work a ambassadors for the project and secure that the project has the correct preconditions.

Try always to work closely together with the chairman of the steering committee. He or she should always send out the invitations and the minutes for the meetings. Try also not get trapped in the “dear-pm-please-check-with-the-other-in-the-sc”-trap. If you need input from the SC you should put the question to the chairman and he or she will then contact the other members of the SC. This could otherwise be very time-consuming. An exception that confirms the rule is if you need to do some lobbying on the members in the SC…but that is a total different ballgame.

Remember that it is your responsibility and obligation to address issues with the SC to the “customer” of the project if you don’t think that that the SC is working properly.

There are also a couple of things that You as a Pm needs to think about when it comes to SC-meetings.

Please let me know your thoughts about project management or let me know if I can help you in any way...

BR The PM

Introduction

noreply@blogger.com (The PM) — Tue, 02 May 2006 18:33:00 +0000

Welcome!

I’m currently working as a Project Manager in an internal IT-department for the Global Company. The Global Company has approximately 100 000 employees around the world and has it HeadQuarters in Europe. I’m based at the HQ. The IT-department has around 1200 employees around the world on 10 different sites and if you include the consultants the figure would be around 1700. We are approximately 800 employees (incl consultants) at the HQ and the IT organisation is working fairly well with a newly implemented product-oriented organisation. It’s actually a terrific company to work in and I’m enjoying every day…more or less…
I’m just above 30 and started in the Global Company 2000 as a Project Manager and been working with different types of project but my focus has been on implementing 3rd party packages and vendor management. These two areas have become my speciality and my main focus of interest together with leadership in the scope of project management. I’ve run project from 5000 man hours up to 48000 man hours with a total budget of 28 million USD.

I’m currently involved in two different projects;

The first project- The Infrastructure project- has the objective to upgrade the hardware and software of the most critical system for the Global Company. Without this system the Global Company will not make any earnings. I’m responsible for this project and I must say that it is running very smoothly. In the time of writing we are just finalising the test-phase. It is a fairly small project with a budget of 13000 man hours. The scope of the project is to perform one pilot and plan for the rollout on ~300 sites globally. The Global Company will do this together with one of biggest consultancy firms.
Although we have our challenges (what would life be without them?) the project is in a good shape, on time and on budget.

The second project –The 3rd party project- is more of a challenge. The Global Company implementing a 3rd party product and the project is in a total mess. I could write endless lines of the bad management of the project but I will most likely come back to that in future postings. I’m not responsible of this project but supporting the responsible PM with issues regarding vendor management and the implementation of the system in North America. The responsible PM could be more experienced but is under the difficult circumstances performing well. Myself and the project manager took over the project in February 2006 and understood quickly that the project was (and still is) in a very bad condition. We are starting to get the pre-conditions in place but it is long and painstaking road ahead of us.

I will in this Blog tell You about the progress, difficulties, challenges that I have in these two project related to project management and leadership.

I’m looking forward to your feedback and will do my best to answer any mails…

By the way, this is a good week, because myself and my fiancée will travel to one of the major capitals in Europe for a long weekend without the kids…;-)
So, more about the projects and my weekend will come in the beginning of week 19.

All the best,
The PM