1. Big Picture: Execution and Delivery
2. Characteristics of a Good Contract
3. Work Contracts
4. How to set a strong contract
5. Memo of Understanding
6. Communication
7. Typical Project
8. Project reviews
9. Standard Project Risks
10. Keys to successful project management
11. Measurements
12. The Business Plan and Project Plans
13. Rules
1.Big Picture: Execution and delivery
Most problems in execution arise from poor communication.
Rule: “You always must find out: “What are we doing, and why are we doing it”
Your objective is:
• No Guesses
• No Surprises
• No Assumptions
To accomplish this, you must have a clear contract between all the parties, regarding what will be accomplished.
A Lawful Contract must have:
• Lawful Object
• Consideration
• Competency
• Mutual Consent
Rules:
• “Most projects fail for lack of a clear contract”
• “Don’t do anything without knowing what will happen next”
2.Characteristics of a “Good” Contract
• No Assumptions
• Written-Signed
• Buy-in from both sides
• Authority is clear
• Responsibility appropriate with Authority
• Clear Deliverables
• Clear Timing
• Details worked out
• Specifications clear
• Communicated to ALL affected parties
• Consideration (payment) is clear
• Others
• ______________________
• ______________________
• ______________________
• ______________________
• ______________________
• ______________________
• ______________________
• ______________________
• ______________________
3.Work Contracts:
Definition: A work contract is an agreement between two people (typically, customer and supplier), covering the delivery of the result of a particular effort, to be performed by the supplier for the customer.
What you need on a “work contract”
• A clear deliverable
• When it’s needed
• Who is responsible for delivery
• Expected level of efforts and costs
• An agreement on quality (accuracy, finish, etc)
• What happens if Unexpected Problems arise
• How are issues of Authority resolved
• Both parties’ agreement that it can be done within the
• constraints. (often, two signatures on the contract)
Rules:
• “Most contracts fail for lack of a clearly defined deliverable”
• “You must have “Consent” between the parties to have a
good contract. An order does not do it”
4.How to set a strong contract:
First, answer: “What are we doing?”
1. What do you want as a result of this project? Precisely, what is the deliverable?
2. When do you need it?
3. What should it look like? (e.g. the report)
a. Could we sketch it out now
b. Can we define the graphs and tables
4. Anything else?
5. Can we fill in our collective best guess as to what we expect the results to be?
6. What degree of accuracy is required?
7. Assuming that you get the deliverable as sketched out above, are you happy?
Rule: “You must get confirmation that the deliverable, as agreed, will satisfy the customer”
Rule: “The person receiving the work must ask these questions. The requestor must make sure they are all asked.” (why?)
Second, answer: “Why are we doing this? (could we maybe not do it at all)?”
1. What will this report (deliverable) be used for?
2. Who sees it, who gets a copy?
3. What decisions will be made by the organization as a result of this information?
4. What level of effort would be reasonable for this report?
5. Do you expect that I will need input from others? Who?
6. What do I do if I run into problems getting information from others?
7. How do we resolve this?
8. What is the priority of this project? (define re: other work)
9. What happens if I can’t get it done by the due date? (unforeseen problems)
a. Do I stop by time limit? By due date?
b. Should I present my “best guess” within the time and level of effort constraints?
10. Will this report be needed in the future? Should it be a standard format?
11. Do you want to see a draft first?
12. Write it up. He who writes history, defines history.
5.Memo of Understanding
What is it:
• Documentation of an implied contract, when the parties don’t (won’t) formalize the agreement in writing.
Why do it:
• Clarifies the contract
• You get to write it. Your spin
• Proactive
Why bother:
• It can be legally enforceable
• It will become the only documentation of an agreement
• It really can protect you.
What it has to have in it:
• A summary of the implied contract,
• Be fairly written, even handed
• Time and process for objection by the other parties
• A statement that the document will be presumed to be correct, if no written response within the (reasonable) time period.
“If I don’t hear from you in writing, within 2 weeks, I will assume that you agree that this memo documents accurately our mutual understanding of this project.”
6.How we communicate on a project:
Agree with your customer:
• Who do you keep informed of the process
• Who gets copies of the results?
• Who should you consult with, and when.
• Who reviews your work, and at what point does this review happen
Typical Candidates for “who”
• Board of Directors (or project review team)
• Customer(s)
• Suppliers
• Your Boss
• His Boss
Agree with your customer and your Board of Directors:
• When you have design reviews
• When you have project reviews
• Who participates
• How you resolve differences in “direction” of a project
• Documentation requirements
Rules:
• “Most “Unhappiness” comes from poor communication, NOT from poor work”
• “A strong contract on communication will save you unbelievable aggravation.”
Typical project
Rules:
• Force all efforts through periodic milestones.
• Schedule reviews in advance. Hold formats consistent
• Process => Milestone => Process => Milestone
7.Typical Project, cont.
Rules:
• Most projects are “screwed up” by inappropriate innovation
• NEVER compromise a design freeze date on a project with a fixed and unmovable production date.
8.Project Reviews:
Why do them:
• Communication with customers, team, management
• Review progress
• Clarify objectives
• Get input
• Agree on what happens next
Two Types: Design Reviews and Project reviews
Design reviews:
• Occur during a process, PRIOR to reaching a milestone
• Objective to get input and consensus
• Typically involves technical issues
Project Reviews:
• Occur at a milestone (end of a phase, usually a deliverable has happened)
• Review project. Has it been successful,
• Should we continue?
• Typically involves commercial issues, e.g. delivery, costs incurred to date, costs for the next phase, return on investment.
Rule: “You can’t review a project without knowing ALL of the relevant financial information”
9.Standard Risks for any Project:
• You have to constantly evaluate risks
• There are standard risks for any project. Determine the risks for
your world
• Learn to be realistic
• Get team buy-in to risks and solution
10.Keys to successful project management
1. Process => Milestone => Process => Milestone
a. Force all efforts through control points
2. Write a work contract for the entire effort to the next major milestone:
a. Define Deliverables carefully
b. Answer ALL standard questions
3. Use Standard, proven technology, as the primary path (design)
a. Pursue design improvements as a parallel effort
4. If the “improved design” is not completely and carefully certified by the design freeze date, DO NOT USE IT!!!
a. Go with the standard design
b. Document efforts so the improvement can be applied to the next project
5. Always assess project risks.
a. Benchmark against other programs, both successful and unsuccessful
b. Use this risk analysis to communicate, and to ask for help
6. Communicate project results, both positive and negative
a. Summarize periodically and document design standards
7. Measure progress and results
a. What gets measured is what gets done.
11.Measurement
Rule: “What is measured is what gets done”
• Measurements are the second most important job of the team leader. (Safety is #1)
• Measurements quantify the mission, and the progress toward the goal. They are imperative for maintaining high morale.
Good measurements are:
• Simple
• Relevant
• Easy to understand
• Clearly communicated
• Accessible to all team members
The signs of a healthy company are:
• Measurements on the walls
• Products in the halls.
If you don’t see measurements and product, there will be problems! (Usually low morale)
Be careful to make sure what you are measuring is relevant to the goals and mission. Don’t report measurables just because the data is easy to obtain.
Business Plans and Project Plans
A business plan is simply a good project plan. Typically, there is more scrutiny on a business plan, because someone is putting in a significant amount of money.
A good project plan or business plan is like a journey:
1. Where are we going, and why
2. What does it look like when we get there
3. What is my role
4. What is in it for me when we arrive
5. Who else is involved
6. Why should I join
7. What are the risks
8. When is it over
9. How do I get out
There are several objectives of a business or project plan:
1. To be a roadmap for the business, identifying where you are going and the resources required.
2. To communicate your vision and purpose to your team members, (including the money guys).
3. To provide a baseline to measure results, and to drive decisions
A business plan is NOT just a device to raise money or get project approval, and then put in the drawer and never look at again.
12.Business and Project Plans: (cont.):
Decisions (to join, invest, etc.) are made on one’s JUDGMENT of:
1. The opportunity
a. The context of the opportunity
b. How this opportunity compares to other opportunities
c. Industry and market assessment
2. The people
a. Key management team
b. The leader
3. The product or service
a. Your customers
b. Your competition
c. Your competitive advantage
4. The risk and reward
a. The economics of the business
b. The deal. Who gets what for what.
c. Exit strategies
A successful Business Plan will have answers to all the “obvious” questions.
• You do not have to have all the answers. You only have to identify what you don’t know, and where you need help.
• Find an EXAMPLE of a successful plan that is relevant to your business, and use it as a benchmark.
Call someone when you start, who has experience in your business, (especially in extracting funding) and ask for help.
Rules: Project Management
• Don’t do anything without knowing what will happen next
• Most Projects fail for lack of a clear contract
• Most contracts fail for lack of a clear deliverable
• You must have consent between parties to have a good contract
• Most “Unhappiness” comes from poor communication, NOT poor work.
• He who writes history, defines history
• Poor communication => unbelievable aggravation
• Process => Milestone = Success
• Most projects are “screwed up” by inappropriate innovation
• A business plan is a project plan with your money and life.
• A plan is a roadmap. You can always change direction.
• What gets measured is what gets done
• Measurements on the walls, Product in the halls