The Power of Thank you!

There are many different factors that influence a project. Some examples are below

1. Criticality – How important is this project to your organization?
2. Complexity – Is it a routine project or does it include groundbreaking changes?
3. Organizational Maturity – Where is your company in regards to planning?
4. Project Management Methodology used? – Waterfall or Agile? Why one or the other?
5. The Project Team. To come up with a successful Work Team you should follow some Team Building principles .
6. Geography – Where are all the stakeholders located? In how many countries? On how many sites? How many languages do the project stakeholders speak?
7. Number of Stakeholders – How many stakeholders are involved in the project?
8. Management Culture – Is it more a top/down culture or a laid back culture or …? 
9. Company size – Is it a project for a Multinational company or a small startup?

An additional Key factor is the “human factor”. What I mean by this is that the deciding factor is how people interact with each other. 
Would it help a Project Manager or Scrum Master if he or she had all the perfect specialists in one team but they don’t like working with each other? That is like an assembly of stars but it doesn’t make a good team.

It might be possible to remedy this situation but it would most likely require considerable time and effort. There are some simple steps you can follow proactively to minimize such situations.

If you are like most people you will do more for a team when you feel appreciated and important.

Unfortunately in a number of teams this is not the case. If your team is one of these teams you should start changing that. Be the Leader and don’t wait for anyone else to step up!

Note: It doesn’t matter if you are a Project Manager or Scrum Master or Project Team Member etc. If you are seriously interested in a successful team you can and should be the person that leads the change.

There are some fairly simple things you can do on a regular basis that will make a big difference like

• Say “Thank you” to someone who did a good job. Do it in front of others, regularly and sincerely. Remember people can’t read your thoughts. 
• Listen – before you prescribe any fix. If you really listen that will inspire openness and trust. There are many smart people out there and together you will come up with a better solution. I’ve seen it many times. It works.
• Walk your talks – Do what you say you will do, always! Be accountable for your actions, this includes successes and failures. 
• Give everyone a chance to shine – give everyone a chance to contribute in a meaningful way and look actively for chances to show team members strengths. 
• Be fair and honest – e.g as a Project Manager or Scrum Master don’t sacrifice your team in order to shine in front of Management

If you follow these simple suggestions consistently all stakeholders (including you) will feel more fulfilled and appreciated.

What's the value of Project Management?

It seems that many companies believe they know how to do project management effectively. Based on what I've seen, I would at least partially disagree. Yes, I'm sure there is a project management methodology they follow on paper and there are probably tons of project management documents posted somewhere (on a SharePoint, on an Intranet Site etc.). There are probably a number of people that have done their project management certifications (e.g. PMP etc.). You might even send people to training classes and get Project Management Magazines (e.g. PM Network) on a regular basis. This is all good and necessary and I highly recommend having certified Project Professionals available for your Projects. But the more important question is, how much is the whole project management knowledge and culture applied in your everyday business operations?
It's good to have the knowledge but what is it good for if you don't use it?

Take a moment to think about how often you heard, read or saw other people talking about necessary project management steps that you've never applied to any of your projects.

Let's look at one example: What happens in your company if you move from one project phase into the next one. Let's say from the Analysis Phase to the Design Phase. Do you evaluate your goals, costs and resources used so far? Do you know if it makes sense to continue with the project at that time?
In many cases the project just goes on because the budget was approved at the beginning and so the project simply proceeds. Project Manager, Project Sponsor or the Project Team probably know about the step but don't use in their projects. To engrain this step in your companies culture is not an easy step.

Depending on the Project Management Maturity in your company I suggest to use less Methodology steps but to really engrain the ones you use deeply in your company culture. Keep in mind that the acceptance of that culture is key. You have to come up with a way that makes people want that culture. Spend enough time here before you proceed with any changes.

To go back to the example above: If you use a project plan (includes project schedule, risk management plan, cost management plan, procurement management plan) make sure everyone knows about the plan and uses the plan. Reduce steps if they are not followed (e.g. remove the cost management plan).
Note: the purpose to reduce some steps in the project plan is to increase the acceptance of the project stakeholders. Once the accpetance is there you can and should work on the next steps.

As a project manager you are responsible to build a stronger team, so work with and for your team to get it there.

Integration Management

This topic covers the last of the knowledge areas according to PMI. In this post we discuss how we put all the pieces from the previous posts together.
During the project the main task for the project manager should be the integration role.
The Project Manager should:

• Take lessons learned into account. Do you have any historical information from previous projects? If yes, use it! This is important for project managers that join a company on a temporary basis and for regular employed Project Managers. Even though records exist quite often they are not taken into account. The lessons learned should show what went well and what didn't. It is especially important to pay close attention to the lessons learned regarding  “communication”.
• Determine which Project Planning Methodology to use. Are you using the Waterfall model or the Agile Project Management with SCRUM? Why do you use one or the other? What Project Plan Documents will you use?
• Decide where all the Project Management Information will be stored? For the Project Schedule you might want to use a Software Program like MS Project. What about the Risk Management Plan? The Communication Plan etc.? You also have tons of other documents (e.g. regular status updates to project sponsors, Workflows, Project Charter, Business Requirements Plan, RACI charts, Meeting notes, Change Management). Where do you want to keep all these documents? Who should have access to these documents?

Let's put the tasks above plus some others in a chronological order.

1. Create a Project Charter (this is a fairly extensive example). The Project Charter in its simplest form should explain what the objective of the project is. What is the Business Case? Why is the Project being done? It should further state what the deliverables of the project are. Note: Keep in mind this is NOT a project plan! Keep it short and simple so that it is really useable!
2. Prepare HIGH LEVEL Project Documents as far as possible (e.g. if you got a go-live date from a project sponsor you can already enter that information and do some backwards calculation). You should have at least these documents.

a. Scope Document (Business Requirements Document)
b. Project Schedule
c. Risk Management Plan
d. Communication Plan
e. Procurement Plan

3. Determine how Change Management is supposed to work and put the necessary policies and   processes in place. This will deal with changes once the original Project Scope has been agreed to and then you get the unavoidable changes. 
a. What systems will you use?
b. Who needs to approve a change?
c. What is the expected Turn-around-time for a change request?
d. Do you have a form that needs to be submitted?
e. To who is the form submitted?

4. Setup a Project Kickoff Meeting
a. Objective here is to make everyone familiar with the details of the project and the people who will work on this project.
b. Invite all the stakeholders (e.g. project sponsor, project team) for a face to face meeting if possible
c. If the project team comes from multiple continents and multiple cultural backgrounds make sure you are familiar with their cultural backgrounds so that you can work most effectively.
d. Review all the available information (e.g. project risks, meeting plan, project schedule)

5. Execute the Project
a. This can include the Project Management Life Cycle for every Project Life Cycle
 
6. Close the Project
a. Organize a post-mortem meeting

Check this link for a short summary of Integration Management from PMI.

Procurement Management

The objective for this blog post is to provide a high level overview on this topic. This is appropriate for Project Managers that do not deal with this topic on a regular basis. To delve deeper into this topic you might want to start with this link . This is a bigger subject so take your time to follow up on the different Procurement Management Steps mentioned below in order to get a thorough understanding.

Definition: Procurement Management includes the processes required to acquire goods and services from outside the performing organization.

As always you start with a Plan. In this case a Procurement Management Plan . In an ideal world the Project Manager should be involved in the creation of a procurement contract . The Project Managers role should cover at least the following tasks

·         Ensure Risk Management is incorporated in the Procurement Management Plan

·         Ensure the Procurement schedule aligns with the project schedule

If the Project Manager was assigned to the Project AFTER the contract was signed a thorough check is recommended to ensure the tasks above are appropriately covered.

There are basically 2 different ways of procurement contracts:  (for more info check this link, slides 18+19)

1. Centralized – a department/team handles the contracts for all projects


2. De-centralized – an assigned contract administrator handles the contract for 1 project

 The Procurement Management Process includes the following steps

Step	What tasks need to be addressed?	What’s the result?
Procurement Planning	Make or buy	Decided for Make or buy, Draft version for Scope of work is available
Solicitation Planning	RFP created	RFP ready
Solicitation	Get Answers for open Questions	Proposal was created
Select Source	Pick one	A signed Contract
Contract administration	Admin	Contract is complete
Contract closeout	Finish	Contract closed

Different Contract Types

-          Cost reimbursable

o   Buyer has the most risk because the total costs are unknown

o   Seller writes scope of work

o   Buyer describes what they need

o   The sellers costs are reimbursed

-          Time and Material

o   Price per hour/days or per SKU etc.

o   Used for smaller projects

o   Has elements of fixed price (per hour) and Cost reimbursable (cost unknown)

-          Fixed Price

o   Most common type of contract (one price for all the required work)

o   Buyer has the least (cost) risk

o   Seller will be most concerned about scope of work

o   Buyer can completely describe the scope of work (very rarely the case!)

-          Purchase Order

o   Used for commodity procurements

The scope of work describes what work is to be completed for a contract. It should be

- clear (unambiguous)

- complete (e.g. describe all tasks that the seller is required to complete, performance expectations for Software Projects etc.)

- concise