Construction Contract Claims, Changes & Dispute Resolution (Paperback), by Paul Levin

Product Details

Paperback: 255 pages
Publisher: American Society of Civil Engineers; 2 Sub edition (June 1998)
Language: English
ISBN-10: 0784402760
ISBN-13: 978-0784402764
Product Dimensions: 8.9 x 5.9 x 0.6 inches
Shipping Weight: 12.8 ounces (View shipping rates and policies)
Average Customer Review: No customer reviews yet. Be the first.
Amazon.com Sales Rank: #1,319,885 in Books

Comment: This book has many good examples which can also be used in IT projects.

Due Diligence - DD

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

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.

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

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!

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!

KPIs for Project Management

Here are something to read about PM KPI: KPI explained

When we want to create KPIs for PM, we need to use the CSC (Critical Success Criteria) related to project management. This means that the KPIs must be related to Time, Budget and Scope (TBQ) tripple constraints.

In order to relate to these three critical criteria, the assumption is that tasks contribute to scope. Each task involve resource. Each resource is related to cost. Each task needs time for completion. Therefore Earned Value Analysis or Management is the tool that we usually used to measure these three key performance areas.

The following are some sample of KPIs related to Project Management (or Earned Value elements):

Earned Value (EV) -- This is the value that we get back as a result of the investment. For example, after the contract is signed, nothing is done but the vendor is paid 10% of the project fee; so, the earned value is still $0. Unless some work already performed and can be translated to the value.

Schedule Variance (SV) -- To show what is the difference between the original plan and the actual progress.

Cost Variance (CV) -- To show what is the cost difference between the original project budget and the actual expenses.

Schedule Performance Index (SPI) -- To show how well the schedule is managed against the baseline. This means that, for every $1 we spend on the resource, how much progress is achieved.

Cost Performance Index (CPI) -- To show how well the cost is managed against the original budget baseline. This means that, for every $1 we spend on the resource, how much value we got in return. For example, if we pay $1, but we get $0.5 of the value of the result, that means the CPI is poor.

Other KPIs that may be applicable are such as:

Customer Satisfaction -- For example, we can measure the return customer in quantity, or customer terminate the contract, etc.

Process Efficiency -- For example, the speed in getting one job done is compared between the post-project to the pre-project measurement.

Quality Efficiency -- For example, the number of defects, etc.