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 :-)

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 :-)

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.

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!