Tuesday, September 12, 2006

Defining the Quality

Project quality planning is about setting the right expectations on how the outcomes to be produced. Before we can plan how to obtain the result, we must define the quality expectations of the results. So in summary, quality planning involves two steps:


  1. Defining the Quality Expectations
  2. Defining How the Quality Expectations [satisfaction] To Be Met
Quality Expectation

Quality Expectation is about - what does the customer want. It should reflect how should the customer's satisfaction can be achieved after he/she gets what we give (the delivery of the quality expectation). In general term, quality means "specified functionalities that are fit to use". This means that, when they are fit to use, then the satisfaction is achieved.

For an example on an Internet Infrastructure Setup Project, the requirements are:
  1. Scalability
  2. High Availability
  3. High Performance
Once the high level requirements are defined, we can now specify the quality expectations. The quality expectations should be measurable:

Scalability - The infrastructure can be expanded. This means that we can add additional web servers, additional licences, etc.

High Availability - The infrastructure has to be "on" all the time. At least the total down-time allowed in one year is X hours.

High Performance - The performance of the system should be fast (efficient). This means that when a user opens a web-based reports, the response should be within ? seconds. Or, when the user open a web-based public page, the response should be within ? seconds. Of course, the performace can be affected by many factors, but there should be a measurement of various types of pages.

Once we have specified the measurable quality expectations, the planning of how to execute them will be easier. For example, to use purchase what types of equipment, how many servers, etc will be easier to plan. Another example can be like the scheduled down-time in a year, and which resources assigned to solve the problems, etc will be easier to plan when the quality expectation is measurable.

Quality Control Processes

How the outcome is to be tested against the quality defined is subject to the nature of the product or service. For example, how to test whether the outcome delivered is according to the quality expectation for a software system will be totally different from a project building a disaster recovery center (DRC).

When the quality definition is done properly then the testing part will be easier. Testing is one of the means for us to find out if there is any defects in the outcome so that we can control the quality. The testing methods must be carried out according to the plan. The plan is in regards to how the quality is defined and by meeting what conditions then the quality is met. So, the testing is "planned" when you define your quality definition. It is the starting point of the testing.

In my early days when I was a software developer, I started planning the testing only after the system is completed. But, how it should be tested, I didn't really know. Why? Because the customer didn't define how it is to be tested and my supervisor (the manager) didn't tell me how to define the quality in the first place ... What happened then? The customer hesitated in accepting the system as per it is "fit" to be operated in the production environment. What was the consequence? The payment was delayed. How it was delayed? The customer bargained with my manager for how it should be considered fit for them to accept only during User Acceptance Test! There were 5 testers that tested the system and these 5 testers had their own "expectations" which were conflicting with what the quality expectations "created" by us (the supplier). Crap! Work done! No money! All complaints here and there!

So, in summary, these problems can be avoided if in the first place the "fitness of use" is defined properly :-(

Friday, September 08, 2006

R&D on Project Performance Tracking

I have created some files to demonstrate the project performance tracking by using Ms Project 2003 and Ms Excel 2003.

All the files are zipped. The Ms Powerpoint file contains the scenario and sequences of the demonstration.

Please feel free to test it out and let me know if you have any better ideas or ways in doing it. Let's share our problems and solutions :)

The following is the summary of the R&D:

I create two projects. Project A and B. The mission of both projects is to install 100 units of PCs within 8 days. For every 20 units of PCs intallation, we assume 20% completion of the project. So, the following is a summary of the plan:

Day 1 - 20 units, Day 2 - 20 units, Day 3 - 20 units, Day 7 - 20 units and Day 8 - 20 units. For

Project A, I allocate these individual units across one single task row while Project B I break down the milestones into 5 task rows.

Then I enter the actual value - the actual units of PCs installed on individual days. I enter 20 units for day 1 and 40 units on day 2. Now the problem comes: Project A doesn't reflect the correct % complete accordingly. So, it is better if we breakdown the milestones into individual task rows. Check the presentation file for details...

Monday, June 26, 2006

Learning to express

It has been quite some time I don't update this blog. I was busy with a few proposal submissions. The preparation work is always tiring. The deadline is always pressing us to work very hard and long hours. I have to run around the building to have several meetings with all the people involved in a few separate sessions. As our resources are assigned to multiple projects at the same time and these projects require them to be on-site most of the time. It is quite difficult to get all the people sit in the same room for a proposal preparation meeting that is longer than one hour.

Lately, I am involved with one proposal preparation for a new client. The proposal is about setting up a project management office (PMO). My mentor has gotten the lead opportunity through his good work with some public seminars. He is kind enough to bring the opportunity to the company that I am working with. It is a good opportunity for me to learn by working with him to expand my experience in setting up a PMO for a client last year. My company is also happy for the opportunity for business and coaching on work for me. It seems everything is just going to benefit me.

My mentor has massive experience in consulting business. He has work experience at high rank with the big 5 consulting firms. For me to learn from him, I have to work harder than usual. He has higher expectation in preparing proposal such as the style of expressing the ideas, selling the ideas, sellection of diagrams, etc. It took us (me and him) a few hours just to write the Executive Summary.

I have to draw diagrams to clear my thoughts and to make the thinking process more logical before I put down my pen. This has helped me think better. Although the process is much more pressing and tiring, but I believe in the benefits I will get later.

Writing is not easy, in addition, to express well and to impress well is even harder. I am learning. I am reading a book on writing skill. Hopefully, soon, I will be able to be a professional writer.

Thursday, April 13, 2006

Creative thinking!

My definition for Creative Thinking is -


To think "how to not to do it myself: To find as many alternatives as possible as options for making decision. The alternatives are not necessarily to be new ideas, but are multiple choices for me to compare and choose from.

When I mean creative in business options, I mean "how can we EMPOWER and ENABLE the OTHERS to provide what we want or we need?" The following options are my examples when I mean "empowering and enabling the others":

to produce the goods for me?

  1. to collect the data for me?
  2. to analyze the collected data for me?
  3. to do marketing for me?
  4. to do selling for me?
  5. to deliver the goods for me?
  6. to collect money from the customer for me?
  7. to manage my information system for me?
  8. to manage my projects for me?
  9. to manage my suppliers for me?
  10. to obtain other sources of financial funding for me?
  11. to identify good investments for me?
  12. to generate income from the investments for me?
  13. ...

Now, most of the activities in business are not owned or performed by in-house resources. Most of them are through services provided by other parties. I call this as partnership-oriented business nature which is different from the Chinaman's business nature. The Chinaman's business nature is always related to "one leg kick", "all in one" and "one for all". When we are talking about partnership-oriented business, we are talking about "work together" with others! As PM job is very heavily relying on others, we should always think in "partnership" model!

When you are open for ideas, not emotional, not biased then you may have more choices. When you have more choices doesn't mean you should simply choose one from the options. The final decision has to be made based on certain basis and calculation.

Monday, March 20, 2006

Before a serious confrontation ...

I have got the book: Crucial Confrontation!

It is really a great book. After reading it, I learned a very valuable lesson on how to deal with confrontation - in a better way.

But, first things first, I have to work on myself first:

  1. Am I the problem?
  2. What is the real problem? Am I dealing with the signal or the right problem?
  3. Why should I confront? Is it a high-stake "must"?

It also highlights that, we should open our mouth when we have the following signs:

  1. You're acting out your feelings
  2. Your conscience is nagging you
  3. You're downplaying the cost of not taking action while exaggerating the dangers of speaking up
  4. You figure that nothing you do will help

Recently, there is one incidence where a sales person inform the technical personel late enough to come out with a proposal to be submitted to a client. I was the last person informed although I am to provide the cost for the project management services. For me to come out with the cost, I need to work on the schedule given by the technical lead. After I have the schedule, I need to review the technical lead's proposal write-up. For this last minute notification, I was so angry and told the sales person coldly, "I will work with the technical lead, but why you inform me so late? Tomorrow is the due date, and you inform me as the last person ..." But, the sales person raised her voice and asked me to forget about the redtapes, and better get started to work on the costing and schedule ... At that time, I was really angry ....

So, after I put down the phone, I did all the things and finally the proposal due date was postponed. Because, the sales person herself said that she was so busy and cannot work on the proposal. Anyway, my obligation is done. But, should I confront her? If yes, what is the real problem?

  1. Am I angry because of the fact that she is not respecting us?
  2. Am I angry because I don't have sufficient time to complete the work within normal office hours?
  3. Am I angry because she was instructing me to do my work?

Now, I am still thinking ... am I creating imagination for above issues? Am I finding excuses to confront her?

Finally .... my decision is ... let me finish the whole book first before I decide :-)

Thursday, March 09, 2006

The most difficult people I have ever dealth with ...

Based on my experience, I have come accross the following types of people:
  1. The bully. They just want other people do things following their way. They want you to keep quiet and listen to their talk. They will use their authority or their boss' authority. The worse thing is, some times these people will just use very bad tone or manner when they talk. They make you feel like you are nothing. And they like to show their "power" in front of the public to make them look good, but bad on you ...
  2. The sniper - They like to stab you from the back! In front of you, they will say all the good things to you. When you are not careful enough ... your blood is leaking ...
  3. Everything can; but come to the end, everything cannot!
  4. Everything is no. Before you finish your explaination, the answer is already in his mind -- No!
  5. "Let's do it! You go first, I will come after you ..." This kind of people will talk like a leader, but when come to problem solving ... you are on your own ... they already start digging another hole somewhere else ...
  6. "I know it cannot work. But, don't ask me why!" This kind of people, always got their own assumptions and start with something negative. He will criticise whatever you say, but no solution is recommended. He can always say, "you are the consultant, so you should know what is wrong! Don't expect me to pay you and tell you the answer!"
  7. "The things already in my blood! I will never be wrong! Don't ever try to say something stupid to me!" This kind of people just remember the old good days in their time ... whatever they have done was perfect, the best ... they won't admit that there are better ways out there ... They always believe that their experience and skills will never expire ...
  8. "I already knew that it won't work ..." This kind of people will criticise how fool you are only after all you have done and tried. They were quiet when you were doing the planning even they were part of the planning team. When something goes wrong, then only they say "I already suspected the things will not work ..." Their "wisdom" always comes only "after" other people failure!
  9. Smoker! This kind of people like to "smoke" your view, they paint the wrong picture to cover up what they have done wrong. For example, they will start talking loud on your issue to distract people attention on his late attendance to the meeting ...
  10. The Great Pretender! This type of people will be the "nice" people all the time. They will appologize for their fault, their mistake ... but will do it again and again ... It is like they slap on your face and then say sorry for it ... again!
  11. The Micro-Manager! This type of people are very thourough. They can always find the "fish bone" in an "egg"!

Do you have the same problems?

Related links:

Dealing with People You Can't Stand: How to Bring Out the Best in People at Their Worst

Books Recommendation - Crucial Confrontations and Crucial Conversation

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

Thursday, March 02, 2006

Meeting procedures

All meetings need to be properly minuted. Here are some guidelines to follow for taking minutes and reviewing pending items.

Here is another guide for chairing a meeting.

Tuesday, February 21, 2006

The Last Evening Talk in Year 2005


Finally, I was lucky to get my boss approval and sponshorship in hosting the evening talk on December 14, 2005 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 :-)

Wednesday, February 15, 2006

Are you one of the in-house resources?

Usually, most people will relate "in-house" to "under the same corporate umbrella" so, everything can be compromised ...

Under the same umbrella, your customer can be your boss or those people who are having higher access to your boss directly. It will have direct "impact" on your career. It is quite hard for you to say "no!" There is "almost" no way for you to reject unreasonable request and yet you can't run away from being "blamed" if your project is not delivering what is "expected" by the stakeholders. It is even worse when the cause of the failure is not directly under your control ...

In-house usually implies that you have the "obligation" to be "competent" enough to be kept "in-house". It is often that when you are "in-house" resource the expectation on you is even greater compared to external resources. Transparency (how your work is watched) is also very high.

It is also interesting to note that "in-house" give others theperspective of "sunk cost resources" therefore most of the jobs are considered "inclusive" within the "salary" package you are getting.

So, are you one of the in-house resources?

Open-ended System Requirement Study Period ...

A requirement study stage should not be left "open-ended". There should be key review milestones specified for checking the accuracy of the study and make any necessary change if required. No matter it is based on Water-Fall model, RUP, etc, the principle is still the same -- the outcome/deliverables of any stage must be specified in the scope of work (SOW).

If based on a small software house scenario, assuming the job is gotten through Purchase Order (PO), and if there is no contract is signed, and if there is no SOW is bound with the contract, then at least there should be Project Schedule that shows the milestones for review. During each review, meeting minutes should be taken to protect your effort (if next time there is any dispute).

Of course, time is short and expectation on requirements can be challenging, but some creative ways can be used to gain common understanding and be bound/attached to the System Requirement Specification. For example, the system analyst can use Use Case, UI prototype (on paper or on computer), Flow Chart, Story Board, etc. As long as can common understanding between the provider and customer can be reached.

If our problem is: "The customer is sitting on the documents", then it is the project manager's job to "kick" the customer to respond. Or put the clause "If we do not hear your feedback for changes to be made within 5 working days, we assume the specification content accurate." And in addition to that, don't just wait for it to happen in front of your email program, call the customer or see him/her to check the progress.

Another important area is to get the "right people" to be involved. Don't let those unspecified stangers come into picture last minute. It is okie for people to come and go, but any delay related to this should be recorded and justified for extension of time.

Useful Project Management Links

I have a collection of useful links related to project management templates and methodologies. Please feel free to download them and revert to me if you have others to recommend :-)

Monday, February 13, 2006

What is the major difference between Fixed Work task and Fixed Unit task?

Have you ever wonder what is the major difference betweent the two type of tasks? Here is a Powerpoint presentation to show the difference.

Here is a quick summary:


Examples of a Fixed Work Task

Based on normal situation, each clerk can prepare 1 document per hour. She can prepare 8 documents per day. If there are 4 persons to work on different documents, there will be a total of 32 documents to be prepared within 1 day. In this case, if our task is to process 32 documents, they can only be completed within 32 man-hours (fixed work effort needed). So, to complete this task, we can assign 4 clerks to prepare 8 documents in one day, or 2 clerks to prepare 16 documents in one day.


Examples of a Fixed Unit Task

If one clerk will only work 8 hours a day (assuming each resource is one unit. Each unit will contribute 8 hours per day), no matter how urgent is the work. If our task is to supply 2 clerks to process the documents for 2 days without considering the urgency of the documents, so for this task, each clerk will work 8 hours in one day and 16 hours in 2 days. Based on our statistics (or estimation), 16 documents should be produced for each clerk. So, we can process 32 documents within 2 days with 2 clerks assigned to the task.

Take back your control on the project schedule!!

Have you ever experience the "bad experience" about the Microsoft Project schedule when Ms Project try to be too "intelligent" by amending your duration when you add/reduce people to/from your tasks? Here are some tips to take back your control!

There is also another useful tutorial that drills down to the setting of the task properties.

Friday, February 10, 2006

How to avoid scope creep?

What is scope creep? The more the team explore what does the scope statement means, the more they find out they underestimate the coverage!

Usually, the scope creep can be caused by the following scenarios:
  1. Underestimate of complexity
  2. Wrong assumption/intepretation of the scope statement
  3. The environment factor has changed

For environment factor, such as government authority dictates on certain compliance, is very difficult to foresee. But, usually, it will become a totally new requirements that can be negotiated for additional charge.

For item 1 and 2 usually they are considered as the contractor's responsibility to explore the risk. But, considering the short time frame that the contractor has in doing the study or risk assessment, the best way is to build in some buffer plus the following effort:

  1. Specify the review cycle and approval cycle for certain key stage or documentation in the contract or scope of work document.
  2. Specify the prerequisites requirements for the stage or work to be performed in the scope of work.
  3. Clearly define the deliverables for each scope statement (if possible) in the scope of work.
  4. Clearly define the assumptions for each scope statement (if possible) in the scope of work.
  5. Keep some buffer for additional time and resources to be utilized

Some times, scope creep is not that scary ... but to know who and what to escalate is crucial!

Can we have properly defined scope before the detailed project plan?

Can we have properly defined scope before the detailed project plan? I guess, this is the "best case" secario if you are the project manager who is to execute the work defined in the scope statement.

But, before a properly defined scope can be obtained, there are a lot of planning and coordination work to be performed by the team. There are many rounds of follow up to be done. There are many parties to be interviewed and met to obtain all necessary important information. So, the objective of the project plan is to include that portion of work as well.

The scope statement (some times it is known as System Requirement Specification for software project) will be a "living" document. This means that, the team will continuously update the scope document to ensure the latest and most accurate condition of the requirements are documented. When there is additional scope after further assumption clarification and exploration, this new requirement will be submitted for approval for inclusion as Change Request. When we say new requirement it means that it is totally outside the original intention of the requirement. For example, originally the scope statements specifies that there are two units of servers are required for hosting the database. After the project is started, some external government authority dictates that for all transaction audit, the system needs additional two units of servers to store archive-data. In this case, the two additional servers are considered as new requirement.

In another scenario, in the original scope statement, if it reads "The system shall be able to keep the sales transaction for 3 months on the production server." After further study, the team finds out that the "sales transaction" means sale enquiry record, quotation record, sales order record and payment record. But, the original team assumes the sales record is equivalent to sales order record only. In this case, the problems arise: For these four types of records, for three months, the production server storage capacity is not sufficient to store these records. So, additonal storage media or shorter duration of the record keeping needs to be decided. In this scenario, it is "wrong assumption or intepretation" of scope definition. It is not an additional requirement. It is an under-estimate of scope complexity. In this case, it is the vendor responsibility to "find out" what does "sales transaction" means, what to do after the "3 months", and where the "production server" is.

Then the next question will be, how can the vendor find out this requirement in a very short duration during tendering (or proposal) stage? Usually, the detailed study will be performed only after the contract is awarded to the vendor. But, the tolerance level for scope difference should be defined in the project flexibility. Some times, the buffer for the scope is built in to the quotation or proposal. It is part of the risk assessment. The buffer for wrong estimate is crucial especially for fixed price contract.

So, the conclusion is ... it is very rare chance you will have a properly define scope before you start developing your detailed project plan :-)

Understanding a Tender/Bid Documentation

If your project is going through a normal tendering (some times, it is called bidding) process, you will usually be required to submit your proposal to address client's requirements specified in the Bid document. The bid document is some times called Tender document too.

So, what are inside a tender document? Usually it will consist of the following parts:

  1. Tender cover letter
  2. Tender instruction to vendor (instructing the vendor how to response)
  3. General requirements
  4. Product requirements
  5. Services requirements

For a good sample of RFP, click here to access the website of Office of Medical Procurement.


Within the Tender document, there will be one part named Request for Proposal (RFP) which details down all the client's requirements (general requirements, product requirements and services requirements) on the project.

As the name implies, RFP will expect the vendor to propose how they want to address the project requirements. The proposal should show your distinction on your solution - how different is your solution.

There are basically two parts of the requirements. First, there will be requirements for the product or products required for the project. For example, requirements on the hardware or software required for the project. The second type of requirements are those non-product requirements. For example, study, design, training, testing and implementation are all services. When we combine these two types of requirements, we call it solution requirements.

There is very high chance that more than one vendor is proposing the same product. For example, two vendors may be IBM product sellers. But, the quality of service may be different. So, through different approach in packaging the solution, it can differentiate the quality of the vendor.

Nowadays, especially for projects going through tendering process, the client (or customer) will look out for better solution (which implies a better product range plus better quality of service).

Thursday, January 26, 2006

Understanding Earned Value Basics

This file shows some examples in using Ms Project 2003 and Ms Excel to produce S-Curve chart based on the data collected from Earned Value Analysis.

Here is the link to the Ms Excel file that you can try out the concepts discussed in the presentation file.

A case study - Setting up a PMO

This is a presentation that I prepared for the seminar last year. But, unfortunately, I fell sick on that day. Eventually, the presentation was taken over by my colleague :-)

This presentation is about my experience as part of the pioneer team in establishing a PMO (Project Management Office) for one of the biggest ports in Malaysia.

Project Manager Survivor Guide

This is the slides that I prepared when I conduct and in-house training for our technical specialist. Some of the project management skill may be still applicable eventhough they are not put into the position as project manager.

Hope this guide is useful to you too :-)

PDU Calculation Worksheet

If you are rushing to submit the PDU (Professional Development Unit) claim within this year, you can use this Excel Worksheet to calculate how many points more you need here. There are a few restriction on certain type of activities such as professional work experience, self initiative learning activity, etc.

Wednesday, January 25, 2006

Reference for Writing Style and Grammar

I believe most project managers will face demands for clearer writing for their work on proposal, letter, memo, email, etc. When you are expected to write, people will expect you spend some time "to think" before you type. A clear message is always expected from your written document.

Here are some useful reference points for writing style and grammar :-)

Tuesday, January 24, 2006

Why project management is important?

This link shows why project management methodology is important. It also leads to the complete methodology of Tasmanian State Government.

Good Lessons Learned from Apperentice 2 and 3

Good Lessons Learned from Apprentice 2 and Apperentice 3.

Project Tolerance

Ultimately, the tolerance level that determines whether a project is a success or failure. Each project should be given tolerance level for the variances on scope, time and budget. All plans are based on the best estimation. There is no perfect plan. Based on actual measurement or feedback from execution, the plans have to be changed to reflect the actual situation and what to be done next. However, changes should not be taken for granted. All measurements must have baselines. By comparing the baselines to the actuals we got the variances.

If there is no tolerance level set, we can not know what is acceptable or what is not. The tolerance level is how the project determined for effectiveness, efficiency and economical. The tolerance level on any of these is strongly influenced by how good is the stakeholder relationship. No mater how good is the product or work done, if the stakeholder relationship is bad, the tolerance level will not be high -- so, that means the project is already half way dying .... So, start from now, pay more attention to stakeholder relationship management!

Book References Recommendation

Crucial Confrontations (Paperback)
ISBN: 0071446524

Crucial Conversations: Tools for Talking When Stakes are High (Paperback)
ISBN: 0071401946

As most project managers know, communication is critical as part of their work. Dealing with people is always a dynamic challange considering everyone they need to deal with will have different attitude, mindset, perspective, expectation, characteristic, etc.

I haven't gotten these two books yet, but planning to get a copy of them soon. Based on the feedback and review comment from those who own them, these two books will definitely add to your PM Tool Box :-)

Project Management Practices

Core Concepts: Project Management in Practice (with CD) (Paperback)
by Samuel J., Jr. Mantel (Author), Jack R. Meredith (Author), Scott M. Shafer (Author), Margaret M. Sutton (Author) "Once upon a time there was a heroine project manager..." (more)

Monday, January 23, 2006

Dealing with People You Can't Stand: How to Bring Out the Best in People at Their Worst

Another good book recommendation for you! It is about how to deal with the 10 types of most difficult people that can be in your office, home or anywhere ...

Although it may not address all the people that you may have difficult situation with, but at least, with this guide and practical advices, you can react differently, at least, be a more healthier victim :-)

Don't react too fast!

I have personally seen and been involved in highly emotional, personal, stressful situation in communication in projects.

When there is verbal attact, usually the person who is receiving the attact will be fighting back by instinct ... and the instinct is always telling us to do something silly ...

To communicate properly under stressful verbal attact, we need to put the personal emotion aside. Look at the real substance of the things being talked about. Not the choices of words being used. For example, "It sound stupid to me that this thing is to be done in this way ..."
Usually, we will automatically respond to the word "stupid" with anger. No, we should look at the substance: " ... for this thing to be done this way ..."

We can ask, "yeah, this way seems not so good AND I am open for suggestion. Your input is very much valuable for helping me ..." If you say in this way, the other party will have to be involved.

If this guy says "no, you are the consultant, you should know the best ..." Then, you can say, "I have tried my best to obtain the point of view of most of the key stakeholders on my (best) solution ... and so far they have given favourable replies ..."

We need to focus on the fact and the reason to support what you say. It is not emotion that supports us. But the real reasons will back us up.

The objectives is to get what we want in "good terms". Don't react too fast! :)

Sunday, January 22, 2006

Soft buttons ...

Everyone has "soft buttons". Including myself. I am aware of emotion effects when someone presses my soft buttons. I am "allergic" to some words... I will clench my fist ... my body will be shaking ... my voice will be raised ...

But, I always regret after I release my "anger" ... Now, I tell myself, "wait! Cool down!!""Dear Mr. A, I am sorry, could you please repeat your question? I can't understand what you mean ..." This will make the speaker to have a chance to "rephrase" the question or accusation, then you can have some time to take a deep breath and reevaluate what is the real problems, then only react to the right problem ....

Shit ... I hope I don't regret too often ...

Saturday, January 21, 2006

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!

Tuesday, January 17, 2006

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.

:-)

Sunday, January 08, 2006

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?

Saturday, January 07, 2006

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.

Converting a Physical Linux to Virtual

Hmm ... I have done a lot of work on my Linux Lubuntu 15.10 with PHP and PostgreSQL and a few other things ... it is quite time-consuming to...