You asked. But, you don't listen!

Listening is NOT equal to SIMPLY asking question!

Ask the right question to get the right answer.

To get the right answer, listen properly!

Focus on the root information. Not about the length or flowery words ... Pay attention to the tone of voice and reaction on the face. Observing the body language is as important as the choice of words used.

If you ask question, but you don't listen properly; then it is equivalent to DON'T ASK!

Interviewed by the client's tender committee

During tender process, the client's tender committee can invite the vendor to be interviewed for clarifying certain issues or unclear statements specified in the proposal submitted by the vendor. After the client has clarified the issues they have, they might find out that actually, the vendor has given a better "idea" to refine the statements specified in the RFP (Request for Proposal) issued by the client earlier on. Then the client may scrap the previous RFP or tender documentation and initiate a new tender. Then, in the new tender, the client can include the things they found useful through previous clarification or interview.

Although the client has this option, but it may be negative effect on the vendor. The vendor's effort to respond to this kind of process involves additional pre-sale cost. However, as a vendor, we cannot run away from this if we need the business from the client. However, the client still has option to plan their evaluation process to suite their preferred vendor. If you know that you are not their preferred vendor, save a bit of effort on a higher chance tender.

The tender evaluation process can be tailored in any way to give higher marks or weightage on certain areas. For example, the preferred vendor can provide feature A and D better. So, the evaluation process can give higher weightage to feature A and D. That means that in the evaluation form, it may say 30% on feature A, and 30% on feature D, feature C 10%, etc. But, these evaluation criteria is not available to the vendor, so the vendor has to be smart "enough" to know what is considered important to the client.

:-)

PowerPhrases - Say What You Mean, Mean What You Say, Don't Be Mean When You Say It

This is a good book. I would suggest that you read this book before you are confronting those tuff guys :)

Click here to find out more

T.E.A.M - Cross Cultural Team Management

In some complex projects, most of the time the project team may
formed by many parties with different cultural difference. When we
say cultural differences, they are referred to as difference in terms
of but not limited to the following:

1. Nationality
2. Citizenship
3. Company values
4. Religion
5. Personal beliefs
6. Industrial practices
7. Age group
8. Gender group
9. Ranking in position

The list may go on and on ...

But, I think the basic principles are still applicable in managing
the team with cultural differences:

1. Respect
2. Trust
3. Motivation

However, when we are going to solve problems/conflicts within the
team with cultural difference, we have to pay attention to at least
the following source of information:

1. Choice of words (in the conversation)
2. Understanding of the problems (listen to the people involved)
3. Observation of the emotional reaction
4. Description of the case from their co-workers or friends (from the
same group, or having similar culture)

In order to perform stakeholders analysis, we can use the basic TEAM
factors as the starting point:

T - Timing of the action: For example, when is the right timing for
resource aquisition, the right timing of information distribution to
the stakeholders, etc

E - Effect of the project: For example, what is the perception about
the end effect of the project amoung the stakeholders. Will it affect
their jobs?

A - Authority and influence: For example, who has the authority or
influence on the project? Some times, some times, some people without
the authority and make or break the project by releasing some "3rd
party opinion" ...

M - Motivation: For example, what motivates the stakeholder to buy
in? What makes the people work ...

I created this simple TEAM factors for myself to remember the most
critical factors all the time when managing the team and
stakeholders. Hope that it helps :)

What do you think?

The usual processes for setting up a realistic schedule

The usual processes for setting up a realistic schedule:

1. Invite the team to give input and create the WBS - if the riskassessment is performed at the same time is also possible.

2. Prepare the Network Diagram for the WBS

3. Perform risk assessment in order to find out more risks after thedependencies have been identified.

4. Update WBS and the network diagram

5. Assign resources to the work packages

6. Prepare draft schedule with resources availability

7. Perform resource leveling

8. Perform risk assessment in order to find out more risks after the resources have been considered

9. Get consensus and finalize the schedule

10. Finalize the baseline

Usually, for small project, the risk assessment is also informal and is done at the initial stage, which might be even before the schedule is developed.

But, to create an almost realistic schedule, the resource leveling (step 7) is important. But, be careful when you do this with any scheduling software.

What makes the definition of Project Success?

What makes projects successful? Many project managers will say:

Time, budget and quality.

Are that all? How about the following situation?

1. Initial problems or objectives for project justification are not solved or achieved.

2. Project sponsor and key stakeholders do not look good.

3. Customers’ satisfaction is not achieved or cannot be defined.

Imagine, if the project is supposed to deliver a sales system. The system is delivered on-time, within budget, and with expected quality and performance. However, what if:

1. The number of customers is not increased;

2. The yearly overhead is higher;

3. New promotion of products cannot be handled.

Then most of the PMs will say, "hey, those are not my problems ... I should not be blamed ..."

Of course, every reasonable people will agree with that, just that the customer is still not "happy" with the result, they still think that the project is not that "successful" ... is it a fair comment?

Yes, if we are talking about the definition of success of project, we can qualify that those problems or effects after the project delivery are not the PM's fault. But, that is the project objectives definition problem. The expectation out of the project should be clearly communicated during project initiation stage. If the PM is involved in the initiation stage, he/she should take initiatives to ensure the objectives are "defined" or "quantified" as much as possible. Take the business risks into consideration. Then the priorities of objectives can be a decision point for the project scope, timeline and quality expectation. A lot of human interaction here ... not only about the tripple constraints!

The Last Evening Talk in Year 2005

Finally, I was lucky to get my boss approval and sponshorship in hosting the evening talk at our auditorium for PMIMY (Project Management Institute Malaysia Chapter) and MNCC (Malaysia National Computing Council). It was a nice event and there were about 90 attendees that turned up. It was the first evening talk that I organized after I come back to Kuala Lumpur. When I was away to Johor Bahru for my PMO project at Johor Port, I missed many sessions of evening talks that were quite good. Now I am back to KL, so more opportunity for more exposure :-)