WEEK 5 NOTES

Daniel started by explaining the basics of what a proposal and a tender document was.

“Proposal” / “Tender response”:

I learned that the purpose of a proposal is for

1.) legal reasons

2.) Keeping everybody on both sides of the project right

3.) So the client knows the process and what’s going to be done before the team is assembled

“Tender”:

In other words – a tender is a document that lays out what a company needs done, and a proposal is a response to that tender.

READING “PROJECT GUIDE TO UX DESIGN” CHAPTER 3

ELEMENTS OF CHAPTER:

Proposals (a summary)
creating the proposal
- 1.) title page
- 2.) revision history
- 3.) project overveiw
- 4.) project approach
- 5.) scope of work
- 6.) assumptions
- 7.) deliverables
- 8.) ownership and rights
- 9.) additional costs and fees
- 10.) project pricing
- 11.) payment schedule
- 12.) acknowledgement and sign off
statements of work

“CREATING THE PROPOSAL”

TITLE PAGE:

To include:

Client company name
client company logo (if permission to use it)
project title
document type (proposal)
version of proposal
submission date
my own company name
proposal authors
project reference number
cost
confidentiality

Logo, cost, and project reference number

I’ve learned that for a title page I should avoid using the clients logo. This is because the client knows who they are, and its not worth the time and effort to ask for permission to use the company logo, its also not worth the hassle if you misuse it.

The cost is decided after the projects components are decided on, and the cost info leads nicely into the payment schedule.

The project reference number is also something to be aware of – a lot of companies won’t use one at all, although some government agencies rely on them and if its not found on your title page the proposal will be rejected.

REVISION HISTORY:

Revision history is its own section of the proposal
Its used to identify how many times you’ve updated the proposal since the original
In general, you should provide the version number, date, author, and any comments associated with that version (what was modified)

Below is an example of a revision history table:

PROJECT OVERVIEW:

Its a description of the project you’ll be working on in your own words

description should provide client with a clear picture of what you envision their product will entail, and an explanation of what they can find in the rest of the proposal

an example of the beginning of a project overveiw:

Its a good idea to conclude the overview with a sound explanation of your recommendations and proposed approach to completing the project:

PROJECT APPROACH:

This is an opportunity to identify to the client how you plan on working on the project with them.

You get to identify the rules of engagement and set expectations for the work that’s ahead of you.

One methodology was created to show to (potential) clients was the “Purite Process”

p – PREPARE – “We dedicate a portion of every initiative to understanding your industry and your competitors and how they do business in order to be as informed as possible prior to beginning requirements gathering”

U – Understand – We work closely with your subject matter experts and/or users to define the requirements for building the project correctly

R – Render – In this phase we create and develop all the pieces of a project/ product. In our experience, any development phase requires a lot of heads-down, focused work effort but also timely, open communication with your team(s). it also requires that we…

I – Iterate – The iterate phase is repeated throughout the entire lifecycle of the project. We move as quickly as possible to bring the project to life, and this often requires creating multiple iterations in rapid timelines. This requires direct and timely involvement from you and your dedicated resources. The end result is the product you’ve specified – and helped create.

T – Test – We test every project throughout the course of our render phase; however, we also require an extra set of eyes – from our own testing team and from your designed user group / audience group to perform goal based testing. this additional round of testing helps ensure that as few stones as possible are left unturned in order to deliver a project that’s been rigorously evaluated from multiple levels.

E – Enable – Upon successful completion of the five previous phases and your signed approval, we will enable the solution and take it live.

A simpler version of defining your process could be:

plan the overall strategy
define the detailed project requirements
develop, test, refine, and launch the work product
extend the project by recommending enhancements and improvements based on info learned during development, testing, and post-launch.

After defining the process, you have the opportunity to detail the various efforts that’ll take place in each phase of your approach, as well as what each of those efforts means to you and your client.

It will vary in length depending on your project, process, and the activities; however try to keep it 2 / 3 pages maximum.

Only include the outputs you’ll be able to deliver to your client – this will prevent further updating of the document or revisiting of the project pricing.

SCOPE OF WORK:

This is where you identify the division of labour for the project- AKA which parts the client does and which parts you do

An example of a scope of work:

ASSUMPTIONS

This is the place to spell out exactly what you need done from the client

“Assumptions” is kind-of like another word for “expectations”

An example of assumptions:

DELIVERABLES:

This is your opportunity to detail to the client what kind of work product they can expect from you during the course of the project

its recommended that you handle status reporting separately and closer to the end of the project – but feel free to add it to this part of the project.

provide description of any work product that you MAY include – even if it doesn’t get produced, however if you’re doing this MAKE SURE to use the word MAY

example of how to introduce the deliverable section:

OWNERSHIP & RIGHTS:

It’s important to consider the extent to which you’ll allow your client to use the work you produce.

This can be categorised in two different ways

- work for hire
- licensed work

Work for hire projects are considered created by and under copyright to the party who pays for the work – not the party responsible for doing the actual work.

This means that when performing work on a project that is work for hire you have absolutely no rights to the work and every thing’s owned by the client

Licensed work projects allow you to retain copyright to the work but grant other parties the right to copy/ distribute it

ADDITIONAL COSTS AND FEES

Its important that your client understands whether the project pricing you will provide for them does or doesn’t account for external resources

For example – some projects require the use of stock photography. You can either purchase the imagery and include it as part of your fee or you can clearly identify the purchase of imagery as an additional cost that will be passed along to your client.

If you anticipate travel related fees including hotels, and car rentals etc

An example of how to explain additional costs and fees:

PROJECT PRICING:

Estimate how long you think it’ll take you to do the project – including specific numbers of revisions

Estimate an approx amount of time for project management – this could be 25%

Then determine the hourly billable rate you want to charge, and calculate it all out

An example of a project pricing section:

Remember – there is no real wrong way to put together your project estimate – unless you put yourself into a negetive cash flow position!

PAYMENT SCHEDULE

payment schedules are sometimes created based on milestone based payments

They’re also created based on a recurring payment schedule with regular, detailed invoices.

This approach will also provide clients with a clear understanding of what’s been accomplished and what work is remaining on the project.

Its also important to include how it’ll be handled if the projects put on hold for a long period of time. if you won’t be doing work for them for a long time you may want to be able to move on and look for other work to fill the void.

An example of how to structure payments for your work:

ACKNOWLEDGEMENT & SIGN OFF

It doesn’t mean much until the right person in the client company has signed and approved it at the very end

Sign offs are clear and simple, once you have created the proposal document youll create two copies of it – including an acknowledgement and sign off sheet for both parties.

An example of an acknowledgement and sign off:

WEEK 6

1.) project over veiw (what needs done / experience)

2.)project approach (how it’s going to be done)

3.)scope of work (who is involved)

4.)assumptions (what you’ll need)

5.)deliverables (what you’ll produce)

6.)ownerships and rights (work for hire / licensing)

7.)additional costs (expenses)

8.)pricing and payment schedule (your quote)

9.)acknowledgement and signoff (agreement to start)