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!

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